Atlas Kubernetes Operator が管理するコンポーネントの機密情報を保存する場所は選択できますが、Atlas Kubernetes Operator は、期待されるKubernetes シークレット を見つける必要があります。Atlas Kubernetes Operator のシークレットは、次の方法を含むさまざまな方法で保存できます。
- 機密情報を Kubernetes シークレット に直接格納します 。Atlas Kubernetes Operator ドキュメントのすべてのチュートリアルでは、デフォルトで Kubernetes シークレット を使用します。Kubernetes シークレットを使用するには、チュートリアルの手順に従います。 
- GitOps フローに従って機密情報をGithubリポジトリに配置します。機密データを Git に安全に保存するには、対象のターゲット クラスターのシークレットを暗号化する シークレット などのツールを使用できます。 
- HashiCorp Vault や ハイパースケールのネイティブ シークレット管理ソリューション などの外部のシークレットストレージツールに機密情報を格納します。中間シークレットプロビジョニングツールは、外部シークレットストレージツールから機密情報を取得し、機密情報からKubernetes シークレットを作成します。シークレットプロビジョニングツールの詳細については、考慮事項を参照してください。 
このチュートリアルでは、Atlas Kubernetes Operator で使用するための外部シークレット ストレージ ツールを設定します。 このチュートリアルでは、Atlas Kubernetes Operator が Kubernetes クラスターにシークレットをプロビジョニングするためのシークレットを作成して保存する必要がない「シークレットレス」設定に焦点を当てます。
Considerations
次のチュートリアルでは、次のツールとオプションをインストールまたは構成します。
- シークレットプロビジョニングツール。シークレットプロビジョニングツールは、1 つ以上の認証メカニズムを使用して、シークレット管理サービスから認証情報を検索し、Atlas Kubernetes Operator が使用できるシークレットを作成します。このチュートリアルでは、次のいずれかのオープンソース シークレットプロビジョニングツールをインストールします。 
- シークレット にアクセスするための認証。HashiCorp Vault のシークレットにアクセスできるサービス アカウントと名前空間は、さまざまな方法で認証できます。 - 外部シークレット演算子 の場合、このチュートリアルでは OIDC JSONウェブトークン認証を使用します。詳しくは、 JSON web token/OIDC認証 を参照してください。 
- Secrets Store CSI ドライバー の場合、このチュートリアルではKubernetes認証を使用します。 
 - あるいは、クラウドプロバイダーのKMSがネイティブIAMシステムを使用してこの認証を提供することもできますが、これについてはチュートリアルでは説明されていません。 認証用にクラウドプロバイダーのKMSを構成する方法については、 外部シークレット演算子 のドキュメントの次のリソースを参照してください。 
前提条件
このチュートリアルを完了する前に、次のツールと構成が必要です。
- Kubernetes、Atlas Kubernetes Operator、および Atlas のサービス アカウントの実行と、それらを構成するのに十分な特権。 - x86-64、AMD64、または ARM64 アーキテクチャーを持つプロセッサを実行しているノードを含む実行中の Kubernetes クラスターが必要です。 このチュートリアルでは、Kubernetes クラスターは - https://kube01.internal.ioでデフォルトのポート(443)でリッスンしています。- のAtlas Kubernetes Operator プロジェクトにアクセスできます。Github - Atlas Kubernetes Operatorを使用してAtlas CLI をインストールするには、次のコマンドを実行します。 - atlas kubernetes operator install [options] - コマンド構文とパラメータの詳細については、Atlas CLI Atlas Kubernetes Operatorのインストール の ドキュメントを参照してください。 - Atlas Kubernetes Operator を配置するには、次のコマンドを実行します。 - <version>を最新のリリース番号に置き換えます。- kubectl apply -f https://raw.githubusercontent.com/mongodb/mongodb-atlas-kubernetes/<version>/deploy/all-in-one.yaml - Atlas アカウントの登録については、「 Atlas アカウントの作成 」を参照してください。 
- API キー。 API キーを作成し、 API Access Listを構成する必要があります。 - Atlas Kubernetes Operator から Atlas へのアクセスを構成するには、次の公開 API キー、プライベート API キー、および組織 ID 情報が必要です。 - Atlas Kubernetes Operator で新しい Atlasプロジェクトを作成する場合は、 組織へのプログラムによるアクセスの付与 。組織で Atlas Administration APIのIP アクセス リストが必要な場合は、 APIアクセス リストも設定する必要があります。 - 重要- API キーには、 Organization Project Creator組織ロール以上を割り当てる必要があります。 
- 既存の Atlasプロジェクトを操作する場合は、 プロジェクトからプロジェクト アクセスを追加 します。組織で Atlas Administration APIのIP アクセス リストが必要な場合は、 APIアクセス リストも設定する必要があります。 - 重要- Project Ownerプロジェクト ロールに API キーを割り当てる必要があります。 
 
