【Kubernetes】EKS環境における機密情報（シークレット）管理について

Posted at 2025-11-19

はじめに

Kubernetesでアプリケーションを運用する際、データベースの認証情報やAPIキーなどの機密情報（シークレット）を安全に管理することは最重要課題の一つです。

本記事では、特にAWS EKS環境でWordPressなどのアプリケーションをHelm Chartでデプロイするケースを想定し、シークレット管理に関する主要な4つのツール（Helm Secrets, KSOPS, External Secrets, CSI Driver）を比較します。

Kubernetesのシークレット管理ツールは、大きく「リポジトリ暗号化アプローチ」と「外部ストア連携アプローチ」の2つに分類されます。

ツール名	概要	主な利用目的
Helm Secrets	HelmとSOPSを連携させるプラグイン。暗号化されたシークレットをHelm Chartに含め、デプロイ時に復号する。	GitOpsでのシークレットのバージョン管理。
KSOPS	KustomizeとSOPSを連携させるツール。Kustomizeのビルドプロセスで暗号化ファイルを復号する。	Kustomizeを利用した環境でのシークレット管理。

ツール名	概要	主な利用目的
External Secrets Operator (ESO)	外部ストア（AWS Secrets Managerなど）のシークレットを、K8s `Secret` としてクラスター内に自動同期するオペレーター。	外部ストアとの一元管理を保ちつつ、アプリケーションにはネイティブな`Secret`として提供したい場合。
CSI Secrets Store Provider	外部ストアのシークレットを、Podのボリューム（ファイル）として直接マウントするCSIドライバー。	クラスターのetcdにシークレットを保存せず、高いセキュリティを実現したい場合。

AWS EKS環境でWordPressの管理者ID/パスワードを管理する場合、AWSのサービスと連携できる外部ストア連携アプローチが最も推奨されます。

機密情報はAWS Secrets Managerに格納し、EKSのIAM Roles for Service Accounts (IRSA) を利用して、Kubernetesクラスターが安全にアクセスできるように設定します。

理由	詳細
AWS連携	AWS Secrets Managerとの連携がネイティブで、シークレットのライフサイクル（ローテーション、監査）をAWS側で一元管理できます。
Helmとの親和性	ESOは最終的にKubernetesのネイティブな`Secret`オブジェクトを作成します。これにより、Helm Chartは既存の`Secret`を参照するだけでよく、アプリケーション側の修正が不要な場合が多いです。
仕組み	1. ユーザーは`ExternalSecret`リソースを作成し、Secrets Managerのどのシークレットを参照するか定義します。2. ESOがSecrets Managerからシークレットを取得し、K8s `Secret`を作成・更新します。

ESOよりも高いセキュリティを求める場合は、CSI Driverが有効です。

セキュリティ強化の根拠: シークレットがetcdにSecretオブジェクトとして永続的に保存されず、Podの一時的なメモリ/ファイルシステム上にのみ存在します。
考慮事項: アプリケーション（WordPressなど）がシークレットを環境変数ではなく、マウントされたボリューム内のファイルから読み取るように設定を調整する必要があります。

ツール	最適でない理由
Helm Secrets / KSOPS	* セキュリティ: 暗号化されていても、シークレットのコピーがGitリポジトリに存在することになり、理想的ではない。* 運用: シークレットの自動ローテーションに対応できず、更新のたびに手動で暗号化ファイルを再コミットする必要がある。

要件	推奨ツール	補足
セキュリティと運用性のバランスを取る	External Secrets Operator (ESO)	既存のHelm Chartとアプリケーションを最小限の変更で対応可能。
最高レベルのセキュリティを追求する	CSI Secrets Store Provider	etcdにシークレットを保存しない。ただし、アプリケーション側の設定変更が必要となる場合がある。

EKS環境では、AWS Secrets Managerと連携し、鍵の管理をAWSに委ねる外部ストア連携アプローチを採用することが、安全で持続可能なシークレット管理となると思います。