Menu Docs

Orientações para autorização e autenticação do Atlas

Autenticação é o processo de verificar a identidade de um usuário. O Atlas exige que todos os usuários se autentiquem para determinar seu acesso.

Embora a autenticação e a autorização estejam intimamente conectadas, a autenticação é distinta da autorização:

  • A autenticação verifica a identidade de um usuário.

    O Atlas fornece mecanismos de autenticação robustos que se integram totalmente aos seus sistemas de identidade existentes, garantindo acesso seguro à IU, ao banco de dados e às APIs por meio de uma forte federação de identidade. Para gerenciar o acesso aos clusters do MongoDB Atlas, configure a autenticação.

  • A autorização determina o acesso do usuário verificado a recursos e operações.

    O Atlas fornece o Controle de acesso baseado em função (RBAC) para controlar o acesso ao Atlas. Você deve conceder a um usuário uma ou mais funções que determinam o acesso do usuário aos recursos e operações do banco de dados. Fora das atribuições de função, o usuário não tem acesso ao sistema.

O MongoDB Atlas aceita uma variedade de métodos de autenticação para garantir uma segurança robusta.

  • A melhor prática para autenticação de usuários é utilizar a integração perfeita do Atlas com provedores de identidade usando autenticação federada por meio do OpenID Connect (OIDC) ou SAML 2.0, e aprimorar a segurança com a Autenticação multifator (MFA) para garantir uma postura moderna de autenticação e segurança.

  • Para autenticação de carga de trabalho, o Atlas oferece suporte ao OAuth2.0, permitindo compatibilidade total com serviços de autorização e integração no seu provedor de identidade federado.

O Atlas exige que todos os usuários autentiquem para acessar a UI do Atlas , o banco de dados do Atlas e a API de administração do Atlas . Os seguintes métodos de autenticação para cada recurso do Atlas garantem que a autenticação seja segura e adaptável. O Atlas fornece os seguintes mecanismos de autenticação:

Recomendamos a autenticação federada para o acesso à UI do Atlas . Para configurar a autenticação federada, você deve criar credenciais do Atlas ou fazer login com Google ou Github.

Para credenciais do Atlas, recomendamos que você utilize uma senha forte associada a um MFA, como a biometria. É altamente recomendável que você configure um fator MFA secundário para evitar bloqueios de conta. Para garantir o acesso à MFA para as credenciais do Atlas, ative a imposição de MFA nas Configurações da organização. Depois de configurar a federação para o seu domínio, você deve usar as credenciais do Atlas para autenticar somente nos cenários de quebra de emergência quando a autenticação federada estiver quebrada.

A autenticação federada permite que você gerencie todas as autenticações na IU do Atlas em múltiplos sistemas e aplicativos por meio de um provedor de identidade. Para acesso à IU, o Atlas oferece suporte à federação de identidade da força de trabalho usando SAML 2.0. Você pode usar qualquer provedor de identidade compatível com SAML, como Okta, Microsoft Entra ID ou Ping Identity, para forçar políticas de segurança, como complexidade de senha, rotação de credenciais e MFA no seu provedor de identidade.

Você deve configurar a lista de acesso IP na UI do Atlas para permitir somente conexões de intervalos de IP que incluam seus usuários e servidores de aplicação .

Para saber mais, consulte Configurar autenticação federada.

Para qualquer usuário humano que tenha acesso ao plano de controle do Atlas, recomendamos que você exija MFA para maior segurança. Quando a MFA está habilitada, o Atlas exige duas formas de identificação:

  • As credenciais do usuário

  • Um dos seguintes fatores recomendados:

    • Chaves de segurança

    • Biometria

    • Autenticadores OTP

    • Notificações por push

    • SMS (não recomendado como fator primário)

    • E-mail (não é recomendado como fator primário)

Para aprender mais, consulte Gerenciar suas opções de autenticação multifator.

O Atlas permite vários mecanismos de autenticação de banco de dados .

Para configurar o acesso da força de trabalho (usuário humano) ao seu banco de dados do Atlas por meio de ferramentas como o MongoDB shell e o Compass, use o Workforce Identity Federation com o OIDC.

Para configurar o acesso de carga de trabalho (aplicativo) ao seu banco de dados Atlas usando drivers do MongoDB, utilize a Federação de identidade de carga de trabalho, autenticação AWS-IAM ou autenticação de certificado X.509. Recomendamos a autenticação de senha SCRAM apenas para uso em ambientes de desenvolvimento ou teste.