- シークレットストレージヴォールト 。このチュートリアルでは、 で実行中シークレットストレージ用のサードパーティ サービスである HashiCorp Vault - https://vault.internal.ioを使用します。- では、必要に応じて、 、 、Google の Cloud など、他のシークレット ストレージAtlas Kubernetes OperatorKMS Amazon Web Servicesヴォールトを使用できます。Azure 
- 内部アクセスのみ。 パブリック インターネット経由で機密情報の露出を防ぐため、シークレット ストレージ ソリューションの次のコンポーネントは内部アクセスのみを許可します。 - HashiCorp Vault または KMS サービス。 
- Kubernetes Cluster APIs サービス。 
- 内部ネットワークです。 このチュートリアルでは、 - internal.ioを使用します。
 - 以前のコンポーネントでは内部アクセスのみが許可されていますが、相互へのアクセスが許可されており、チームまたは組織内の誰にもアクセス可能です。 これはセキュリティ上のベストプラクティスです。 
- 公開認証局(CA) 。 パブリック CA を使用すると、カスタム CA ルート証明書の管理と配布を回避できます。 - 次のいずれかのツールを使用して、CA 証明書の管理と更新を自動化できます。 - このチュートリアルでは、次の操作を行います。 - すべての - internal.ioHTTPs サービスは内部アドレスですが、HTTPS サイトには公開 CA によって署名された自動更新証明書が保持されます。
- サーバー側の HTTPS 検証のみを実行するため、この統合には相互 TLS(mTLS)は必要ありません。 
- クライアントは、追加の証明書プロビジョニングなしでこれらのサービス証明書を信頼できます。 
 
手順
Atlas Kubernetes Operator のシークレット ストレージを構成するには、次の手順に従います。
ターゲット クラスターにシークレット プロビジョニング ツールをインストールします。
シークレット プロビジョニング ツールを選択してインストールします。
外部シークレット演算子 をシークレットプロビジョニングツールとして使用するには、次の手順に従います。
- 次のコマンドを実行して、 Helm Charts で 外部シークレット演算子 をインストールし、サービスを開始します。 - helm repo add external-secrets https://charts.external-secrets.io - helm upgrade -i --atomic \ - -n external-secrets --create-namespace --set extraArgs.loglevel=debug \ - external-secrets external-secrets/external-secrets` 
- 外部シークレットが正常に実行されることを確認します。 - kubectl get pod -n external-secrets -l app.kubernetes.io/name=external-secrets - NAME READY STATUS RESTARTS AGE - external-secrets-5779d5d6f6-2lhgd 1/1 Running 0 70s 
Secrets Store CSI ドライバーをシークレット プロビジョニング ツールとして使用するには、次の手順に従います。
- 次のコマンドを実行して Secrets Store CSI ドライバーと Helm Charts をインストールし、サービスを開始します。 - helm repo add secrets-store-csi-driver https://kubernetes-sigs.github.io/secrets-store-csi-driver/charts - helm upgrade -i --atomic --set syncSecret.enabled=true \ - -n kube-system csi-secrets-store secrets-store-csi-driver/secrets-store-csi-driver 
- 次のコマンドを実行して、Secrets Store CSI HashiCorp Vaultプラグインと Helm Charts をインストールします。HashiCorp Vaultサーバーやシークレット インジェクションをインストールする必要はありません。 - helm install vault hashicorp/vault \ - --set "server.enabled=false" --set "injector.enabled=false" \ - --set "csi.enabled=true" 
- シークレット ストア CSI が正常に実行されることを確認します。 - kubectl get pod -n kube-system -l app.kubernetes.io/name=secrets-store-csi-driver - NAME READY STATUS RESTARTS AGE - csi-secrets-store-secrets-store-csi-driver-6dcm8 3/3 Running 0 2m2s 
- HashiCorp Vault CSI プロバイダーが正常に実行されていることを確認します。 - kubectl get pods -l app.kubernetes.io/name=vault-csi-provider - NAME READY STATUS RESTARTS AGE - vault-csi-provider-j7xbr 2/2 Running 0 5m39s 
シークレットにアクセスするための認証を設定します。
OIDC JSON web tokenとKubernetes認証を設定するには次の手順に従います。
- 次のコマンドを実行して、マウント パスのOIDC JSON web token認証を有効にします。 複数のKubernetesクラスターを設定する場合は、各クラスターのマウント パスに対してOIDC JSON web token認証を有効にする必要があります。 - vault auth enable -path=jwt-kube01 jwt 
- 次のコマンドを実行して、 - kube01.internal.ioクラスター上のOIDC検出 URL への非認証アクセスを許可します。- $ kubectl create clusterrolebinding oidc-reviewer \ - --clusterrole=system:service-account-issuer-discovery \ - --group=system:unauthenticated 
- 次のコマンドを実行して、HashiCorp Vault にクラスターを信頼するように指示します。 - https://kube01.internal.io/のクラスターの発行者は、- .well-known/openid-configurationの OIDC 検出ドキュメント内のURLと一致する必要があります。- curl https://kube01.internal.io/.well-known/openid-configuration | jq .issuer - https://kube01.internal.io/ - vault write auth/jwt-kube01/config jwks_url="https://kube01.internal.io/openid/v1/jwks" 
- クラスターに公開するシークレットへのアクセスを許可するポリシーを作成します。 - 次の例では、後の手順で指定する - external-secretsポリシーを作成します。- echo external-secrets-policy.hcl - path "secret/data/kube01/external-secrets/*" { - capabilities = ["read"] - } 
- コマンドを実行してHashiCorp Vaultロールを作成し、Kubernetesサービス アカウントをそのロールにバインドします。これにより、HashiCorp Vault内でのサービス アカウントのアクセスが制限されます。 - 次のコマンドを実行すると、 - vaultオーディエンスのJSON web token(OIDC)タイプの- jwt-kube01-systemロールが作成されます。このコマンドでは、バインドされたサブジェクトとして、- subユーザー クレームと- mongodb-atlas-system名前空間内の- defaultKubernetesサービス アカウントを指定します。このコマンドは、HashiCorp Vault 内の- external-secretsポリシーセットの権限のロールを関連付けます。- vault write auth/jwt-kube01/role/jwt-kube01-system role_type="jwt" bound_audiences=vault \ - user_claim="sub" bound_subject="system:serviceaccount:mongodb-atlas-system:default" \ - policies="external-secrets" 
- コマンドを実行して、外部シークレット演算子が - default名前空間にアクセスするための別のロールを作成します。- 次のコマンドを実行すると、 - vaultオーディエンスのJSON web token(OIDC)タイプの- jwt-kube01-defaultロールが作成されます。このコマンドは、- subユーザー クレームと、- default名前空間内の- defaultKubernetesサービス アカウントを バインドされたサブジェクト として指定します。このコマンドは、HashiCorp Vault 内の- external-secretsポリシーセットの権限のロールを関連付けます。- vault write auth/jwt-kube01/role/jwt-kube01-default role_type="jwt" bound_audiences=vault \ - user_claim="sub" bound_subject="system:serviceaccount:default:default" \ - policies="external-secrets" 
- システム サービス アカウントに対してOIDC認証が正常に実行されることを確認します。 - export TEST_JWT_TOKEN=$(kubectl -n mongodb-atlas-system create token default --audience "vault") - vault write auth/jwt-kube01/login role=jwt-kube01-system jwt=$(TEST_JWT_TOKEN) - Atlas Kubernetes Operatorは、システム サービス アカウントのOIDC JSON web token認証情報を返します。 
- デフォルトのサービス アカウントに対してOIDC認証が正常に実行されることを確認します。 - export TEST_JWT_TOKEN=$(kubectl -n default create token default --audience "vault") - vault write auth/jwt-kube01/login role=jwt-kube01-default jwt=$(TEST_JWT_TOKEN) - Atlas Kubernetes Operatorは、デフォルトのサービス アカウントのOIDC JSON web token認証情報を返します。 
Kubernetes 認証を設定するには、次の手順に従います。
- 以下のコマンドを実行して、マウント パスの Kubernetes 認証を有効にします。 複数の Kubernetes クラスターを設定する場合は、各クラスターのマウント パスに対して Kubernetes 認証を有効にする必要があります。 - vault auth enable -path=jwt-kube01 kubernetes - Helm を使用して をインストールすると、クラスター ロールのバインディングが自動的に構成されます。 
- クラスターに公開したいシークレットへのアクセスを許可するポリシーを作成します。 - 次の例では、後のステップで使用されるポリシー - vault-secretを作成しています。これは、ヘルム- vaultチャート CSI プロバイダーが設定する HashiCorp Vault サービス アカウントにバインドされたKubernetes シークレット である を使用します。- echo vault-secret.yaml - apiVersion: v1 - kind: Secret - metadata: - name: vault - annotations: - kubernetes.io/service-account.name: vault - type: kubernetes.io/service-account-token - $ kubectl apply -f vault-secret.yaml 
- コマンドを実行して Kubernetes クラスターを信頼し、Kubernetes 認証を使用します。 - export VAULT_JWT ?= $(shell kubectl get secret/vault -o jsonpath='{.data.token}' |base64 -d) - vault write auth/k8s-kube01/config kubernetes_host="kube01.internal.io" token_reviewer_jwt=$(VAULT_JWT) 
- コマンドを実行してHashiCorp Vaultロールを作成し、Kubernetesサービス アカウントをそのロールにバインドします。これにより、HashiCorp Vault内でのサービス アカウントのアクセスが制限されます。 - 次のコマンドは、 - defaultまたは- mongodb-atlas-system名前空間のKubernetesサービス アカウントにバインドされた- auth/k8s-kube01に- k8s-kube01ロールを作成します。このロールは、HashiCorp Vault 内の- secrets-store権限ポリシーに関連付けられます。- vault write auth/k8s-kube01/role/k8s-kube01-role \ - bound_service_account_names=default,mongodb-atlas-operator \ - bound_service_account_namespaces=default,mongodb-atlas-system \ - policies=secrets-store - ポリシーが存在し、シークレットへのアクセスが許可されている必要があります。 次のサンプル ポリシーでは、 - kube01/secrets-storeパスの下の KV v 2シークレットへのアクセスを許可します。- path "secret/data/kube01/secrets-store/*" { - capabilities = ["read"] - } 
- システム サービス アカウントに対して Kubernetes 認証が正常に実行されることを確認します。 - export TEST_JWT_TOKEN=$( kubectl create -n mongodb-atlas-system token mongodb-atlas-operator) - vault write auth/jwt-kube01/login role=jwt-kube01-system jwt=$(TEST_JWT_TOKEN) 
- Kubernetes 認証がデフォルト アカウントで正常に実行されることを確認します。 - export TEST_JWT_TOKEN=$(kubectl -n default create token default) - vault write auth/jwt-kube01/login role=jwt-kube01-default jwt=$(TEST_JWT_TOKEN) 
自動シークレットプロビジョニングを設定します。
外部シークレット演算子を使用してシークレットをプロビジョニングするには、
- mongodb-atlas-system名前空間に- defaultサービス アカウントの- SecretStoreカスタム リソースを配置します。- $ cat external-secrets/vault-system.yaml - apiVersion: external-secrets.io/v1beta1 - kind: SecretStore - metadata: - name: vault-store - namespace: mongodb-atlas-system - spec: - provider: - vault: - server: "https://vault.internal.io" - path: "secret" - version: "v2" - auth: - jwt: - path: "jwt-kube01" - role: "jwt-kube01-system" - kubernetesServiceAccountToken: - expirationSeconds: 600 - serviceAccountRef: - name: "default" - audiences: - - vault - $ kubectl apply -f external-secrets/vault-system.yaml 
- default名前空間に- defaultサービス アカウントの- SecretStoreカスタム リソースを配置します。- $ cat external-secrets/vault-default.yaml - apiVersion: external-secrets.io/v1beta1 - kind: SecretStore - metadata: - name: vault-store - namespace: default - spec: - provider: - vault: - server: "https://vault.internal.io" - path: "secret" - version: "v2" - auth: - jwt: - path: "jwt-kube01" - role: "jwt-role" - kubernetesServiceAccountToken: - expirationSeconds: 600 - serviceAccountRef: - name: "default" - audiences: - - vault - $ kubectl apply -f external-secrets/vault-default.yaml 
- API キーを含むシークレットを参照する - ExternalSecretカスタム リソースを配置します。 外部シークレット演算子が作成するシークレットを見つけるには、Atlas Kubernetes Operator の値- credentialsを使用して- spec.target.template.metadata.labelsを- atlas.mongodb.com/typeに設定する必要があります。- 次のコマンドを実行する前に、HashiCorp Vault に次のプロパティを持つ Kv V2 パス - secret/data/kube01/external-secrets/atlas-accountにシークレットが入力されていることを確認してください。- orgId
- publicApiKey
- privateApiKey
 - $ cat external-secrets/atlas.yaml - apiVersion: external-secrets.io/v1beta1 - kind: ExternalSecret - metadata: - name: atlas - namespace: mongodb-atlas-system - spec: - refreshInterval: "15s" - secretStoreRef: - name: vault-store - kind: SecretStore - target: - name: mongodb-atlas-operator-api-key - template: - metadata: - labels: - atlas.mongodb.com/type: credentials - data: - - secretKey: orgId - remoteRef: - key: secret/data/kube01/external-secrets/atlas-account - property: orgId - - secretKey: publicApiKey - remoteRef: - key: secret/data/kube01/external-secrets/atlas-account - property: publicApiKey - - secretKey: privateApiKey - remoteRef: - key: secret/data/kube01/external-secrets/atlas-account - property: privateApiKey - $ kubectl apply -f external-secrets/atlas.yaml - このコマンドは、 名前空間にKubernetesシークレット - mongodb-atlas-operator-api-key- mongodb-atlas-systemを作成します。
- データベースユーザーの認証情報を含むシークレットを参照する - ExternalSecretカスタム リソースを配置します。 外部シークレット演算子が作成するシークレットを見つけるには、Atlas Kubernetes Operator の値- credentialsを使用して- spec.target.template.metadata.labelsを- atlas.mongodb.com/typeに設定する必要があります。- 次のコマンドを実行する前に、HashiCorp Vault に - passwordプロパティを持つ Kv V2 パス- secret/data/kube01/external-secrets/db-userにシークレットが入力されていることを確認してください。- $ cat external-secrets/dbuser.yaml - apiVersion: external-secrets.io/v1beta1 - kind: ExternalSecret - metadata: - name: dbuser - namespace: default - spec: - refreshInterval: "15s" - secretStoreRef: - name: vault-store - kind: SecretStore - target: - name: dbuser-password - template: - metadata: - labels: - atlas.mongodb.com/type: credentials - data: - - secretKey: password - remoteRef: - key: secret/data/kube01/external-secrets/db-user - property: password - $ kubectl apply -f external-secrets/atlas.yaml 
- 次のコマンドを実行すると、シークレットが期待どおりに返されることを確認します。 - $ kubectl get -n mongodb-atlas-system secrets/mongodb-atlas-operator-api-key - $ kubectl get -n default secrets/dbuser-password 
シークレット ストア CSI を使用してシークレットをプロビジョニングするには、次の手順に従います。
- mongodb-atlas-system名前空間に- SecretProviderClassカスタム リソースを配置します。 Secret s Store が作成するシークレットを見つけるには、Atlas Kubernetes Operator の値- credentialsを使用して- spec.secretObjects.labelsを- atlas.mongodb.com/typeに設定する必要があります。- 次のコマンドを実行する前に、HashiCorp Vault に次のプロパティを持つ Kv V2 パス - secret/data/kube01/external-secrets/atlas-accountにシークレットが入力されていることを確認してください。- orgId
- publicApiKey
- privateApiKey
 - $ cat secrets-store/atlas.yaml - apiVersion: secrets-store.csi.x-k8s.io/v1 - kind: SecretProviderClass - metadata: - name: atlas - namespace: mongodb-atlas-system - spec: - provider: vault - secretObjects: - - data: - - key: orgId - objectName: atlas-org - - key: publicApiKey - objectName: atlas-pub-key - - key: privateApiKey - objectName: atlas-secret-key - secretName: mongodb-atlas-operator-api-key - type: Opaque - labels: - atlas.mongodb.com/type: credentials - parameters: - vaultAddress: https://vault.internal.io - vaultKubernetesMountPath: k8s-kube01 - roleName: k8s-kube01-role - objects: | - - objectName: atlas-org - secretPath: secret/data/kube01/secrets-store/atlas-account - secretKey: orgId - - objectName: atlas-pub-key - secretPath: secret/data/kube01/secrets-store/atlas-account - secretKey: publicApiKey - - objectName: atlas-secret-key - secretPath: secret/data/kube01/secrets-store/atlas-account - secretKey: privateApiKey - $ kubectl apply -f secrets-store/atlas.yaml - このコマンドは、 名前空間にKubernetesシークレット - mongodb-atlas-operator-api-key- mongodb-atlas-systemを作成します。
- 次のコマンドを実行して、必要なシークレットをマウントするポッドを追加します。 - $ cat secrets-store/ako-patch.yaml - template: - spec: - containers: - - name: system-secret-placeholder - image: mongodb/atlas - command: ["sleep", "infinity"] - volumeMounts: - - name: secrets-store-mount - mountPath: "/mnt/secrets-store" - readOnly: true - volumes: - - name: secrets-store-mount - csi: - driver: secrets-store.csi.k8s.io - readOnly: true - volumeAttributes: - secretProviderClass: atlas - $ kubectl apply -f secrets-store/ako-patch.yaml 
- データベースユーザーの認証情報を含むシークレットを参照する - SecretProviderClassカスタム リソースを配置します。 Secret s Store が作成するシークレットを見つけるには、Atlas Kubernetes Operator の値- credentialsを使用して- spec.target.template.metadata.labelsを- atlas.mongodb.com/typeに設定する必要があります。- 次のコマンドを実行する前に、HashiCorp Vault に - passwordプロパティを持つ Kv V2 パス- secret/data/kube01/external-secrets/db-userにシークレットが入力されていることを確認してください。- $ cat external-secrets/dbuser.yaml - apiVersion: external-secrets.io/v1beta1 - kind: SecretProviderClass - metadata: - name: dbuser - namespace: default - spec: - provider: vault - secretObjects: - - data: - - key: password - objectName: dbuser - secretName: dbuser-password - type: Opaque - labels: - atlas.mongodb.com/type: credentials - parameters: - vaultAddress: https://vault.internal.io - vaultKubernetesMountPath: k8s-kube01 - roleName: k8s-kube01-role - objects: | - - objectName: "dbuser" - secretPath: "secret/data/kube01/secrets-store/db-user" - secretKey: "password" - $ kubectl apply -f secrets-store/dbuser.yaml 
- 次のコマンドを実行して - secret-placeholder要塞ポッドを作成します。これで Secrets Store の CSI ドライバーが- dbuserの認証情報を取得し、Kubernetes に同期できるようにします。- $ cat secrets-store/placeholder.yaml - kind: Pod - apiVersion: v1 - metadata: - name: secret-placeholder - spec: - containers: - - image: mongodb/atlas - command: ["sleep", "infinity"] - name: secret-placeholder - volumeMounts: - - name: secrets-store-mount - mountPath: "/mnt/secrets-store" - readOnly: true - volumes: - - name: secrets-store-mount - csi: - driver: secrets-store.csi.k8s.io - readOnly: true - volumeAttributes: - secretProviderClass: dbuser - $ kubectl apply -f secrets-store/placeholder.yaml 
- 次のコマンドを実行すると、シークレットが期待どおりに返されることを確認します。 - $ kubectl get -n mongodb-atlas-system secrets/mongodb-atlas-operator-api-key - $ kubectl get -n default secrets/dbuser-password 
Atlas Kubernetes Operator カスタム リソースを配置します。
Atlas Kubernetes Operator カスタム リソースを配置できるようになりました。Atlas Kubernetes Operator は、 HashiCorp Vault を参照Kubernetesシークレットを使用して認証します。配置に必要に応じて timeout の値を調整します。
kubectl apply -f ako/project.yaml kubectl apply -f ako/deployment.yaml kubectl apply -f ako/user.yaml kubectl wait --for=condition=ready atlasdeployment/serverless-deployment --timeout=10m kubectl wait --for=condition=ready atlasdatabaseuser/user --timeout=10m 
これらのカスタム リソースの詳細については、「カスタム リソース 」を参照してください。
Atlas Kubernetes Operator 配置をテストします。
Atlas Kubernetes Operator の配置をテストするには、次のコマンドを実行します。
export ATLAS_DEPLOYMENT_CONN_STR=$(kubectl get secrets/test-atlas-operator-project-test-serverless-deployment-dbuser -o jsonpath='{.data.connectionStringStandardSrv}' |base64 -d) mongosh $(ATLAS_DEPLOYMENT_CONN_STR) --apiVersion 1 --eval "show dbs" 
Atlas Kubernetes Operator は、データベース配置のリストを返します。