External Secrets ================ `External Secrets `_ はCNCFサンドボックスプロジェクトであり、TAG Securityのスポンサーのもとで2022年に受け入れられました。 について -------- **外部シークレットオペレーターESO** は、シークレットのストレージをKubernetes自分自身から分離することにより、シークレット管理を強化するKubernetesオペレーターです。これにより、外部シークレット管理システムとネイティブKubernetes ``Secret`` リソース間のシームレスな同期が可能になります。 ESOは、以下を含む幅広いバックエンドをサポートしています。 - `HashiCorp Vault `_ - `AWS Secrets Manager `_ - `Google Secret Manager `_ - `Azure Key Vault `_ - `IBM Cloud Secrets Manager `_ …その他にもたくさん。サポートされているプロバイダーの完全な最新のリストについては、 `official External Secrets documentation `_ を参照してください。 PostgreSQLおよびCloudNativePGとの統合 ------------------------------------- PostgreSQLデータベースに関しては、外部シークレットは2つの主要なユースケースで `CloudNativePG `_ とシームレスに統合します。 - **自動パスワード管理** ESOは、Kubernetes ``Secret`` リソースに保存されているデータベースユーザーパスワードの自動生成とローテーションを処理でき、クラスター内で実行されているアプリケーションが常に最新の資格情報にアクセスできるようにします。 - **クロスプラットフォームのシークレットアクセス** ``SecretStore`` リソースを介して外部キー管理サービスKMSとこれらのパスワードの透過的な同期が有効になります。これにより、Kubernetesクラスターの外部のアプリケーションと開発者Kubernetesシークレットにアクセスできない場合があり、外部KMSからデータベース資格情報を直接取得できます。 例 外部シークレットを使用した自動パスワード管理 ----------------------------------------------- :ref:`quickstart guide ` から\ ``cluster-example`` Postgresクラスターで\ ``app`` ユーザーのパスワードを24時間ごとに自動的にローテーションする方法を説明します。 .. Note:: 続行する前に、`cluster-example` Postgresクラスターが環境で稼働していることを確認してください。 　 デフォルトでは、CloudNativePGは\ ``cluster-example-app`` という名前のKubernetes ``Secret`` を生成および管理します。これには、\ ``cluster-example`` クラスターの\ ``app`` ユーザーの資格情報が含まれています。これについては、 :ref:`“Connecting from an application” section ` で読むことができます。 外部シークレットを使用する場合、目標は次のことです。 1. パスワードの生成方法を指定する\ ``Password`` ジェネレーターを定義します。 2. ``password`` および\ ``pgpass`` フィールドのみを更新することにより、\ ``cluster-example-app`` シークレットの同期を維持する\ ``ExternalSecret`` リソースを作成します。 パスワードジェネレーターの作成 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 次の例では、 `Password `_ ``default`` 名前空間の\ ``pg-password-generator`` という名前のリソース。ニーズに合わせて名前とプロパティをカスタマイズできます。 .. code:: yaml apiVersion: generators.external-secrets.io/v1alpha1 kind: Password metadata: name: pg-password-generator spec: length: 42 digits: 5 symbols: 5 symbolCharacters: "-_$@" noUpper: false allowRepeat: true この仕様は、生成されるパスワードの長さ、数字、記号、大文字の包含などの特性を定義します。 外部シークレットの作成 ^^^^^^^^^^^^^^^^^^^^^^ 次の例では、 時間ごとにパスワードを更新する ``cluster-example-app-secret`` という名前の\ ``ExternalSecret`` リソースを作成します。 ``Merge`` ポリシーを使用して、\ ``cluster-example-app`` シークレットの指定されたフィールド\ ``password`` 、\ ``pgpass`` 、\ ``jdbc-uri`` 、および\ ``uri`` のみを更新します。 .. code:: yaml apiVersion: external-secrets.io/v1 kind: ExternalSecret metadata: name: cluster-example-app-secret spec: refreshInterval: "24h" target: name: cluster-example-app creationPolicy: Merge template: metadata: labels: cnpg.io/reload: "true" data: password: "{{ .password }}" pgpass: "cluster-example-rw:5432:app:app:{{ .password }}" jdbc-uri: "jdbc:postgresql://cluster-example-rw.default:5432/app?password={{ .password }}&user=app" uri: "postgresql://app:{{ .password }}@cluster-example-rw.default:5432/app" dataFrom: - sourceRef: generatorRef: apiVersion: generators.external-secrets.io/v1alpha1 kind: Password name: pg-password-generator ラベル ``cnpg.io/reload: "true"`` により、シークレットが変更されたときにCloudNativePGがデータベースのユーザーパスワードのリロードをトリガーします。 構成の検証 ^^^^^^^^^^ ``ExternalSecret`` が正しく同期していることを確認するには .. code:: sh kubectl get es cluster-example-app-secret リアルタイムで更新されるパスワードを観察するには、一時的に\ ``refreshInterval`` を\ ``30s`` に減らし、次のコマンドを繰り返し実行します。 .. code:: sh kubectl get secret cluster-example-app \ -o jsonpath="{.data.password}" | base64 -d 30秒ごとにパスワードが変更され、ローテーションが正しく機能していることを確認します。 他にもあります ^^^^^^^^^^^^^^ 上記の例では、CloudNativePGによって作成されたデフォルトの\ ``cluster-example-app`` シークレットに焦点を当てていますが、同じアプローチを拡張して、カスタムシークレットまたはパスワードを定期的にローテーションするように作成するPostgreSQLユーザーを管理できます。 例外部KMSとの統合 ----------------- CNCFエコシステムで最も広く使用されているキー管理サービスKMSプロバイダーの1つが `HashiCorp Vault `_ です。 VaultはビジネスソースライセンスBUSLに基づいてライセンスされていますが、完全な互換性がありアクティブにメンテナンスされているオープンソースの代替品 `OpenBao `_ が利用できます。 OpenBaoは、HashCorp Vaultと同じインターフェイスをすべてサポートしているため、真のドロップイン代替品となります。 この例では、CloudNativePG、外部シークレットオペレーター、およびHashCorp Vaultを統合して、PostgreSQLパスワードを自動的にローテーションし、Vaultに安全に保存する方法を示します。 .. Note:: この例では、 HashiCorp Vaultが既にインストールされ、環境に適切に構成されており、チームがそれを操作するために必要な専門知識があることを前提としています。 Vaultを展開するにはさまざまな方法があり、それらの詳細についてはCloudNativePGの範囲外です。 Kubernetes内でVaultを実行することは可能ですが、外部に展開されるのがより一般的です。詳細な手順については、 `HashiCorp Vault documentation `_ を参照してください。 　 前の例から続けて、必要な\ ``SecretStore`` および\ ``PushSecret`` リソースを作成して、Vaultとの統合を完了します。 ``SecretStore`` の作成 ^^^^^^^^^^^^^^^^^^^^^^ この例では、 HashiCorp Vaultが\ ``http://vault.vault.svc:8200`` の名前空間内からアクセスでき、 ``vault-token`` という名前のKubernetes ``Secret`` が同じ名前空間に存在し、Vaultでの認証に使用されるトークンを含むことを前提としています。 .. code:: yaml apiVersion: external-secrets.io/v1 kind: SecretStore metadata: name: vault-backend spec: provider: vault: server: "http://vault.vault.svc:8200" path: "secrets" # Specifies the Vault KV secret engine version ("v1" or "v2"). # Defaults to "v2" if not set. version: "v2" auth: # References a Kubernetes Secret that contains the Vault token. # See: https://www.vaultproject.io/docs/auth/token tokenSecretRef: name: "vault-token" key: "token" - -- apiVersion: v1 kind: Secret metadata: name: vault-token data: token: aHZzLioqKioqKio= # hvs. **** *** この構成は、 ``vault-backend`` という名前の\ ``SecretStore`` リソースを作成します。 .. Note:: この例では、基本的なトークンベースの認証を使用します。これは、APIおよびCLIのユースケースをテストするのに適しています。これはVaultで有効になっているデフォルトの方法ですが、運用環境にはお勧めできません。実稼働環境では、より安全な認証方法の使用を検討します。 `External Secrets Operator documentation `_ を参照してください サポートされている認証メカニズムの完全なリストについては、 　 .. Note:: HashiCorp Vaultは、バージョン`v2` の`secrets` パスでKVシークレットエンジンを有効にする必要があります。 Vaultインスタンスが別のパスまたはバージョンを使用している場合、それに応じて`path` および`version` フィールドを更新してください。 　 ``PushSecret`` の作成 ^^^^^^^^^^^^^^^^^^^^^ ``PushSecret`` リソースは、Kubernetes ``Secret`` をHashCorp Vaultにプッシュするために使用されます。この単純化された例では、サンプルクラスター\ ``cluster-example`` の\ ``app`` ユーザーの資格情報をプッシュします。 ``PushSecret`` の構成の詳細については、 `External Secrets Operator documentation `_ を参照してください。 .. code:: yaml apiVersion: external-secrets.io/v1alpha1 kind: PushSecret metadata: name: pushsecret-example spec: deletionPolicy: Delete refreshInterval: 24h secretStoreRefs: - name: vault-backend kind: SecretStore selector: secret: name: cluster-example-app data: - match: remoteRef: remoteKey: cluster-example-app この例では、 ``PushSecret`` リソースは、 ``cluster-example-app`` という名前のKubernetes ``Secret`` をHashCorp Vaultにプッシュするように外部シークレットオペレーターに指示します。前の例から。 ``remoteKey`` は、 ``vault-backend`` という名前の\ ``SecretStore`` を使用して、シークレットをVaultに保存する名前を定義します。 .. _構成の検証-1: 構成の検証 ^^^^^^^^^^ ``PushSecret`` が正常に機能していることを確認するには、 HashiCorp Vault UIに移動します。パス\ ``secrets`` の\ ``kv`` シークレットエンジンで、上記で定義した\ ``remoteKey`` に対応する\ ``cluster-example-app`` という名前のシークレットを見つけます。