Atlas の認証と承認に関するガイダンス
項目一覧
認証は、ユーザーの身元を確認するプロセスです。Atlas は、アクセスを決定するためにすべてのユーザーに認証を要求します。
認証と承認は密接に関連していますが、以下に示すように認証は承認とは異なります。
認証はユーザーの身元を確認します。
Atlas は、既存の ID システムとシームレスに統合する堅牢な認証メカニズムを提供し、強力な ID フェデレーションを通じてUI、データベース、およびAPIへの安全なアクセスを提供します。認証を設定することで、 MongoDB Atlasクラスターへのアクセスを管理できます。
承認は、リソースと操作に対する確認済みユーザーのアクセス権が決まります。
Atlas は、Atlas へのアクセスを管理するためのロールベースアクセス制御(RBAC)を提供します。ユーザーには、データベース リソースおよび操作へのユーザーのアクセス権を決定する 1 つ以上のロールを付与する必要があります。割り当てられたロール以外では、ユーザーはシステムにアクセスできません。
Atlas 認証のための機能
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 認証の推奨事項
Atlas UI 認証
Atlas UIアクセスにはフェデレーティッド認証を推奨します。フェデレーティッド認証を設定するには、 Atlas の認証情報を作成する か、 Google またはGithubでログする 必要があります 。
Atlas の認証情報には、 biometrics など、暗号化に耐性のある MFA を備えた強力なパスワードを使用することをお勧めします。アカウントのロックアウトを回避するために、セカンダリ MFA 係数を設定することを強くお勧めします。 Atlas 認証情報の MFA アクセスを確保するには、 組織設定 で MFA の適用を有効にします。ドメインのフェデレーションを設定したら、フェデレーション認証が中断された場合の緊急事態でのみ認証するために、Atlas の認証情報を使用する必要があります。
フェデレーティッド認証
フェデレーション認証は、中央のIdPを通じて、複数のシステムやアプリケーションにまたがるAtlas UIへのすべての認証を管理できます。UIアクセスの場合、Atlas は SAML 2.0 を使用したワークフォースアイデンティティフェデレーションをサポートしています。Okta、Microsoft Entra ID、Ping Identity などの SAML 互換のIdPを使用して、パスワードの複雑さ、認証情報のローテーション、MFA などのセキュリティポリシーをIdP内で強制できます。
ユーザーとアプリケーションサーバーを含むIP範囲からの接続のみを許可するには、Atlas UIでIP アクセス リストを設定する必要があります。
詳しくは、「 フェデレーション認証の構成 」を参照してください。
多要素認証
Atlas コントロール プレーンにアクセスするすべての人間ユーザーは、セキュリティを強化するために MFA を必要とすることをお勧めします。 MFA が有効になっている場合、Atlas では次の 2 つの形式の ID が必要です。
ユーザーの認証情報
次の推奨要素のいずれか:
セキュリティキー
生体認証
OTP 認証子
プッシュ通知
SMS (プライマリ要素としては推奨されません)
メール(プライマリ要因としては推奨されません)
詳細は、多要素認証オプションの管理を参照してください。
Atlas データベースの認証
Atlas はさまざまなデータベース認証メカニズムをサポートしています。
MongoDB Shell や Compass などのツールを介して Atlasデータベースへのワークフォース(人間のユーザー)アクセスを構成するには、 Workforce IdP と OIDC を使用します。
MongoDB ドライバーを使用してAtlas データベースへのワークロード(アプリケーション)アクセスを設定するには、ワークロードIDフェデレーション、AWS-IAM 認証、または X.509 証明書認証を使用してください。SCRAMパスワード認証は、開発環境またはテスト環境でのみ使用することをお勧めします。
Atlas は以下もサポートしています:
Workforce IdP
Workforce IdP を使用すると、 IdPを介して Atlasデータベースへのすべての認証を管理できます。データベースにアクセスするには、 Okta 、 Microsoft Entra ID、または Ping Identity などの OIDC 互換の ID プロバイダーを使用して、パスワードの複雑さ、認証情報のローテーション、MFA などのセキュリティ ポリシーをIdP内に適用することをお勧めします。
詳細については、OIDC を使用した Workforce Identity Federation の設定を参照してください。
Workload Identity Federation とAmazon Web Services IAM ロール認証
Workload Identity Federation を使用すると、 Azureや Google Cloud などのクラウド環境で実行中アプリケーションが Atlas で認証されるため、データベースユーザーの認証情報を個別に管理する必要がなくなります。 Workload Identity Federation を使用すると、 Azure Managed Identity、Google サービス アカウント、または OAuth2.0 準拠のサービスを使用して Atlasデータベースユーザーを管理できます。これらの認証メカニズムにより、Atlas データベースへのスワードレスアクセスが可能になることで、管理が簡素化され、セキュリティが強化されます。
本番環境で実行されるすべてのアプリケーションには、Workload アイデンティティフェデレーションをお勧めいたします。最も極端な緊急事態を除いて、人間のユーザーが接続することを許可すべきではありません。
AWS IAM ロール を介して認証することもできます。
詳細については、以下をご覧ください。
X.509 クライアント証明書と SCRAM
Atlas のコントロールおよびデータプレーンのすべての側面へのセキュリティとアクセスの容易さのために、IdP を介して Workforce またはワークロード Identity Federation を使用することをお勧めします。
フェデレーション用のIdPがない場合、Atlasクラスターはユーザー認証用のX.509クライアント証明書もサポートします。X.509 証明書は相互 TLS のセキュリティを提供するため、ステージングおよび本番環境に適しています。また、X.509 で使用するために独自の認証局を持ち込むことができます。X.509 の欠点は、証明書とそのセキュリティをアプリケーション側で管理しなければならないことです。一方、ワークロードアイデンティティフェデレーションを使用すると、パスワードレスアクセスが可能になり、アプリケーションのセキュリティが容易になります。
Atlas クラスターはユーザー認証にSCRAMパスワード認証もサポートしていますが、SCRAMは開発環境とテスト環境でのみ使用することをお勧めします。
X.509 または SCRAM 認証を利用する場合は、 HashiCorp Vault または AWS Secrets マネージャーなどのサードパーティーのシークレットマネージャーを使用して、複雑なデータベース認証情報を生成および保存することをお勧めします。
詳細については、次のマニュアルページをご覧ください。
ジャストインタイムアクセス
Atlas は、事前定義された時間後に自動的に期限切れとなる一時データベースユーザーの作成をサポートしています。ユーザーを作成する期間は以下の通りです。
6 時間
1 日
1 週間
詳細については、「データベース ユーザーの設定」を参照してください。
秘密マネジメント
HashiCorp Vaultのようなサードパーティのシークレットマネージャーの使用をお勧めします。 またはAWS Secrets マネージャーを使用して、複雑なデータベース認証情報を生成し、保存します。シークレットマネージャーは、Atlasデータベースに設定されたロールに基づいて、データベースの認証情報を動的に生成できます。
詳細については、ブログHashiCorp VaultでMongoDB Atlasデータベースの秘密を管理するをご覧ください。
Atlas Administration API 認証
Atlas は、Atlas Administration API への認証方法を 2 つ提供します。
サービス アカウント
サービス アカウントは、業界標準の OAuth2.0 を使用して、Atlas Administration APIを通じて Atlas で安全に認証します。有効期間が短いアクセス トークンを使用することでセキュリティが強化され、認証情報のローテーションが必要になるため、可能な場合はAPIキーの代わりにサービス アカウントを使用することをお勧めします。
サービス アカウントはプレビュー機能として利用できます。プログラムによるサービス アカウントのアクセスは、Atlas UIまたは Atlas Administration APIを使用することでのみ管理できます。Atlas CLI または Terraform を使用して、サービス アカウントのプログラムによるアクセスを管理することはできません。
詳細については、「サービスアカウントの概要」を参照してください。
API キー
サービス アカウントを使用しない場合は、API キー ベースの認証を使用して、プログラムによるアクセスを安全に管理できます。APIキーを使用した認証は、リクエストを保護するためにHTTPダイジェスト認証を使用します。API公開キーはユーザー名として機能し、対応する秘密キーはパスワードとして機能します。これらのキーは、AWS Secrets Manager や HashiCorp Vault などのサードパーティーのシークレット管理システムに保存するべきです。これらのキーを Vault に安全に保存する方法については、ブログ「HashiCorp Vault で MongoDB Atlas データベース シークレットを管理する」を参照してください。
セキュリティをさらに強化し、不正アクセスのリスクを最小限に抑えるために:
定期的にAPIキーをローテーションするためのベストプラクティスに従ってください。HashiCorp Vault でこれらのキーをローテーションする方法を学ぶには、たとえば、Hashicorp のドキュメントをご参照ください。
APIキーのためにIPアクセスリストを使用してください。詳細については、Atlas Administration API に IP アクセス リストが必要です。を参照してください。
詳細については、Atlas Administration API 認証をご覧ください。
配置
認証に関連する配置の推奨事項を学ぶには、Atlas 組織、プロジェクト、およびクラスターに関するガイダンスをご覧ください。
Atlas 認証に関する推奨事項
すべてのリソースにわたるアクセスを効果的に管理するには、Atlas の堅牢なロールベース アクセス制御(RBAC)を実装する必要があります。Atlas には、Atlas コントロール プレーンの管理に一般的に必要なさまざまなレベルのアクセスを提供する 組み込みロール が含まれています。データプレーン内の Atlas クラスターに接続する場合は、データベースのきめ細かなカスタムロールを使用して、ロールがその機能を実行するために必要なデータアクセスへのアクセスに基づいて詳細なスコープを指定することをお勧めします。このアプローチでは、最小特権の原則に従うことができます。
さらに、AtlasをフェデレーテッドIdPと統合することにより、IdPグループをAtlasロールにマッピングして、ジャストインタイムプロビジョニングを利用できます。これによりアクセス管理が効率化され、プラットフォーム全体で安全で整理されたロール割り当てが保証されます。オーケストレーションレイヤーのプロビジョニングプロセスに基づいて、プログラムによってアクセスを許可することができます。
一般に、上位環境へのアクセスは、セキュリティと確定的な結果がテストされているスクリプトを持つプログラム サービス アカウントのみに制限することをお勧めします。人間によるアクセスは、開発およびテスト中の低い環境でのみ許可される必要があります。
Atlas UIおよびAtlas管理API(Control Plane)の承認
ユーザー、サービスアカウント、およびAPIキーを事前定義されたロールに割り当てて、Atlas 組織もしくはプロジェクト、またはその両方で実行できるアクションを指定できます。IdP を使用して、グループ ロール マッピングを通じてIdPグループを Atlas ロールにリンクしてアクセスを管理します。
Azure Entra ID、Okta、Ping IdentityなどのSAMLでSSOを提供する最新のフェデレーション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 ユーザーロール 」を参照してください。
データベース承認
ワークフォースおよびワークロードのユーザーには、特定のプロジェクトや個々のクラスターに合わせた権限を持つ、事前定義またはカスタムのきめ細かなデータベースロールを割り当てることができます。ステージング環境と本番環境では、IdPをAtlasにリンクすることで、アイデンティティフェデレーションを使用してアクセス管理を合理化し、データアクセスの認証と承認フローをより現代的で効率的にすることをお勧めします。
IdP に グループメンバーシップ を設定することで、グループをデータベースユーザーにマッピングし、 IdP 内のアクセス制御を簡素化できます。ただし、ワークロードIDの場合は、groups
の代わりにusers
クレームを使用してロールを直接割り当てることをお勧めします。開発環境およびテスト環境では、開発およびテストプロセスを簡素化するために、事前定義された readWriteAny
ロールをデフォルトとして使用できます。アプリケーションをより高い環境に移行する際には、最小権限の原則に基づき、アプリケーションサーバーのアクセスを制限するためのカスタムロールをビルドする必要があります。
詳細については、以下をご覧ください。
オートメーションの例:Atlas 認証と承認
次の例では、オートメーション用の 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>"
共通のファイル
の例ごとに次のファイルを作成する必要があります。各例のファイルを 独自のディレクトリに配置します。ID と名前を変更して、 値を使用します。次に、コマンドを実行して Terraform を初期化し、Terraform プランを表示して変更を適用します。
azure.tf
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] } }
variables.tf
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 }
terraform.tfvars
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 ユーザーを作成します。
main.tf
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 }
次の例を使用して、 Azureで使用するために Atlas で OIDC フェデレーティッドIdPを設定し、OIDC フェデレーション認証ユーザーを作成します。アクセスを許可するには、 Azure Active Directory が発行した OIDC トークンを使用します。
main.tf
# 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" {}
outputs.tf
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 }
認可例
次の を使用して、ユーザーにはクラスターの管理者権限と、クラスター内のプロジェクトのプロジェクトノードの権限を付与します。
main.tf
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>"
共通のファイル
の例ごとに次のファイルを作成する必要があります。各例のファイルを 独自のディレクトリに配置します。ID と名前を変更して、 値を使用します。次に、コマンドを実行して Terraform を初期化し、Terraform プランを表示して変更を適用します。
azure.tf
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] } }
variables.tf
# 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" }
terraform.tfvars
org_id = "32b6e34b3d91647abb20e7b8" project_id = "67212db237c5766221eb6ad9" project_name = "My Project" connection_strings = token_audience = "https://management.azure.com/"
outputs.tf
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" }
IdP のフェデレーティッド設定の構成
以下を使用して、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プロジェクトの例については、「例」を参照してください。