View a markdown version of this page

Utilisateur de la base de données MongoDB Atlas - AWS Secrets Manager

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Utilisateur de la base de données MongoDB Atlas

Champs de valeur secrète

Les champs suivants doivent figurer dans le secret du Secrets Manager :

{ "username": "database username", "password": "database password", "clusterUrl": "cluster hostname", "databaseName": "authentication database", "groupId": "Atlas Project ID" }
nom d’utilisateur

Le nom d'utilisateur de la base de données MongoDB (SCRAM-authenticated). Cet utilisateur doit être configuré dans MongoDB Atlas pour accepter l'authentification SCRAM.

mot de passe

Le mot de passe actuel de l'utilisateur de la base de données MongoDB Atlas.

URL du cluster

Le nom d'hôte du cluster MongoDB Atlas, par exemple. cluster0.abc123.mongodb.net N’incluez pas le préfixe mongodb+srv://. Ceci est utilisé pour vérifier le nouveau mot de passe lors de la rotation.

databaseName

Base de données d'authentification dans laquelle sont stockées les informations d'identification de l'utilisateur. Généralement admin pour les utilisateurs de SCRAM ou $external pour X.509/LDAP.

groupId

L'identifiant hexadécimal du projet Atlas à 24 caractères (également appelé ID de groupe). Vous pouvez le trouver dans les paramètres de votre projet Atlas.

Champs de métadonnées secrets

Les champs de métadonnées pour l'utilisateur de la base de données MongoDB Atlas sont les suivants :

{ "adminSecretArn": "arn:aws:secretsmanager:us-east-1:111122223333:secret:MongoDBAtlasServiceAccount", "apiVersion": "2025-03-12" }
administrateur SecretArn

Le nom de ressource Amazon (ARN) pour le secret qui contient les informations d'identification OAuth du compte de service Atlas (type : MongoDBAtlasServiceAccount) avec les autorisations d'administrateur d'accès à la base de données de projet. Ce secret d'administration est utilisé pour s'authentifier auprès de l'API Atlas Admin pour les mises à jour des mots de passe.

Version de l'API

(Facultatif) La date de version de l'API Atlas Admin au yyyy-mm-dd format. Cette valeur est utilisée dans l'Accepten-tête sous la formeapplication/vnd.atlas.{apiVersion}+json. La valeur par défaut est 2025-03-12 si elle n'est pas précisée.

Flux d'utilisation

Ce type de rotation utilise une architecture à deux secrets. Un code secret d'administration contenant les informations d'identification OAuth du compte de service Atlas (clientId,clientSecret,serviceAccountId) est requis pour s'authentifier auprès de l'API Atlas Admin. Le secret d'administration doit être de type MongoDBAtlasServiceAccount.

Vous pouvez créer votre secret à l'aide de l'CreateSecretappel dont la valeur secrète contient les champs mentionnés ci-dessus et tapez le secret comme MongoDBAtlasDatabaseUser. Les configurations de rotation peuvent être définies à l'aide d'un RotateSecret appel. Vous devez fournir les métadonnées adminSecretArn dans la rotation. Vous devez également fournir un ARN de rôle dans l'RotateSecretappel qui accorde au service les autorisations requises pour alterner le secret. Pour un exemple de politique d'autorisations, voir Sécurité et autorisations.

Étant donné que le secret d'administrateur est d'un type différent (MongoDBAtlasServiceAccount) de celui de l'utilisateur (MongoDBAtlasDatabaseUser), la politique de rôle de rotation par défaut définie n'secretsmanager:resource/Typeaccordera pas l'accès au secret d'administrateur. Vous devez fournir explicitement au rôle de rotation l'accès au secret d'administrateur en ajoutant une instruction limitée au MongoDBAtlasServiceAccount type ou en spécifiant l'ARN du secret d'administration directement dans la politique de rôle.

Pendant la rotation, le pilote génère un nouveau mot de passe, appelle l'API Atlas Admin pour mettre à jour le mot de passe de l'utilisateur de la base de données et vérifie le nouveau mot de passe en ouvrant une véritable connexion MongoDB au cluster. Notez qu'il y a un délai de propagation de 5 à 10 secondes après la mise à jour du mot de passe avant que le nouveau mot de passe ne soit accepté par la couche d'authentification du cluster.