Para agentes de IA: um índice de documentação está disponível em https://www.mongodb.com/pt-br/docs/llms.txt — as versões de markdown de todas as páginas estão disponíveis anexando .md a qualquer caminho de URL.
Menu Docs

Métodos de autenticação da Administration API do Atlas

Importante

Recomendamos que você utilize contas de serviço em vez de chaves API para autenticar na Atlas Administration API. As chaves de API são um método de autenticação legado.

Para utilizar a Atlas Administration API para gerenciar seus clusters do Atlas, você deve autenticar suas solicitações de API. A Administration API aceita os seguintes métodos de autenticação:

Para aprender a usar contas de serviço e chaves de API para configurar o acesso programático a suas organizações e projetos do Atlas, consulte o guia de primeiros passos da Atlas Administration API.

A Atlas Administration API não fornece acesso aos dados armazenados em seus clusters. Para ler ou gravar dados em um banco de dados, você deve autenticar em seu cluster usando as credenciais de um usuário de banco de dados com as funções de leitura ou gravação apropriadas. Você pode utilizar a Atlas Administration API para criar e gerenciar usuários de banco de dados.

Observação

Muitos URLs de endpoint da API de administração do Atlas seguem o formato de /api/atlas/<version>/groups/<GROUP-ID>/, em que <GROUP-ID> é o ID do projeto. Para esses recursos, a conta de serviço ou as chaves de API que você usa para autenticar a solicitação devem ser um membro da organização que hospeda o projeto. Caso contrário, o Atlas responde com um erro 401.

As seções a seguir descrevem os métodos de autenticação da Administration API Atlas:

Service accounts are the recommended method to manage authentication to the Atlas Administration API. Service accounts provide improved security over API keys by using the industry standard OAuth 2.0 protocol with the Client Credentials flow.

A service account lets you manage permissions and create access tokens that authenticate API requests. Each service account has a client ID and a rotatable secret that function as a username and a password for creating access tokens. To learn how to construct an API request with an access token, see Make an API Request.

Dica

Melhores práticas de token de conta de serviço

Considere as seguintes melhores práticas ao usar tokens de conta de serviço:

  • Reutilizar tokens: os tokens de acesso da conta de serviço têm uma vida útil de 1 hora (3600 segundos), durante a qual você pode reutilizar o token várias vezes. Evite criar novos tokens para cada solicitação.

  • Gere novos tokens quando necessário: embora não seja possível atualizar um token de acesso, você pode gerar um novo token quando o token atual estiver próximo do vencimento. Isso evita interrupções de serviço e permite que você mantenha o acesso autorizado à conta de serviço.

  • Revogue tokens desnecessários: Quando você não precisar mais de um token, revogue o acesso do token para minimizar os riscos de segurança e garantir que apenas tokens ativos tenham acesso à sua conta de serviço.

Cada conta de serviço pertence a exatamente uma organização, e você pode conceder acesso a qualquer número de projetos dentro dessa organização. Para conceder acesso a uma conta de serviço em nível de organização a um projeto, consulte Conceder acesso a uma conta de serviço existente a um projeto.

Atlas funções limitam quais operações uma conta de serviço pode autenticar com seu token de acesso. Você deve atribuir funções às contas de serviço, como faria com os usuários, para garantir que a conta de serviço gere tokens de acesso com as permissões necessárias para as chamadas de API desejadas.

Importante

If a project-level service account has access to the organization or to other projects, you must have the Organization Owner role to manage its lifecycle, including rotating or revoking its secrets.

Você não pode usar uma conta de serviço ou seu token de acesso para fazer login no Atlas por meio da IU do Atlas. As contas de serviço só concedem acesso à Atlas Administration API, que não inclui acesso à IU ou acesso a dados do cluster. Para saber mais sobre as limitações das contas de serviço, consulte Limites e Limiares do MongoDB.

Importante

Recomendamos que você utilize contas de serviço em vez de chaves API para autenticar na Atlas Administration API. As chaves de API são um método de autenticação legado.

As chaves de API são um método legado de autenticação para a Atlas Administration API que utiliza autenticação Digest HTTP.

As chaves de API têm duas partes: uma chave pública e uma chave privada. Eles servem a mesma função que um nome de usuário e uma senha para autenticar solicitações de API. Para aprender como construir uma solicitação de API usando chaves de API, consulte Criar uma solicitação de API.

O Atlas realiza o hash da chave pública e da chave privada usando um valor exclusivo chamado nonce. O nonce só é válido por um curto período de tempo, de acordo com a especificação de autenticação de resumo HTTP. Essa vida útil limitada protege contra ataques de repetição, onde um invasor armazena em cache uma chave privada para usá-la sem restrição de tempo.

Cada par de chaves de API pertence a apenas uma organização e pode conceder acesso a qualquer quantidade de projetos nessa organização. Para conceder acesso a chaves de API em nível de organização a um projeto, consulte Conceder acesso a uma conta de serviço existente a um projeto.

Atlas funções limitam quais operações as chaves de API podem executar. Você deve atribuir funções às chaves de API, como faria com os usuários, para garantir que as chaves de API tenham as permissões necessárias para as chamadas de API desejadas.

Você não pode usar chaves de API para fazer login no Atlas por meio da IU do Atlas. As chaves de API concedem apenas acesso à API de Atlas Administration API, que não inclui acesso à IU ou acesso a dados do cluster.

Para aprender como usar e gerenciar contas de serviço e chaves de API, consulte os seguintes procedimentos: