Docs Menu
Docs Home
/ /
Atlas Architecture Center
/

Atlas の認証と承認に関するガイダンス

認証は、ユーザーの身元を確認するプロセスです。Atlas は、アクセスを決定するためにすべてのユーザーに認証を要求します。

認証と承認は密接に関連していますが、以下に示すように認証は承認とは異なります。

  • 認証はユーザーの身元を確認します。

    Atlas は、既存の ID システムとシームレスに統合される堅牢な認証メカニズムを提供し、強力な ID フェデレーションを通じて UI、データベース、API への安全なアクセスを提供します。認証を設定することで、MongoDB Atlas クラスターへのアクセスを管理できます。

  • 承認は、リソースと操作に対する確認済みユーザーのアクセス権が決まります。

    Atlas では、Atlas へのアクセスを管理するための RBAC(Role-Based Access Control、ロールベースのアクセス制御)が提供されます。ユーザーには、データベース リソースおよび操作へのユーザーのアクセス権を決定する 1 つ以上のロールを付与する必要があります。割り当てられたロール以外では、ユーザーはシステムにアクセスできません。

MongoDB Atlas は、堅牢なセキュリティを確保するためにさまざまな認証方法をサポートしています。

  • ユーザー認証のベストプラクティスは、OpenID Connect(OIDC)またはSAML 2.0を使用したフェデレーティッド認証を通じて、AtlasとIdPとのシームレスな統合を活用し、多要素認証(MFA)でセキュリティを強化して、現代的な認証とセキュリティの姿勢を確保することです。

  • ワークロード認証の場合、Atlas は OAuth2.0 をサポートしているため、承認サービスとのシームレスな互換性を可能にし、フェデレーティッド IdP への統合を実現します。

Atlas では、 Atlas UI、 Atlas データベース、 Atlas Administration APIにアクセスするためにすべてのユーザーに認証が必要です。各 Atlasリソースに対する次の認証方法により、認証が安全であり、適応型であることが保証されます。Atlas は、次の認証メカニズムを提供します。

Atlas UIアクセスにはフェデレーティッド認証を推奨します。フェデレーティッド認証を設定するには、 Atlas の認証情報を作成する か、 Google またはGithubでログする 必要があります 。

Atlas の認証情報には、 biometrics など、暗号化に耐性のある MFA を備えた強力なパスワードを使用することをお勧めします。アカウントのロックアウトを回避するために、セカンダリ MFA 係数を設定することを強くお勧めします。Atlas 認証情報の MFA アクセスを確保するには、 組織設定 で MFA の適用を有効にします。ドメインのフェデレーションを設定したら、フェデレーション認証が中断された場合の緊急事態でのみ認証するために、Atlas の認証情報を使用する必要があります。

フェデレーション認証を使用すると、中央の IdP を通じて、複数のシステムやアプリケーションにわたる Atlas UI へのすべての認証を管理できます。UI アクセスの場合、Atlas はSAML 2.0 を使用した Workforce Identity Federation をサポートしています。Okta、Microsoft Entra ID、Ping Identity などの SAML 互換の IdP を使用して、パスワードの複雑さ、認証情報のローテーション、MFA などのセキュリティポリシーを IdP 内で強制できます。

ユーザーとアプリケーションサーバーを含むIP範囲からの接続のみを許可するには、Atlas UIでIP アクセス リストを設定する必要があります。

詳細については「フェデレーション認証の設定」を参照してください。

Atlas コントロール プレーンにアクセスするすべての人間ユーザーは、セキュリティを強化するために MFA を必要とすることをお勧めします。MFA が有効になっている場合、Atlas では次の 2 つの形式の ID が必要です。

  • ユーザーの認証情報

  • 次の推奨要素のいずれか:

    • セキュリティキー

    • 生体認証

    • OTP 認証子

    • プッシュ通知

    • SMS (プライマリ要素としては推奨されません)

    • メール(プライマリ要素としては非推奨)

詳細は、「多要素認証オプションを管理する」を参照してください。

Atlas はさまざまなデータベース認証メカニズムをサポートしています。

MongoDB Shell や Compass などのツールを介して Atlasデータベースへのワークフォース(人間のユーザー)アクセスを構成するには、 Workforce IdP と OIDC を使用します。

MongoDB ドライバーを使用してAtlas データベースへのワークロード(アプリケーション)アクセスを設定するには、Workload Identity Federation、AWS-IAM 認証、または X.509 証明書認証を使用します。SCRAM パスワード認証は、開発環境またはテスト環境でのみ使用することをお勧めします。

Atlas は以下もサポートしています。

Workforce IdP を使用すると、 IdPを介して Atlasデータベースへのすべての認証を管理できます。データベースにアクセスするには、 Okta 、 Microsoft Entra ID、または Ping Identity などの OIDC 互換の ID プロバイダーを使用して、パスワードの複雑さ、認証情報のローテーション、MFA などのセキュリティ ポリシーをIdP内に適用することをお勧めします。

詳細については、「OIDC を使用した Workforce Identity Federation の設定」を参照してください。

Workload Identity Federation を使用すると、Azure や Google Cloud などのクラウド環境で実行されているアプリケーションが、データベースユーザーの認証情報を個別に管理することなく Atlas で認証できます。Workload Identity Federation を使用すると、Azureマネージド ID、Google サービスアカウント、または任意の OAuth 2.0 準拠のサービスを使用して、Atlas データベースユーザーを管理できます。これらの認証メカニズムは、Atlas データベースへのパスワードレス アクセスを可能にすることで、管理を簡素化し、セキュリティを強化します。

本番環境で実行されるすべてのアプリケーションには、Workload Identity Federation をお勧めいたします。最も極端な緊急事態の場合を除いて、人間のユーザーが接続することを許可すべきではありません。

Amazon Web Services IAM ロール を介して認証することもできます。

詳細については、以下をご覧ください。

Atlas のコントロールプレーンおよびデータプレーンの全体に対するセキュリティとアクセスの容易さのために、IdP を介して Workforce Identity Federation または Workload Identity Federation を使用することをお勧めします。

フェデレーション用の IdP がない場合、Atlas クラスターはユーザー認証用に X.509 クライアント証明書もサポートします。X.509 証明書は相互 TLS のセキュリティを提供するため、ステージングおよび本番環境に適しています。また、X.509 で使用するために独自の認証局を持ち込むことができます。X.509 の欠点は、証明書とそのセキュリティをアプリケーション側で管理しなければならないことです。一方、Workload Identity Federation を使用すると、パスワードレスのアクセスが可能になり、アプリケーションのセキュリティが容易になります。

Atlas クラスターはユーザー認証に SCRAM パスワード認証もサポートしていますが、SCRAM は開発環境とテスト環境でのみ使用することをお勧めします。

X.509 または SCRAM 認証を利用する場合は、HashiCorp Vault または AWS Secrets Manager などのサードパーティーのシークレット マネージャーを使用して、複雑なデータベース認証情報を生成および保存することをお勧めします。

詳細については、次のマニュアル ページをご覧ください。

Atlas は、事前定義された時間後に自動的に期限切れとなる一時的なデータベースユーザーの作成をサポートしています。ユーザーを作成できる期間は以下の通りです。

  • 6 時間

  • 1 日

  • 1 週間

詳細については、「データベースユーザーの設定」を参照してください。

複雑なデータベース認証情報を生成して保存するには、HashiCorp VaultAmazon Web Services Secrets Manager などのサードパーティのシークレット マネージャーを使用することをお勧めします。シークレット マネージャーは、Atlas データベースの構成されたロールに基づいてデータベース認証情報を動的に生成できます。

詳細については、ブログの「HashiCorp Vault で MongoDB Atlas データベースのシークレットを管理する」を参照してください。

Atlas は、Atlas Administration API に対して、次の 2 つの認証方法を提供します。

サービス アカウントは業界標準の OAuth2.0 を使用して、Atlas Administration API を介して Atlas へのセキュアな認証を行います。可能な限り API キーの代わりにサービスアカウントの使用を推奨します。これは、短期間のアクセストークンと必須の認証情報ローテーションにより、セキュリティが強化されるためです。

サービス アカウントへのプログラムによるアクセスは、Atlas UI または Atlas Administration API でのみ管理できます。Atlas CLI または Terraform を使用して、サービス アカウントへのプログラムによるアクセスを管理することはできません。

詳細については、「サービス アカウントの概要」を参照してください。

サービス アカウントを使用しない場合は、APIキーベースの認証を使用して、プログラムによるアクセスを安全に管理できます。APIキーベースの認証では、リクエストを保護するためにHTTPダイジェスト認証を使用します。API公開キーはユーザー名として機能し、対応する秘密キーはパスワードとして機能します。これらのキーは、Amazon Web Services Secrets Manager や HashiCorp Vault などのサードパーティのシークレット管理システムに保存する必要があります。これらのキーを Vault に安全に保存する方法については、ブログ「HashiCorp Vault でMongoDB Atlasデータベース シークレットを管理する」を参照してください。

セキュリティをさらに強化し、不正アクセスのリスクを最小限に抑えるためには:

詳細については、「Atlas Administration API 認証」を参照してください。

認証に関連する配置の推奨事項については、「Atlas の組織、プロジェクト、およびクラスターに関するガイダンス」を参照してください。

すべてのリソースにわたるアクセスを効果的に管理するには、Atlas の堅牢なロールベース アクセス制御(RBAC)を実装する必要があります。Atlas には、Atlas コントロール プレーンの管理に一般的に必要なさまざまなレベルのアクセスを提供する 組み込みロール が含まれています。データプレーン内の Atlas クラスターに接続する場合は、データベースのきめ細かなカスタムロールを使用して、ロールがその機能を実行するために必要なデータアクセスへのアクセスに基づいて詳細なスコープを指定することをお勧めします。このアプローチでは、最小特権の原則に従うことができます。

さらに、Atlas をフェデレーション IdP と統合することにより、IdP グループを Atlas ロールにマッピングして、ジャストインタイム プロビジョニングを利用できます。これによりアクセス管理が効率化され、プラットフォーム全体で安全で整理されたロール割り当てが保証されます。オーケストレーション レイヤーのプロビジョニング プロセスに基づいて、プログラムでアクセスを許可することができます。

一般に、上位環境へのアクセスは、セキュリティと確定的な結果がテストされているスクリプトを持つプログラム サービス アカウントのみに制限することをお勧めします。人間によるアクセスは、開発およびテスト中の低い環境でのみ許可される必要があります。

ユーザー、サービスアカウント、およびAPIキーを事前定義されたロールに割り当てて、Atlas 組織もしくはプロジェクト、またはその両方で実行できるアクションを指定できます。IdP を使用して、グループ ロール マッピングを通じてIdPグループを Atlas ロールにリンクしてアクセスを管理します。

Azure Entra ID、Okta、Ping Identity などの SAML をサポートする最新のフェデレーティッド ID プロバイダー(IdP)を使用することを推奨します。これにより、認可プロセスがより安全になり、IdP グループを Atlas ロールにプログラムで割り当てるために必要な柔軟性がサポートされます。お客様の会社のドメインを制限して、アクセスが許可されていない場合にユーザーが Atlas にログインできないようにする必要があります。これは「フェデレーション認証のドメインマッピングを管理する」の手順に従うことで実行できます。ここからは、ロール マッピング プロセス に示されているように、 IdP グループを Atlas ロールにマッピングすることを推奨します。

Atlas の標準的な階層に従って、各事業部または部門がリンクされた単一の課金組織を持っている場合、組織のユーザーを運用チームまたはプラットフォーム チームの管理者に限定する必要があります。それとは対照的に、アプリケーションの開発を担当する開発チームまたは製品チームに対してプロジェクトのロールを割り当てる必要があります。上位環境では、プログラムによるアクセスのみが許可される必要があります。最も一般的に使用されるロールに関する次の推奨事項は、全般的なガイドラインとして役立ちます。

  • Organization Owner ロールは、組織全体の設定を変更したり、構成を削除したりする能力があるため、厳しく制限し、単独の個人には割り当てません。このロールは、組織の初期設定と構成のためにのみ使用するサービスアカウントに割り当てる必要があります。初期作成後は、構成の変更を最小限に抑えてください。アカウントのロックアウトを回避するために、次の項目を作成できます。

    • Just-in-Timeアクセスを持つ SAML 組織オーナー グループ。

    • 組織所有者のロールを持つAPIキー。壊れた緊急事態で強力なアクセス管理を使用して、安全な場所に保管します。

  • Organization Member ロールは、組織の設定や構成を表示できる運用およびプラットフォーム チームの管理者向けである必要があります。

  • Organization Project Creator ロールは、開発チームと製品チームの新しいアプリケーションに代わってプロジェクトを作成するために使用されるプログラムによるサービス アカウントです。

  • Organization Billing Admin ロールは、請求APIからプログラムによって請求書を取得し、FinOps ツールに入力するために使用されるプログラムによるサービス アカウントです。このサービス アカウントは、使用状況の報告を担当するリンクされた組織すべてにアクセスできる必要があります。

  • Project Owner ロールは、 操作およびプロビジョニングチームによって強制されるガバナンスに使用する必要があります。クラスターを作成および削除する能力があるため、このロールをプログラム サービス アカウントに割り当てます。サンドボックス環境の場合、 ユーザーに Project Owner アクセス権を付与すると、オーケストレーション配置パイプラインを通過せずに、コードやユースケースをテストするためのクラスターを迅速にプロビジョニングできるようにすることを検討できます。

  • 下位環境では、Project Data Access Admin ロールを使用してアプリケーションの開発チームにアクセス権を付与し、開発中およびテスト中にクラスターのクエリとパフォーマンス メトリクスにアクセスできるようにします。このアクセス権により、開発チームは Data Explorer を使用してデータの問題をデバッグすることができます。本番環境ではこのロールを許可しないでください。このロールでは、クラスター上でデータベース、コレクション、インデックスの作成や削除を含むデータの表示および編集が可能です。これは迅速な実験や開発に役立ちます。開発チームに対して開発環境でこのレベルのアクセス権を与えることに抵抗がある場合は、Project Data Access Read Only ロールを使用してクラスターのデータおよびパフォーマンス統計への読み取り専用のアクセス権を付与できます。

    本番環境でクラスターのデータに読み取り専用アクセスを許可するには、Project Observability Viewer ロールを使用してください。

詳しくは、「Atlas user ロール」を参照してください。

Workforce ユーザーおよび Workload ユーザーには、特定のプロジェクトや個々のクラスターに合わせた権限を持つ、事前定義またはカスタムのきめ細かなデータベース ロールを割り当てることができます。ステージング環境と本番環境では、IdP(Identity Provider、アイデンティティ プロバイダー)を Atlas にリンクすることで、ID フェデレーションを使用してアクセス管理を合理化し、データアクセスの認証と承認のフローをより現代的で効率的にすることをお勧めします。

IdP グループ メンバーシップ を構成すると、グループをデータベースユーザーにマッピングでき、 IdP 内でのアクセス制御が簡素化されます。ただし、ワークロードID の場合は、groups ではなく users クレームを使用してロールを直接割り当てることをお勧めします。開発環境およびテスト環境では、開発およびテスト プロセスを簡素化するために、事前定義された readWriteAny ロールをデフォルトで使用できます。アプリケーションを上位の環境に移動する場合は、最小特権の原則に基づいてアプリケーションサーバーが持つアクセスを制限するために、カスタムロールをビルドする必要があります。

詳細については、以下をご覧ください。

Github のすべての柱にわたるステージングおよび本番環境における推奨事項を実行するための Terraform の例を参照してください。

次の例では、オートメーション用の Atlas ツール を使用して認証とカスタムロールを構成します。

指定したクラスターに IAM 認証情報を使用したユーザー認証を作成するには、次のコマンドを実行します。

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

次の コマンドを実行して、 SCRAM認証の一時ユーザーを作成します。

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

次のコマンドを実行して、OIDC で Workforce IdP を構成します。

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"

次の例は、認証と承認を構成する方法を示しています。Terraform でリソースを作成する前に、次のことを行う必要があります。

  • 支払い組織を作成し、その支払い組織の API キーを作成します。ターミナルで次のコマンドを実行し、API キーを環境変数として保存します。

    export MONGODB_ATLAS_PUBLIC_KEY="<insert your public key here>"
    export MONGODB_ATLAS_PRIVATE_KEY="<insert your private key here>"
  • Terraform のインストール

の例ごとに次のファイルを作成する必要があります。各例のファイルを 独自のディレクトリに配置します。ID と名前を変更して、 値を使用します。次に、コマンドを実行して Terraform を初期化し、Terraform プランを表示して変更を適用します。

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"]

次の を使用して、ユーザー名とパスワード認証 を持つ Atlas ユーザーを作成します。

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 }

次の例を使用して、OIDC フェデレーティッド IdP を Atlas に設定し、Azure で使用し、OIDC フェデレーション認証ユーザーを作成します。Azure Active Directory によって発行された OIDC トークンを使用してアクセスを許可します。

# 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
}

次の を使用して、ユーザーにはクラスターの管理者権限と、クラスター内のプロジェクトのプロジェクトノードの権限を付与します。

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"
}
}

次のコマンドを実行して、IdP 内の特定のグループからデータベースユーザーを作成します。ユーザーの認証と認可は、 IdPである Okta が管理します。コマンドは、IdPグループ内のユーザーに Atlas クラスターに対する dbAdmin 特権と readWrite 特権も付与します。

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

次のコマンドを実行して、フェデレーション設定から OIDC 互換の ID プロバイダーを作成します。

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"

次の例は、認証と承認を構成する方法を示しています。Terraform でリソースを作成する前に、次のことを行う必要があります。

  • 支払い組織を作成し、その支払い組織の API キーを作成します。ターミナルで次のコマンドを実行し、API キーを環境変数として保存します。

    export MONGODB_ATLAS_PUBLIC_KEY="<insert your public key here>"
    export MONGODB_ATLAS_PRIVATE_KEY="<insert your private key here>"
  • Terraform のインストール

の例ごとに次のファイルを作成する必要があります。各例のファイルを 独自のディレクトリに配置します。ID と名前を変更して、 値を使用します。次に、コマンドを実行して Terraform を初期化し、Terraform プランを表示して変更を適用します。

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"
}

Atlas で OIDC フェデレーション IdP を設定し、Azure で使用するには、次の手順を使用します。Azure Active Directory によって発行された OIDC トークンを使用してアクセスを許可します。

# 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]
}

以下を使用して、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"
}
}

次の例を使用して、my_custom_role という名前のカスタムロールを作成します。これにより、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"
}
}
}

Atlas ロールが特定のグループに割り当てられた Atlasプロジェクトの例については、「例」を参照してください。

戻る

ネットワークセキュリティ

項目一覧