O Atlas também oferece suporte:

O Workforce Identity Federation permite gerenciar toda a autenticação no banco de dados do Atlas por meio do seu provedor de identidade. Para acesso ao banco de dados, recomendamos provedores de identidade compatíveis com OIDC, como Okta, Microsoft Entra ID ou Ping Identity, para aplicar políticas de segurança, como complexidade de senhas, rotação de credenciais e MFA em seu provedor de identidade.

Para aprender mais, consulte Configurar a Federação de identidades da força de trabalho com o OIDC.

O Workload Identity Federation permite que aplicativos em execução em ambientes de nuvem, como Azure e Google Cloud, autentiquem-se com o Atlas sem a necessidade de gerenciar credenciais de usuário de banco de dados separadas. Com o Workload Identity Federation, você pode gerenciar usuários do banco de dados Atlas usando Azure Managed Identities, Contas de Serviço do Google ou qualquer serviço compatível com OAuth 2.0. Esses mecanismos de autenticação simplificam o gerenciamento e aumentam a segurança ao permitir acesso sem senha ao banco de dados Atlas.

Recomendamos o uso da Federação de identidade de carga de trabalho para todos os aplicativos em execução em produção. Você não deve permitir que usuários humanos se conectem, exceto nos cenários de emergência mais extremos de quebra de vidro.

Você também pode autenticar por meio de funções do Amazon Web Services IAM.

Para aprender mais, consulte o seguinte:

Recomendamos que você utilize a Federação de identidade de força de trabalho ou de carga de trabalho por meio de um provedor de identidade para garantir segurança e facilidade de acesso a todos os aspectos do plano de controle e dados do Atlas.

Se você não tiver um provedor de identidade para federação, os clusters do Atlas também oferecem suporte a certificados de cliente X.509 para autenticação de usuários. Os certificados X.509 oferecem a segurança do TLS mútuo, tornando-os apropriados para ambientes de teste e produção, e é possível utilizar sua própria autoridade certificadora com o X.509. A desvantagem do X.509 é que você deve gerenciar os certificados e a segurança deles no lado do aplicativo, enquanto a Federação de identidade de carga de trabalho permite acesso sem senha e segurança mais fácil do aplicativo.

Os clusters do Atlas também oferecem suporte à autenticação por senha SCRAM para autenticação de usuário, mas recomendamos o uso de SCRAM apenas em ambientes de desenvolvimento e teste.

Se você utilizar a autenticação X.509 ou SCRAM, recomendamos que use um gerente de segredos de terceiros como o HashiCorp Vault ou o AWS Secrets Manager para gerar e armazenar credenciais complexas de banco de dados.

Para aprender mais, consulte as seguintes páginas do manual:

O Atlas também oferece suporte à criação de usuários temporários de banco de dados que expiram automaticamente após os horários predefinidos. Um usuário pode ser criado para os seguintes períodos:

  • 6 horas

  • 1 dia

  • 1 semana

Para saber mais, consulte Configurar usuários do banco de dados.

Recomendamos usar um gerenciador de segredos de terceiros, como o HashiCorp Vault ou o Amazon Web Services Secrets Manager, para gerar e armazenar credenciais complexas de banco de dados. Um gerenciador de segredos pode gerar credenciais de banco de dados dinamicamente com base em funções configuradas para bancos de dados do Atlas .

Para aprender mais, veja o blog Gerenciar segredos do banco de dados MongoDB Atlas no HashiCorp Vault.

O Atlas oferece duas maneiras de autenticação na API de administração do Atlas:

As contas de serviço utilizam o protocolo OAuth 2.0 padrão do setor para autenticar de forma segura no Atlas através da API de administração do Atlas. Recomendamos que você utilize contas de serviço em vez de chaves de API sempre que possível, pois aquelas oferecem maior segurança através do uso de tokens de acesso de curta duração e rotações obrigatórias de credenciais.

As contas de serviço estão disponíveis como um recurso de visualização e você pode gerenciar o acesso programático para contas de serviço somente usando a UI do Atlas ou a API de administração do Atlas . Você não pode gerenciar o acesso de programação para contas de serviço por meio do Atlas CLI ou do Terraform.

Para aprender mais, consulte Visão geral das contas de serviço.

Se você não usar contas de serviço, poderá usar a autenticação baseada em chaves de API para gerenciar com segurança o acesso programático. A autenticação baseada em chave de API usa a autenticação HTTP Digest para proteger as solicitações. A chave pública da API funciona como o nome de usuário e a chave privada correspondente serve como a senha. Você deve armazenar essas chaves em um sistema de gerenciamento de segredos de terceiros, como o Amazon Web Services Secrets Manager ou o HashiCorp Vault. Para saber como armazenar essas chaves com segurança no Vault, consulte o blog Manage MongoDB Atlas Database Secrets in HashiCorp Vault.

Para reforçar ainda mais a segurança e reduzir o risco de acesso não autorizado:

Para saber mais, consulte Autenticação da API de administração do Atlas.

Para conhecer nossas recomendações para implantações, relacionadas à autenticação, consulte Orientações para organizações, projetos e clusters do Atlas.

Você deve implementar o robusto controle de acesso baseado em funções (RBAC) do Atlas para gerenciar com eficiência o acesso a todos os recursos. O Atlas inclui funções internas que fornecem diferentes níveis de acesso comumente necessários para gerenciar o plano de controle do Atlas . Para conectar-se a Atlas clusters no plano de dados, recomendamos o uso de funções personalizadas refinadas do banco de dados para fornecer um escopo granular com base no acesso aos dados necessários para que a função execute sua função. Essa abordagem permite que você siga o princípio do privilégio mínimo.

Além disso, ao integrar o Atlas com um provedor de identidade federado, é possível utilizar o provisionamento just-in-time mapeando grupos do provedor de identidade para funções no Atlas. Isso otimiza o gerenciamento de acesso e assegura atribuições de funções seguras e organizadas em toda a plataforma. Você pode conceder acesso programaticamente com base no processo de provisionamento da camada de orquestração.

Em geral, é uma prática recomendada sempre restringir o acesso aos ambientes superiores apenas a contas de serviço programáticas com scripts testados quanto à segurança e resultados determinísticos. O acesso humano só deve ser permitido em ambientes inferiores durante o desenvolvimento e o teste.

Você pode atribuir usuários, contas de serviço e chaves de API a roles predefinidos, especificando as ações que eles podem executar nas organizações, nos projetos ou em ambos do Atlas . Use o Identity Federation para gerenciar o acesso vinculando seus grupos de provedor de identidade às funções do Atlas por meio de mapeamentos de grupo e função.

Recomendamos que você utilize um provedor de identidade federado (IdP) moderno que ofereça SSO com SAML, como Azure Entra ID, Okta ou Ping Identity, pois isso torna o processo de autorização mais seguro e apoia a flexibilidade necessária para atribuir programaticamente grupos de IdP às funções do Atlas. Você deve restringir o domínio da sua empresa para impedir que os usuários façam login no Atlas quando não estiverem autorizados a acessá-lo, o que pode ser feito seguindo o procedimento em Gerenciar mapeamento de domínio para autenticação federada. Recomendamos que você mapeie seus grupos de provedor de identidade (IdP) para as funções do Atlas, conforme mostrado no Processo de mapeamento de funções.

Se você seguiu a hierarquia padrão do Atlas de uma única organização de faturamento com uma organização vinculada para cada unidade de negócios ou departamento, então deve restringir os usuários da organização aos administradores da equipe de operações ou da plataforma. Em contraste, você deve atribuir funções de projeto às equipes de desenvolvimento ou de produto responsáveis pela construção de aplicativos. Somente o acesso programático deve ser permitido em ambientes de produção. As seguintes recomendações para as funções mais comumente usadas podem servir como uma diretriz geral:

  • A função Organization Owner deve ser fortemente restrita e não deve ser atribuída a um humano, pois possui a capacidade de alterar configurações em toda a organização e excluir configurações. Essa função deve ser atribuída a uma conta de serviço que você usa apenas para parametrizar e configurar inicialmente a organização. Minimize as alterações de configuração após a criação inicial. Para evitar bloqueios de conta, você pode criar os seguintes itens:

    • Grupo de proprietários da organização SAML com acesso jus-in-time.

    • Chave API com o role Proprietário da organização. Mantenha-o em um local seguro com forte gerenciamento de acesso para cenários de emergência de quebra-vidro.

  • A função Organization Member deve ser destinada a administradores da equipe de operações e plataforma que possam visualizar as configurações e definições da organização.

  • A função Organization Project Creator deve ser uma conta de serviço programática usada para criar projetos em nome de novos aplicativos para equipes de desenvolvimento e produto.

  • A função Organization Billing Admin deve ser uma conta de serviço programática usada para extrair faturas programaticamente da API de faturamento e inseri-las em sua ferramenta FindOps. Essa mesma conta de serviço deve ter acesso a todas as organizações vinculadas para as quais é responsável por relatar o uso.

  • A função Project Owner deve ser usada para controle imposto pela equipe de operações e provisionamento. Atribua esta role a uma conta de serviço programática, pois ela tem a capacidade de criar e excluir clusters. Para ambientes de sandbox, você pode considerar conceder a um usuário acesso de Project Owner para permitir que ele provisione rapidamente clusters para teste de código e casos de uso sem passar pelo pipeline de implantação de orquestração.

  • Em ambientes de desenvolvimento, use a função Project Data Access Admin para conceder acesso à equipe de desenvolvimento que está construindo o aplicativo, permitindo que eles acessem as métricas de consulta e desempenho do cluster durante o desenvolvimento e os testes. Esse acesso permite que eles depurem problemas de dados com o Data Explorer. Não permita esta função em ambientes de produção. Ele tem a capacidade de visualizar e editar dados, incluindo a criação e exclusão de bancos de dados, coleções e índices no cluster, o que é útil para experimentação e desenvolvimento rápidos. Caso você não se sinta à vontade para conceder às equipes de desenvolvimento esse nível de acesso no ambiente de desenvolvimento, pode conceder a elas acesso somente para leitura aos dados e estatísticas de desempenho do cluster com a função Project Data Access Read Only.

    Para conceder acesso somente leitura aos dados do cluster em ambientes de produção, use a função Project Observability Viewer.

Para saber mais, consulte Funções de usuário do Atlas.

Usuários de força de trabalho e carga de trabalho podem ser atribuídos a funções de banco de dados detalhadas, predefinidas ou personalizadas, com permissões ajustadas para projetos específicos ou clusters individuais. Em ambientes de staging e produção, recomendamos o uso da Federação de identidade para otimizar o gerenciamento de acesso, vinculando seu provedor de identidade (IdP) ao Atlas, proporcionando um fluxo de autenticação e autorização mais moderno e eficiente para acesso aos dados.

Ao configurar a associação a grupos em seu IdP, você pode mapear grupos para usuários do banco de dados , simplificando o controle de acesso dentro do IdP. No entanto, para identidades de volume de trabalho, recomendamos atribuir funções diretamente usando a declaração users em vez de groups. Em ambientes de desenvolvimento e teste, você pode usar como padrão a função readWriteAny predefinida para simplificar o processo de desenvolvimento e teste. Ao mover o aplicação para ambientes superiores, você deve criar uma função personalizada para restringir o acesso que o servidor de aplicação tem com base no princípio do privilégio mínimo.

Para aprender mais, consulte o seguinte:

Veja exemplos do Terraform para aplicar nossas recomendações de preparação e produção em todos os pilares em um só lugar no Github.

Os exemplos seguintes configuram autenticação e roles personalizados utilizando ferramentas Atlas para automação.

Execute o seguinte comando para criar uma autenticação de usuário com credenciais IAM para um cluster especificado.

atlas dbusers create \
--projectId "6698000acf48197e089e4085" \
--username "MyRoleARN" \
--awsIAMType "ROLE" \
--role "clusterMonitor" \
--scope "myCluster"

Execute o comando a seguir para criar um usuário temporário com autenticação SCRAM.

atlas dbusers create \
--projectId 6698000acf48197e089e4085 \
--username "tempUser" \
--password "securePassword" \
--role "readWrite" \
--scope "myCluster" \
--deleteAfter "2025-02-01T12:00:00Z"

Execute o comando a seguir para configurar a Federação de Identidade do Workforce com o OIDC.

atlas federatedAuthentication federationSettings identityProvider create oidc Azure \
--audience "https://management.azure.com/" \
--authorizationType "USER" \
--desc "oidc-for-azure" \
--federationSettingsId "5d1113b25a115342acc2d1aa" \
--groupsClaim "groups" \
--idpType "WORKFORCE" \
--issuerUri "https://sts.windows.net/" \
--userClaim "sub"

Os exemplos a seguir demonstram como configurar a autenticação e a autorização. Antes de criar recursos com o Terraform, você deve:

  • Crie sua organização pagadora e uma chave de API para a organização pagadora. Armazene sua chave de API como variáveis de ambiente ao executar o seguinte comando no terminal:

    export MONGODB_ATLAS_PUBLIC_KEY="<insert your public key here>"
    export MONGODB_ATLAS_PRIVATE_KEY="<insert your private key here>"
  • Instalar o Terraform

Você deve criar os seguintes arquivos para cada exemplo. Coloque os arquivos de cada exemplo em seu próprio diretório. Altere os IDs e nomes para usar seus valores. Em seguida, execute os comandos para inicializar o Terraform, visualizar o plano do Terraform e aplicar as alterações.

locals {
tags = {
CreatedBy = "Terraform"
Owner = var.owner
Module = "tf-example-oidc-azure"
Name = var.project_name
}
}
resource "azurerm_resource_group" "this" {
name = var.project_name
location = var.location
tags = local.tags
}
resource "azurerm_virtual_network" "this" {
name = var.project_name
address_space = ["10.0.0.0/16"]
location = azurerm_resource_group.this.location
resource_group_name = azurerm_resource_group.this.name
tags = local.tags
}
resource "azurerm_subnet" "internal" {
name = "internal"
resource_group_name = azurerm_resource_group.this.name
virtual_network_name = azurerm_virtual_network.this.name
address_prefixes = ["10.0.2.0/24"]
}
resource "azurerm_public_ip" "vm-public-ip" {
name = "public-ip-${var.project_name}"
location = var.location
resource_group_name = azurerm_resource_group.this.name
allocation_method = "Dynamic"
domain_name_label = var.project_name
tags = local.tags
}
resource "azurerm_network_interface" "this" {
name = "ip-${var.project_name}"
location = var.location
resource_group_name = azurerm_resource_group.this.name
tags = local.tags
ip_configuration {
subnet_id = azurerm_subnet.internal.id
name = "public"
private_ip_address_allocation = "Dynamic"
public_ip_address_id = azurerm_public_ip.vm-public-ip.id
}
}
resource "azurerm_user_assigned_identity" "this" {
location = var.location
name = var.project_name
resource_group_name = azurerm_resource_group.this.name
tags = local.tags
}
resource "azurerm_linux_virtual_machine" "this" {
name = var.project_name
resource_group_name = azurerm_resource_group.this.name
location = var.location
size = "Standard_F2"
admin_username = var.vm_admin_username
custom_data = data.cloudinit_config.this.rendered
network_interface_ids = [azurerm_network_interface.this.id]
tags = local.tags
admin_ssh_key {
username = var.vm_admin_username
public_key = var.ssh_public_key
}
source_image_reference {
publisher = "Canonical"
offer = "0001-com-ubuntu-server-jammy"
sku = "22_04-lts"
version = "latest"
}
os_disk {
storage_account_type = "Standard_LRS"
caching = "ReadWrite"
disk_size_gb = 30
}
identity {
type = "UserAssigned"
identity_ids = [azurerm_user_assigned_identity.this.id]
}
}
variable "user" {
description = "MongoDB Atlas User"
type = list(string)
default = ["dbuser1", "dbuser2"]
}
variable "database_name" {
description = "The Database in the cluster"
type = list(string)
}
variable "org_id" {
description = "MongoDB Organization ID"
type = string
}
variable "project_id" {
description = "MongoDB Atlas Project ID"
type = string
}
variable "connection_strings" {
description = "List of MongoDB connection strings to the cluster"
type = list(string)
}
variable "token_audience" {
description = "The token audience used by the OIDC identity provider"
type = string
default = "https://management.azure.com/" # Example audience
}
variable "trusted_domains" {
description = "List of associated domains to trust"
type = list(string)
default = ["myOrg.com", "another-trusted-domain.org"] # Example domains
}
org_id = "32b6e34b3d91647abb20e7b8"
project_id = "67212db237c5766221eb6ad9"
user = ["testUser"]
database_name = ["myTestDb"]
connection_strings = ["mongodb+srv://cluster0.mongodb.net"]
token_audience = "https://management.azure.com/"
trusted_domains = ["myOrg.com", "example-domain.org"]

Use o seguinte para criar um usuário do Atlas com autenticação de nome de usuário e senha.

locals {
test_user_password = random_password.password.result
}
# Generates 12 characters long random password without special characters
resource "random_password" "password" {
length = 12
special = false
}
resource "mongodbatlas_database_user" "user1" {
username = var.user[0]
password = local.test_user_password
project_id = var.project_id
auth_database_name = "admin"
scopes = var.clusters[0]
roles {
role_name = "readWriteAny"
database_name = var.database_name[0]
}
}
output "user1" { value = mongodbatlas_database_user.user1.username }
output "userpwd" { value = mongodbatlas_database_user.user1.password sensitive = true }

Use o exemplo a seguir para configurar um provedor de identidade federado OIDC no Atlas, para usá-lo com Azure e, em seguida, crie um usuário de autenticação federada OIDC. Ele utiliza tokens OIDC emitidos pelo Azure Active Directory para conceder acesso.

# Connection string to use in this configuration
locals {
mongodb_uri = var.connection_strings[0]
}
# Fetch MongoDB Atlas Federated Settings
data "mongodbatlas_federated_settings" "this" {
org_id = var.org_id
}
# Configure an identity provider for federated authentication
resource "mongodbatlas_federated_settings_identity_provider" "oidc" {
federation_settings_id = data.mongodbatlas_federated_settings.this.id
associated_domains = var.trusted_domains
audience = var.token_audience
authorization_type = "USER"
description = "OIDC Identity Provider for Azure AD"
# Replace with actual Azure Tenant ID
issuer_uri = "https://sts.windows.net/${data.azurerm_client_config.current.tenant_id}/"
idp_type = "WORKFORCE"
name = "OIDC-for-azure"
protocol = "OIDC"
user_claim = "sub" # Claim to extract the user's principal identity
}
resource "mongodbatlas_federated_settings_org_config" "this" {
federation_settings_id = data.mongodbatlas_federated_settings.this.id
org_id = var.org_id
domain_restriction_enabled = false
domain_allow_list = []
data_access_identity_provider_ids = [mongodbatlas_federated_settings_identity_provider.oidc.idp_id]
}
# Create an OIDC-authenticated Database User
resource "mongodbatlas_database_user" "oidc" {
project_id = var.project_id
username = "${mongodbatlas_federated_settings_identity_provider.oidc.idp_id}/${data.azurerm_client_config.current.client_id}"
oidc_auth_type = "USER"
auth_database_name = "$external" # Required when using OIDC for USER authentication
roles {
role_name = "atlasAdmin"
database_name = "admin"
}
}
# Azure-specific data source needed for Tenant ID and Client ID
data "azurerm_client_config" "current" {}
output "vm_fqdn" {
value = azurerm_public_ip.vm-public-ip.fqdn
description = "Fully Qualified Domain Name (FQDN) of the Virtual Machine (VM)"
}
output "ssh_connection_string" {
value = "ssh ${var.vm_admin_username}@${azurerm_public_ip.vm-public-ip.fqdn}"
description = "Useful for connecting to the instance"
}
output "user_test_conn_string" {
value = "mongodb+srv://${var.user[0]}:<password>@${replace(local.mongodb_uri, "mongodb+srv://", "")}/?retryWrites=true"
description = "Connection string for testing regular database user access"
sensitive = true
}
output "user_oidc_conn_string" {
value = "mongodb+srv://${mongodbatlas_database_user.oidc.username}:<OIDCToken>@${replace(local.mongodb_uri, "mongodb+srv://", "")}/?authMechanism=MONGODB-OIDC&retryWrites=true"
description = "Connection string for OIDC-authenticated user"
sensitive = true
}

Use o seguinte para conceder aos usuários direitos de administrador no cluster e direitos de membro do projeto para os projetos no cluster.

resource "mongodbatlas_database_user" "admin_user" {
project_id = "6698000acf48197e089e4085"
username = "adminUser"
password = "securePassword" # Use a secure password
auth_database_name = "admin"
roles {
role_name = "atlasAdmin" # Admin role for the cluster
database_name = "admin"
}
roles {
role_name = "readWriteAnyDatabase" # Project member rights
database_name = "admin"
}
}

