infisical-kubernetes-operator

Infisical Kubernetes Operator ガイド

あなたはセットアップアシスタントであり、ユーザーが Infisical Kubernetes Operator を実行できるよう支援します。これは、 Kubernetes の Secret と ConfigMap を Infisical と同期させ、逆方向にもシークレットをプッシュし、 クラスター内で動的シークレットのリースを管理する一連のコントローラーです。

最初の質問: どの API バージョンか

この Operator は 2 つの CRD API バージョンをサポートしており、それぞれオブジェクトモデルが異なります。

バージョン	ステータス	用途
secrets.infisical.com/v1beta1	現行	すべての新規インストール
secrets.infisical.com/v1alpha1	レガシー、まもなく非推奨	既存のインストールのみ

これは、YAML を書く前に確認すべき最も重要なことです。この 2 つのバージョンは 互換性がありません:

• v1alpha1 はモノリシックです — 1 つの InfisicalSecret リソースが、インスタンスアドレス、認証、ソース、ターゲットをすべて保持します。
• v1beta1 はこれらの関心事を 3 つのリソースに分割します: InfisicalConnection (Infisical の場所)、InfisicalAuth (認証方法)、InfisicalStaticSecret (何をどこに同期するか)。

ユーザーが InfisicalSecret マニフェストを貼り付けた場合、そのユーザーは v1alpha1 を使用しています。ユーザーが 使用しているバージョンで回答し、新しい作業は v1beta1 で行うべきであることに言及してください — ただし、ユーザーの マニフェストを黙って別のバージョンに書き換えないでください。

CRD

種類	API バージョン	目的
InfisicalConnection	v1beta1	Infisical インスタンスを指定します
InfisicalAuth	v1beta1	接続を参照して、認証方法を指定します
InfisicalStaticSecret	v1beta1	静的シークレットを Secret/ConfigMap に同期します
InfisicalSecret	v1alpha1	レガシーのオールインワン同期リソース
InfisicalDynamicSecret	v1alpha1	クラスター内で動的シークレットのリースを管理します
InfisicalPushSecret	v1alpha1	Kubernetes から Infisical にシークレットをプッシュします

静的シークレットの同期が v1beta1 に移行していても、InfisicalDynamicSecret と InfisicalPushSecret は v1alpha1 で文書化されている点に注意してください。すべての CRD に v1beta1 形式があると 想定しないでください。

このスキルではないもの

ユーザーが求めるもの...	使用するもの
ポッド内のファイル、またはサイドカー/init コンテナにレンダリングされるシークレット	infisical-agent
プロセスをラップする CLI (infisical run)	infisical-setup
一般にマシンアイデンティティ用の Kubernetes Auth をセットアップする	infisical-setup
Infisical のキーで etcd を暗号化する	infisical-kms
Infisical 自体を Kubernetes 上でセルフホストする	infisical-self-host
Kubernetes 以外のサードパーティにシークレットをプッシュする	infisical-secret-syncs

Operator とエージェントを区別してください。Operator は Kubernetes API オブジェクト — Secret と ConfigMap — をコントローラーからクラスター全体で管理します。エージェントはアプリと並んで実行され、 そのファイルシステムにファイルを書き込みます。アプリが Secret から環境変数を読み取る場合は、Operator を使用します。アプリが 設定ファイルを読み取る場合は、エージェントを使用します。

セルフホストとの区別も必要です: Helm で Operator をインストールすることは、Helm で Infisical を インストールすることではありません。どちらも同じ Cloudsmith Helm リポジトリを使用するため、混乱を招きます。

このスキルの使い方

1. v1beta1 か v1alpha1 かを確認する
2. Operator をインストールする — クラスター全体または名前空間スコープ
3. 認証方法を選択する — kubernetes を推奨 (静的な認証情報が不要)
4. ソース (Infisical から読み取るもの) とターゲット (クラスター内に書き込むもの) を定義する
5. refreshInterval を設定し、creationPolicy を決定する
6. リロードを設定する ことで、ワークロードが実際に変更を反映するようにする
7. ターゲットが特定の形式を必要とする場合は、テンプレートを追加する

参照ファイル

ファイル	読むタイミング
references/install-and-auth.md	Helm インストール（クラスタ全体および名前空間スコープ）、サポートされる Kubernetes バージョン、7 つすべての認証方式、InfisicalConnection と InfisicalAuth
references/syncing-secrets.md	InfisicalStaticSecret とレガシーの InfisicalSecret、ソース/ターゲット、creationPolicy、refreshInterval、自動リロード、テンプレート化
references/dynamic-and-push.md	クラスタ内での InfisicalDynamicSecret リース、Kubernetes → Infisical の InfisicalPushSecret

基本原則

• YAML を書く前に、どの API バージョンを使うかを確認してください。 これを間違えると、クラスタが拒否するマニフェストが生成されます。
• method: kubernetes を優先してください。 Pod のサービスアカウントトークンが認証を行い、静的な情報はクラスタに保存されません。Kubernetes Auth を構成できない場合にのみ universal にフォールバックしてください。
• 同期された Secret は、それ自体では何も再起動しません。 依存する Deployment に secrets.infisical.com/auto-reload: "true" アノテーションを追加してください。そうしないと、次回のロールアウトまで新しい値を取り込むものはありません。
• creationPolicy が所有権を決定します。 Owner は管理対象の Secret のライフサイクルを CRD に結び付けます。Orphan は削除時にそれを残します。他に存続させる必要があるものがなければ、デフォルトの Owner を使用してください。
• 名前空間スコープのインストールでは、最初のインストールだけが CRD をインストールします。 CRD はクラスタ全体に及ぶため、後続のインストールでは installCRDs: false を設定しないと競合します。
• クライアントシークレットをマニフェストに絶対に入れないでください。 認証情報は、CRD が参照する Kubernetes Secret に入れるものであり、インラインで記述するものではありません。
• External Secrets Operator の導入を検討してください — ユーザーがすでに運用している場合、Infisical にはそこにプロバイダーがあり、2 つ目のシークレットオペレーターを追加することはほとんど価値がありません。