Sealed Secrets とは？

Secretのdataはbase64表現で、これ自体は暗号化ではないよ。ファイルを読める人は値を戻せる。クラスター側で保存時の暗号化を有効にしていても、Git上のSecretファイルまで守られるわけではないんだ。

公開鍵で値を暗号化したSealedSecretをGitで管理できるよ。対応する秘密鍵を持つコントローラーが復号して、通常のSecretを生成する。生成したSecretの読み取り権限や保存時の暗号化、秘密鍵の保護は別に必要なんだ。

kubesealというCLIでSecretをSealedSecretに変換するよ。正しい対象の公開鍵証明書を使うことが大切。証明書を取得しておけばオフラインでも暗号化できる。元の平文ファイルや秘密鍵のバックアップを、暗号化したYAMLと一緒に公開しないようにするんだ。

対応する秘密鍵がなければ復号できないよ。ただし、その鍵をバックアップから復元したり共有したりしたクラスターでは復号できる場合がある。既定のstrictスコープでは名前とnamespaceも一致させる必要があるんだ。namespace-wideやcluster-wideは、この名前・namespaceの制約を変える設定で、どのクラスターでも使えるという意味ではないよ。

GitOpsでSealedSecretをクラスターへ適用し、インストール済みのコントローラーにSecretを生成させる流れにできるよ。暗号化した値の管理と、生成したSecretや鍵へのアクセス制御を分けて考えると分かりやすいね。

別の処理だよ。既定では暗号化鍵を定期的に追加し、古い鍵も保持するので過去のデータを復号できる。kubeseal --re-encryptは新しい鍵で暗号化し直す機能で、パスワード自体の変更ではないんだ。Gitの過去版も残るので、漏えいした秘密値は利用先で失効・変更し、鍵のバックアップも安全に管理する必要があるよ。