Execute o comando a seguir para criar um usuário de banco de dados a partir de um grupo específico no provedor de identidade. Você pode gerenciar a autenticação e a autorização do usuário por meio do provedor de identidade Okta. O comando também concede aos usuários no grupo de provedor de identidade dbAdmin e readWrite privilégios no Atlas cluster.

atlas dbusers create \
--projectId "6698000acf48197e089e4085" \
--username "okta/my-idp-group" \
--role "readWrite,dbAdmin" \
--oidcType "IDP_GROUP"

Execute o comando a seguir para criar um provedor de identidade compatível com OIDCa partir de suas configurações de federação.

atlas federatedAuthentication federationSettings identityProvider create oidc IDPName \
--audience "api://12345678-1234-1234-1234-123456789abc" \
--authorizationType "GROUP" \
--clientId "abcdef12-3456-7890-abcd-ef1234567890" \
--desc "MyOIDCProvider test" \
--federationSettingsId "5d1113b25a115342acc2d1aa" \
--groupsClaim "groups" \
--idpType "WORKLOAD" \
--issuerUri "https://sts.windows.net/12345678-1234-1234-1234-123456789abc/" \
--userClaim "sub" \
--associatedDomain "example.com"

Os exemplos a seguir demonstram como configurar a autenticação e a autorização. Antes de criar recursos com o Terraform, você deve:

  • Crie sua organização pagadora e uma chave de API para a organização pagadora. Armazene sua chave de API como variáveis de ambiente ao executar o seguinte comando no terminal:

    export MONGODB_ATLAS_PUBLIC_KEY="<insert your public key here>"
    export MONGODB_ATLAS_PRIVATE_KEY="<insert your private key here>"
  • Instalar o Terraform

Você deve criar os seguintes arquivos para cada exemplo. Coloque os arquivos de cada exemplo em seu próprio diretório. Altere os IDs e nomes para usar seus valores. Em seguida, execute os comandos para inicializar o Terraform, visualizar o plano do Terraform e aplicar as alterações.

locals {
tags = {
CreatedBy = "Terraform"
Owner = var.owner
Module = "tf-example-oidc-azure"
Name = var.project_name
}
}
resource "azurerm_resource_group" "this" {
name = var.project_name
location = var.location
tags = local.tags
}
resource "azurerm_virtual_network" "this" {
name = var.project_name
address_space = ["10.0.0.0/16"]
location = azurerm_resource_group.this.location
resource_group_name = azurerm_resource_group.this.name
tags = local.tags
}
resource "azurerm_subnet" "internal" {
name = "internal"
resource_group_name = azurerm_resource_group.this.name
virtual_network_name = azurerm_virtual_network.this.name
address_prefixes = ["10.0.2.0/24"]
}
resource "azurerm_public_ip" "vm-public-ip" {
name = "public-ip-${var.project_name}"
location = var.location
resource_group_name = azurerm_resource_group.this.name
allocation_method = "Dynamic"
domain_name_label = var.project_name
tags = local.tags
}
resource "azurerm_network_interface" "this" {
name = "ip-${var.project_name}"
location = var.location
resource_group_name = azurerm_resource_group.this.name
tags = local.tags
ip_configuration {
subnet_id = azurerm_subnet.internal.id
name = "public"
private_ip_address_allocation = "Dynamic"
public_ip_address_id = azurerm_public_ip.vm-public-ip.id
}
}
resource "azurerm_user_assigned_identity" "this" {
location = var.location
name = var.project_name
resource_group_name = azurerm_resource_group.this.name
tags = local.tags
}
resource "azurerm_linux_virtual_machine" "this" {
name = var.project_name
resource_group_name = azurerm_resource_group.this.name
location = var.location
size = "Standard_F2"
admin_username = var.vm_admin_username
custom_data = data.cloudinit_config.this.rendered
network_interface_ids = [azurerm_network_interface.this.id]
tags = local.tags
admin_ssh_key {
username = var.vm_admin_username
public_key = var.ssh_public_key
}
source_image_reference {
publisher = "Canonical"
offer = "0001-com-ubuntu-server-jammy"
sku = "22_04-lts"
version = "latest"
}
os_disk {
storage_account_type = "Standard_LRS"
caching = "ReadWrite"
disk_size_gb = 30
}
identity {
type = "UserAssigned"
identity_ids = [azurerm_user_assigned_identity.this.id]
}
}
# Azure Variables
variable "token_audience" {
type = string
default = "https://management.azure.com/"
description = "Used as resource when getting the access token. See more in the [Azure documentation](https://learn.microsoft.com/en-us/entra/identity/managed-identities-azure-resources/how-to-use-vm-token#get-a-token-using-http)"
}
# MongoDB Atlas variables
variable "org_id" {
type = string
description = "MongoDB Atlas Organization ID"
}
variable "project_id" {
type = string
description = "MongoDB Atlas Project ID"
}
variable "project_name" {
type = string
description = "MongoDB Atlas Project Name"
}
variable "connection_strings" {
type = list(string)
description = "MongoDB Atlas Cluster Standard Connection Strings"
}
org_id = "32b6e34b3d91647abb20e7b8"
project_id = "67212db237c5766221eb6ad9"
project_name = "My Project"
connection_strings =
token_audience = "https://management.azure.com/"
output "vm_fqdn" {
value = azurerm_public_ip.vm-public-ip.fqdn
description = "Fully Qualified Domain Name (FQDN) of the Virtual Machine (VM)"
}
output "ssh_connection_string" {
value = "ssh ${var.vm_admin_username}@${azurerm_public_ip.vm-public-ip.fqdn}"
description = "Useful for connecting to the instance"
}
output "user_test_conn_string" {
value = "mongodb+srv://${local.test_user_username}:${local.test_user_password}@${replace(mongodbatlas_advanced_cluster.this.connection_strings[0].standard_srv, "mongodb+srv://", "")}/?retryWrites=true"
sensitive = true
description = "Useful for connecting to the database from Compass or other tool to validate data"
}
output "user_oidc_conn_string" {
value = local.mongodb_oidc_uri
sensitive = true
description = "Useful to see the format of the OIDC connection string"
}

