メインコンテンツへスキップ
Vantage 3.0 セルフホスト型では、pod の起動時に、すべてのデータベース接続文字列、API キー、TLS 証明書をシークレットプロバイダーから読み込みます。これらの値は values.yaml ファイルには一切保存されません。サポートされるプロバイダーは 2 種類で、インストールごとに vantage.secrets で必ず 1 つだけ設定します。

​
サポートされているプロバイダー

この 2 つのプロバイダーは、同じ シークレットエイリアス の仕様を共有しています。Vantage のワークロードは、値の取得元に関係なく、エイリアスでシークレットを参照します。プロビジョニングを計画するには、以下の エイリアス一覧 を参照してください。

​
Azure Key Vault プロバイダー

​
Identity モード

​
仕組み

Vantage は、Azure Key Vault provider とともに Secrets Store CSI driver を使用します。各チャートの SecretProviderClass は、それを使用する pod に CSI ボリュームとしてマウントされ、このマウントをきっかけに、ドライバーが値をチャートごとの Kubernetes Secret (SPC の secretObjects 機能) に同期します。pod はそれを envFrom とボリュームマウント経由で使用します。流れは次のとおりです:
  1. オペレーターは、チャートごとに SecretProviderClass (SPC) を生成し、そのチャートに必要な Key Vault エイリアスと、それぞれをチャートごとの Kubernetes Secret 内のキーにどのようにマップするかを定義します。
  2. pod が SPC のボリュームをマウントすると、Secrets Store CSI driver は identityMode で選択された ID として認証を行い、Key Vault から指定されたオブジェクトを取得して、SPC の secretObjects 機能を通じてチャートごとの Kubernetes Secret に同期します。
  3. チャートの pod は、チャートごとの Secret を使用します。
    • ほとんどのシークレット は、envFrom を介して環境変数としてロードされます。
    • 証明書 (authSigningTlsCrt など) も、volumeMounts を介してファイルとしてマウントされます (通常は /var/run/certs/ 配下) 。
シークレットの値は、チャートごとの Kubernetes Secret と、ランタイム時の pod の環境に存在するため、kubectl get secret から見えなくなるわけではありません。ただし、CSI driver が pod の起動時にそれらを設定するため、values.yaml、ArgoCD の差分、Git には現れません。 Secrets Store CSI driver と Azure Key Vault provider プラグイン は、Vantage より前にクラスターへインストールしておく必要があります。前提条件を参照してください。

​
チャートごとのリソース

シークレットを使用する各 Vantage チャートには、それぞれ専用のリソース一式があります。 このようにチャートごとに分けることで、Key Vault へのアクセスを最小権限に保てます。つまり、あるチャートの SPC が参照するのは、そのチャートが実際に必要とするエイリアスだけです。

​
Service accounts and identity scope

オペレーターは ServiceAccount リソースを作成したり、アノテーションを追加したりしません。各チャートは、標準の Helm 値を通じて独自の SA を提供します。SPC をマウントする各チャートの ServiceAccount を、vantage.secrets.azure.clientId で clientId を指定したユーザー割り当てマネージド ID (UAMI) とフェデレーションするのは、顧客の責任です。その ID には、チャートのエイリアスの参照先となる Key Vault オブジェクトへの読み取りアクセスが必要です。
Key Vault へのアクセスとイメージのプル アクセスは別の要件であり、同じ ServiceAccount に適用されることがあります。UAMI フェデレーション (このページ) はシークレットの読み取りを許可しますが、イメージのプル認証は行いません。プルを行うには、vantage.serviceAccountName で指定された ServiceAccount の imagePullSecrets にレジストリのプル用シークレットを追加するか、代わりに AKS の kubelet ID に AcrPull を付与してください。詳しくは、Image pull access を参照してください。

​
Kubernetes Secrets のプロバイダー

チャートを実行する前に、インストール先の名前空間に Secret リソースを事前に作成しておいてください。objects が定義されていない場合は、デフォルトのシークレット名が使用されます。名前の異なるシークレットを参照するには、objects マッピング (エイリアスごとの secretName) を指定します。 このプロバイダーでは、Secrets Store CSI driver もクラウドの Key Vault も必要ありません。値はクラスター内の Secret オブジェクトから直接読み取られます。 事前チェック時に、オペレーターはシークレット構成を検証します。matched operator チャートと Vantage チャートは、Secret-reader ClusterRole をインストールし、それをオペレーターの ServiceAccount に Vantage リリースの名前空間内でのみバインドします。resourceNames で Secret へのアクセスを制限する場合は、デフォルトおよび上書き後のすべての Secret 名を含めてください。 外部のシークレット管理システムは、引き続き信頼できる情報源として利用できます。たとえば、External Secrets Operator は HashiCorp Vault から Kubernetes Secrets を生成できます。Vantage が使用するのは、生成された Kubernetes Secrets のみであり、External Secrets や Vault に直接接続することはありません。

​
PostgreSQL とサービスごとの Secrets

PostgreSQL を使用するには、vantage.databaseProvider: PostgreSQL を設定します。各サービスには、それぞれ別の論理データベースを指定する接続文字列が必要です。1 つのデータベースを共有すると、サービス間でマイグレーション状態が衝突します。 ワークロードによっては、名前が一意の接続文字列キーを読み取るため、1 つの Secret を共有できます。一方、汎用キー Database__ConnectionString を読み取るワークロードもあります。その場合は、各サービスごとに個別の Secret を作成し、vantage.secrets.kubernetes.objects でそのエイリアスをマップします。
マッピングされた各シークレットには同じキーが含まれていますが、データベース接続文字列はそれぞれ異なります。
認証情報をソース管理にコミットせずに済むよう、シークレット管理システムを使用してこれらの Secrets を作成してください。接続文字列は、先頭・末尾・途中のいずれにも改行文字を含まない 1 行である必要があります。 レポート機能は SQL Server でのみ使用できます。PostgreSQL を使用する場合は、reportingEnabled: false のままにしてください。

​
シークレットのエイリアス

以下のエイリアスは、Vantage のワークロードとお使いのシークレット プロバイダーとの間の取り決めです。Azure プロバイダーでは、最も簡単なのは、Key Vault シークレットの名前をエイリアスに合わせることです。どちらのプロバイダーでも、シークレット構成内の objects マッピングを使って名前を再マッピングできます。

​
プラットフォーム

​
ストレージ

デフォルトの Azure Blob ストレージ バックエンドを使用する場合にのみ必要です。spec.storage.custom が Kubernetes の StorageClass ベースのバックエンド (たとえば NFS) 用に設定されている場合、これらのエイリアスは使用されません。各エイリアスはストレージ アカウントの接続文字列です。各ストレージ 型の用途については、Vantage の基本システム ドキュメントを参照してください。

​
データベース

データベースごとに、それぞれ異なる 接続文字列 を 1 つずつ設定します。データベース名はあくまで例です。接続文字列 が正しいデータベースを指していれば、プロビジョニング処理で生成される名前であればどのようなものでも問題ありません。

​
OAuth

† sendgridApiKey は、SMTP を使用しない場合にのみ必須です。既知の制限事項を参照してください。

​
証明書エイリアス

PEM エンコードされた TLS 関連データが 4 つ必要です。これらは、2 組のシークレットエイリアス (証明書 + 秘密鍵) として扱われます。Azure プロバイダーでは、Key Vault の証明書オブジェクトではなく、Key Vault シークレットとして保存してください。 Azure プロバイダーでは、Key Vault に auth-signing と auth-deactivated という名前の自己署名証明書を 2 つ作成し (Common Name = Vantage の dnsRecord 値) 、続いて上記のエイリアス名に合わせて 4 つの Key Vault シークレットを作成するのが最も簡単です。Kubernetes プロバイダーでは、PEM データを含む Secret リソースを事前に作成します。既定の data キーは auth-signing-tls-crt、auth-signing-tls-key、auth-deactivated-tls-crt、auth-deactivated-tls-key です。objects マッピングを使用して Secret 名を再マッピングします。

​
命名と再マッピング

Azure プロバイダーでは、objects マッピングに記載されていないエイリアスについては、エイリアス自体が Key Vault オブジェクト名として使用されます (secret 型として取得) 。Key Vault オブジェクトの名前がすでにエイリアスと一致している場合、objects マッピングは不要です。Kubernetes プロバイダーでは、objects が定義されていない場合、デフォルトのシークレット名が使用されます。 プロビジョニング プロセスで別の名前を使用している場合は、シークレット設定で objects マッピングを指定してください。
エイリアスはAPIの取り決めであり、オブジェクト名は自由に決められます。

​
必須の権限

Azure Key Vault provider では、Secrets Store CSI driver が使用する ID に、上記に記載されているすべてのシークレットと証明書への 読み取り アクセスが必要です。
  • workloadIdentity (デフォルト) : vantage.secrets.azure.clientId に clientId が指定されているユーザー割り当てマネージド ID。
  • vmManagedIdentity: vantage.secrets.azure.userAssignedIdentityID にクライアント ID が指定されている ID。
  • podIdentity: 検証済みのシナリオではありません。これに依存する前に、ABBYY account team にお問い合わせください。
Kubernetes Secrets provider では、Key Vault やクラウド ID の権限は不要です。インストール先の名前空間に Secret リソースを事前に作成してください。Vantage はそれらを直接使用します。
CSI driver の workload ID (ここでのもの) は、クラスター内の他の workload が使用する workload ID (たとえば、monitoring 用にデプロイする in-mesh Prometheus。Vantage installer は Prometheus をデプロイしません) とは別です。同じ UAMI を使用することも、異なる UAMI を使用することもできます。

​
次のステップ

前提条件

インストール方法を問わず必要となる、クラスターレベルおよび外部サービスの要件。

Azure へのインストール

Azure Key Vault の構成項目と、インストール手順を順を追って説明します。

セルフマネージド Kubernetes

ネイティブな Kubernetes Secrets と PostgreSQL の構成。