As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.

# Usuário do banco de dados MongoDB Atlas
<a name="mes-partner-MongoDBAtlasDatabaseUser"></a>

## Campos de valor secreto
<a name="w2aac25c11c21b3"></a>

A seguir estão os campos que devem estar contidos no segredo do Secrets Manager:

```
{
  "username": "database username",
  "password": "database password",
  "clusterUrl": "cluster hostname",
  "databaseName": "authentication database",
  "groupId": "Atlas Project ID"
}
```

username  
O nome de usuário do banco de dados MongoDB (autenticado por SCRAM). Esse usuário deve estar configurado no MongoDB Atlas para aceitar a autenticação SCRAM.

password  
A senha atual do usuário do banco de dados MongoDB Atlas.

URL do cluster  
O nome do host do cluster MongoDB Atlas, por exemplo. `cluster0.abc123.mongodb.net` Não inclua o prefixo `mongodb+srv://`. Isso é usado para verificar a nova senha durante a rotação.

databaseName  
O banco de dados de autenticação em que as credenciais do usuário são armazenadas. Normalmente `admin` para usuários de SCRAM ou `$external` para X.509/LDAP.

groupId  
O ID hexadecimal do projeto Atlas de 24 caracteres (também conhecido como ID de grupo). Você pode encontrar isso nas configurações do seu projeto Atlas.

## Campos de metadados secretos
<a name="w2aac25c11c21b5"></a>

A seguir estão os campos de metadados do MongoDB Atlas Database User:

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

adminSecretArn  
O Amazon Resource Name (ARN) do segredo que contém as OAuth credenciais da conta de serviço Atlas (tipo: Mongo DBAtlasServiceAccount) com permissões de administrador de acesso ao banco de dados do projeto. Esse segredo do administrador é usado para se autenticar na API Atlas Admin para atualizações de senha.

apiVersion  
(Opcional) A data da versão da API Atlas Admin em `yyyy-mm-dd` formato. Esse valor é usado no `Accept` cabeçalho como`application/vnd.atlas.{apiVersion}+json`. O padrão é `2025-03-12`, se não for especificado.

## Fluxo de uso
<a name="w2aac25c11c21b7"></a>

Esse tipo de rotação usa uma arquitetura de dois segredos. É necessário um segredo administrativo contendo as OAuth credenciais da conta de serviço Atlas (`clientId``clientSecret`,,`serviceAccountId`) para se autenticar na API Atlas Admin. O segredo do administrador deve ser do tipo Mongo DBAtlasServiceAccount.

Você pode criar seu segredo usando a [CreateSecret](https://docs.aws.amazon.com/secretsmanager/latest/apireference/API_CreateSecret.html)chamada com o valor secreto contendo os campos mencionados acima e o tipo de segredo como Mongo DBAtlasDatabaseUser. As configurações de rotação podem ser definidas usando uma [RotateSecret](https://docs.aws.amazon.com/secretsmanager/latest/apireference/API_RotateSecret.html)chamada. Você deve fornecer os metadados `adminSecretArn` na rotação. Você também deve fornecer um ARN de função na [RotateSecret](https://docs.aws.amazon.com/secretsmanager/latest/apireference/API_RotateSecret.html)chamada que conceda ao serviço as permissões necessárias para alternar o segredo. Para obter um exemplo de política de permissões, consulte [Segurança e permissões](mes-security.md).

Como o segredo do administrador é de um tipo diferente (Mongo DBAtlasServiceAccount) do segredo do usuário (Mongo DBAtlasDatabaseUser), a política de função de rotação padrão definida pelo `secretsmanager:resource/Type` escopo não concederá acesso ao segredo do administrador. Você deve fornecer explicitamente à função rotativa o acesso ao segredo do administrador adicionando uma declaração com escopo ao DBAtlas ServiceAccount tipo Mongo ou especificando o ARN do segredo do administrador diretamente na política de função.

Durante a rotação, o driver gera uma nova senha, chama a API Atlas Admin para atualizar a senha do usuário do banco de dados e verifica a nova senha abrindo uma conexão real do MongoDB com o cluster. Observe que há um atraso de propagação de 5 a 10 segundos após a atualização da senha antes que a nova senha seja aceita pela camada de autenticação do cluster.