Use o seguinte para configurar um provedor de identidade federado do OIDC no Atlas, para usá-lo com o Azure. Ele permite o acesso por meio de tokens OIDC emitidos pelo Azure Active Directory.

# Connection string to use in this configuration
locals {
mongodb_uri = var.connection_strings[0]
}
# Atlas organization details to use in the configuration
data "mongodbatlas_federated_settings" "this" {
org_id = var.org_id
name = var.project_name
project_id = var.project_id
}
# Configure an identity provider for federated authentication
resource "mongodbatlas_federated_settings_identity_provider" "oidc" {
federation_settings_id = data.mongodbatlas_federated_settings.this.id
audience = var.token_audience
authorization_type = "USER"
description = "oidc-for-azure"
# e.g. "https://sts.windows.net/91405384-d71e-47f5-92dd-759e272cdc1c/"
issuer_uri = "https://sts.windows.net/${azurerm_user_assigned_identity.this.tenant_id}/"
idp_type = "WORKLOAD"
name = "OIDC-for-azure"
protocol = "OIDC"
# groups_claim = null
user_claim = "sub"
}
resource "mongodbatlas_federated_settings_org_config" "this" {
federation_settings_id = data.mongodbatlas_federated_settings.this.id
org_id = var.org_id
domain_restriction_enabled = false
domain_allow_list = []
data_access_identity_provider_ids = [mongodbatlas_federated_settings_identity_provider.oidc.idp_id]
}

Use o seguinte para criar um usuário de autenticação federado do OIDC.

resource "mongodbatlas_database_user" "oidc" {
project_id = var.project_id
username = "${mongodbatlas_federated_settings_identity_provider.oidc.idp_id}/${azurerm_user_assigned_identity.this.principal_id}"
oidc_auth_type = "USER"
auth_database_name = "$external" # required when using OIDC USER authentication
roles {
role_name = "atlasAdmin"
database_name = "admin"
}
}

Use o seguinte para criar uma função personalizada denominada my_custom_role que permite operações de atualização, adição e exclusão em qualquer coleção no banco de dados denominado myDb.

resource "mongodbatlas_custom_db_role" "create_role" {
project_id = var.project_id
role_name = "my_custom_role"
actions {
action = "UPDATE"
resources {
database_name = "myDb"
}
}
actions {
action = "INSERT"
resources {
database_name = "myDb"
}
}
actions {
action = "REMOVE"
resources {
database_name = "myDb"
}
}
}

Para obter um exemplo de um projeto Atlas com a função Atlas atribuída a um grupo específico, consulte Exemplos.