Kubernetes Operator の シークレット ストレージ ツール を選択できます。 シークレット ストレージ ツールは、Kubernetes Operator が管理するコンポーネントの機密情報を保存する安全な場所です。 これには、 MongoDBデータベース、 MongoDB Ops Manager 、 AppDB のシークレットが含まれます。
シークレット ストレージを構成すると、Kubernetes Operator は ツールにアクセスしてシークレットを取得し、それらを使用して接続を安全に確立します。
サポートされているシークレット ストレージ ツール
Kubernetes Operator は次のシークレット ストレージ ツールをサポートしています。
- Kubernetes : 機密情報を シークレット として保存します( Kubernetesの組み込みシークレットストレージ)。Kubernetes secrets は認証資格情報を保存し、 Kubernetesのみがアクセスできるようにします。 
- HashiCorp Vault : 秘密管理用のサードパーティ サービスである Vault に機密情報を保存します。 
保存できるシークレット
MongoDB Enterprise Kubernetes Operator のドキュメントに含まれる任意のシークレットには、サポートされている任意のシークレット ストレージ ツールを使用できます。ただし、制限 に記載されているものは除きます。
重要
構成後、Kubernetes Operator は、 制限 にリストされているシークレットを 除く すべての シークレットに対して選択したシークレット ストレージ ツールを使用します。シークレット ストレージ ツールを混在させることはできません。
制限
サポートされているシークレット ストレージ ツールには、次の制限があります。
- OpenShiftなどの一部のレジストリでは、リポジトリからイメージをプルするためにimagePullSecretsが必要です。Kubernetes Operator は、HashiCorp Vault からのimagePullSecrets を提供できません。代わりに kubelet イメージ認証プロバイダーを指定すると、 Kubernetesを使用してコンテナイメージ レジストリの認証情報を取得できます。 
シークレット ストレージ ツールを設定する
シークレット ストレージ ツールを設定するには、次のいずれかのオプションを選択します。
HashiCorp Vault を使用してKubernetes Operator のシークレットを保存するには、次の手順を実行します。
前提条件
始める前に、以下の操作を行う必要があります。
- Vault インスタンスを設定します。 Kubernetes Operator が実行されている Kubernetes クラスターは、Vault インスタンスへのアクセス権を持つ必要があります。 - 注意- Vault が開発モードで実行中いないこと、および Vault のインストールが該当する構成の推奨事項に従っていることを確認します。 
- VaultインスタンスのKubernetes認証を有効にします。これにより、Vault で認証できるようになります。 
- Kubernetesクラスターに Vault Agent サイドカー インジェクションを配置します。これにより、Vault からKubernetesポッドにシークレットを挿入できるようになります。 
- Kubernetes Operator、 MongoDBデータベース、 MongoDB Ops Manager、および AppDB の 4 つの Vault ポリシー ファイル をダウンロードします。 
- Vault に - mongodbenterpriseという名前のロールを作成します。Kubernetes Operator でのシークレットの構成は、このロールの存在とその正確な名前に依存します。
手順
Kubernetes Operator ポリシーとそのコンポーネントの Vault を追加します。
次のコマンドを使用して、 Kubernetes Operator、 MongoDB database、 MongoDB Ops Manager 、および AppDB リソースのポリシーを Vault に書き込み、変数を表内の値に置き換えます。
| プレースホルダー | 説明 | 
|---|---|
| {PolicyName} | Vault で作成しているポリシーを識別する、人間に判読可能なラベル。 | 
| {PathToPolicyFile} | ダウンロードしたポリシー ファイルへの絶対パス。 | 
vault policy write {PolicyName} {PathToPolicyFile} 
Vault に追加するすべてのリソースに対して、 コマンドを繰り返します。
Kubernetes Operator とそのコンポーネントの Vault ポリシーに Vault ロールをバインドします。
次の 4 つのコマンドを使用して、 Kubernetes Operator、 MongoDB database、 MongoDB Ops Manager 、および AppDB リソースのポリシーに Vault ロールをバインドし、変数を表内の値に置き換えます。
| プレースホルダー | 説明 | 
|---|---|
| {OperatorPolicyName} | Vault 内の Kubernetes Operator ポリシーを識別する、人間が判読可能なラベル。 | 
| {DatabasePolicyName} | Vault 内の MongoDB database ポリシーを識別する、人間が判読可能なラベル。 | 
| {Ops ManagerPolicyName} | Vault 内のMongoDB Ops Managerポリシーを識別する、人間が判読可能なラベル。 | 
| {AppDBPolicyName} | Vault 内の AppDB ポリシーを識別する、人間が判読可能なラベル。 | 
| {ServiceAccountNamespace} | ポッドにバインドされたサービス アカウントの名前空間を識別するラベル。 | 
vault write auth/kubernetes/role/{OperatorPolicyName} bound_service_account_names=enterprise-operator bound_service_account_namespaces={ServiceAccountNamespace} 
vault write auth/kubernetes/role/{DatabasePolicyName} bound_service_account_names=mongodb-enterprise-database-pods bound_service_account_namespaces={ServiceAccountNamespace} 
vault write auth/kubernetes/role/{OpsManagerPolicyName} bound_service_account_names=mongodb-enterprise-ops-manager bound_service_account_namespaces={ServiceAccountNamespace} 
vault write auth/kubernetes/role/{AppDBPolicyName} bound_service_account_names=mongodb-enterprise-appdb bound_service_account_namespaces={ServiceAccountNamespace} 
これらのコマンドは、各コンポーネントのポッドがポリシーで指定されたアクセスのみを持つことを可能にします。
注意
この手順により、Kubernetes Operator に Vault へのアクセスが許可されます。 Kubernetes Operator が管理しないアプリケーションで Vault を使用するには、それらのアプリケーションの Vault ポリシーを作成してバインドする必要があります。
この手順のコマンドを調整して、サービス アカウント の名前を置き換えることで、他のポリシーをバインドできます。Vault を使用するように他のアプリケーションを構成するには、次のコマンドの {ServiceAccountName} を、アプリケーションのポッドに使用されるサービス アカウントに置き換えます。
vault write auth/kubernetes/role/{PolicyName} bound_service_account_names={ServiceAccountName} bound_service_account_namespaces={ServiceAccountNamespace} 
Kubernetes 配置ファイルに注釈を追加します。
このステップのコマンドを実行中前に、 という名前の Vault mongodbenterpriseロールを作成していることを確認してください。
次の強調表示された行を Kubernetes Operator 配置ファイルのspec.template.metadata.annotationsセクションに追加します。 ほとんどのユーザーでは、このファイルの名前はmongodb-enterprise.yamlまたはmongodb-enterprise-openshift.yamlです。
注意
Helm を使用して Kubernetes Operator をインストールし、 Operator.vaultSecretBackend.enabledをtrueに設定した場合、Kubernetes Operator は次の注釈を追加します。 次の手順に進むことができます。
apiVersion: apps/v1 kind: Deployment metadata:    name: mongodb-enterprise-operator    namespace: production spec:    replicas: 1    template:       metadata:         annotations:           vault.hashicorp.com/agent-inject: "true"           vault.hashicorp.com/role: "mongodbenterprise" 
Vault を TLSモードで実行していて、オペレーター.vaultSecretBackend.tlsSecretRef 値を指定した場合、Kubernetes 演算子は次の注釈を追加します。 それ以外の場合は、 ファイルに次の強調表示された行を追加し、 {TLSSecret}をca.crtエントリを含むシークレットの名前に置き換えます。 ca.crtエントリの内容は、Vault TLS 証明書の生成に使用されるCAの証明書と一致する必要があります。
        annotations:           vault.hashicorp.com/agent-inject: "true"           vault.hashicorp.com/role: "mongodbenterprise"           vault.hashicorp.com/tls-secret: {TLSSecret}           vault.hashicorp.com/ca-cert: /vault/tls/ca.crt 
Kubernetes で 環境変数を定義します。
次の強調表示された行を Kubernetes Operator 配置ファイルのspec.envセクションに追加します。 ほとんどのユーザーでは、このファイルの名前はmongodb-enterprise.yamlまたはmongodb-enterprise-openshift.yamlです。
apiVersion: apps/v1 kind: Deployment metadata:    name: mongodb-enterprise-operator    namespace: production spec:    env:    - name: OPERATOR_ENV      value: ENVIRONMENT_NAME    - name: SECRET_BACKEND      value: VAULT_BACKEND 
Vault 構成情報を含む ファイルを作成します。
お好みのテキスト編集アプリケーションを使用して、 configという名前のファイルを作成します。 以下のテキストを ファイルに貼り付けます。
apiVersion: v1 kind: ConfigMap metadata:   name: secret-configuration   namespace: {Namespace} data:   VAULT_SERVER_ADDRESS: {VaultServerAddress}   OPERATOR_SECRET_BASE_PATH: mongodbenterprise/operator   DATABASE_SECRET_BASE_PATH: mongodbenterprise/database   OPS_MANAGER_SECRET_BASE_PATH: mongodbenterprise/opsmanager   APPDB_SECRET_BASE_PATH: mongodbenterprise/appdb 
このファイル内のパスはデフォルトのパスです。 Kubernetes Operator の構成をカスタマイズした場合は、これらをベース パスに置き換えることができます。
Vault をTLSモードで実行している場合は、 ファイルに次の強調表示された行も追加する必要があります。
   OPS_MANAGER_SECRET_BASE_PATH: mongodbenterprise/opsmanager    APPDB_SECRET_BASE_PATH: mongodbenterprise/appdb    TLS_SECRET_REF: {TLSSecret} 
Vault 構成情報のプレースホルダーを置き換えます。
configファイル内のプレースホルダーをこれらの値に置き換えます。 .txtファイル拡張子を.yamlに置き換えて、 YAMLファイル タイプでファイルを保存します。
| プレースホルダー | 説明 | 
|---|---|
| {Namespace} | Kubernetes Operator の作成した名前空間。 デフォルトの名前空間は | 
| {VaultServerAddress} | Kubernetes Operator が Vault に接続するために使用するアドレス。 | 
| {TLSsecret} | 
 | 
自動的に移行されないシークレットを手動で移行する
次のシークレットを Vault に保存するには、手動で移行する必要があります。
- Kubernetes secret として保存されているオペレーターの認証情報を含む、既存のユーザー作成シークレット(該当する場合) 
- Kubernetes Operator が作成する生成キー シークレット 
- MongoDB Ops Manager管理者認証情報/管理キーKubernetes Operator は、 
- TLS シークレット 
新しいシークレットを手動で移行または作成するには、 Vault に追加します。 これらを Vault に追加した後、Kubernetes から削除できます。
Kubernetes Operator が作成する他のすべてのシークレットは自動的に移行され、Kubernetes Operator は新しいシークレットに Vault を使用します。 ユーザーが作成したシークレットはVault に追加する必要があります。
注意
cert-manager は、生成されたKubernetesシークレットをKubernetesから削除すると、自動的に再作成します。これらのシークレットの削除は、 Kubernetesに保存されないように手動で管理するか、cert-manager の使用を停止する必要があります。
次のステップ
MongoDB Enterprise Kubernetes Operator のシークレット ストレージ ツールを構成すると、次のことが可能になります。