🎯 はじめに
Kubernetes では Secret リソースを使ってパスワードやAPIキーを管理できますが、実際の運用現場では次のような課題が浮上します。
- シークレットをGit管理できず、更新や共有が煩雑
- base64エンコードのみで暗号化が不十分
- AWS、Azureなど複数クラウドを併用している環境での整合性管理が難しい
この問題を解決するのが、CNCF配下の OSS External Secrets Operator（ESO） です。本記事では、AWS Secrets Manager と Azure Key Vault の両方に対応した導入手順と運用ベストプラクティスを詳しく紹介します。
🧩 External Secrets Operatorとは
External Secrets Operator (ESO) は Kubernetes Operator で、外部シークレットストア（AWS Secrets Manager、Azure Key Vault、Vaultなど）からKubernetes の Secret リソースへ自動同期を行います。
[Secrets Manager / Key Vault]
│
▼
[External Secrets Operator]
│
▼
[Kubernetes Secret]
ESO は外部ストアをポーリングし、更新があれば Secret を再生成。これにより、手動更新不要・安全・自動化されたSecret管理が実現できます。
🚀 External Secrets Operator のインストール
helm repo add external-secrets https://charts.external-secrets.io
helm repo update
helm install external-secrets external-secrets/external-secrets \
--namespace external-secrets --create-namespace
☁️ AWS Secrets Managerとの連携
1. IAMとServiceAccountの設定（IRSA）
eksctl create iamserviceaccount \
--cluster my-cluster \
--namespace external-secrets \
--name eso-service-account \
--attach-policy-arn arn:aws:iam::aws:policy/SecretsManagerReadWrite \
--approve
2. SecretStoreを作成
apiVersion: external-secrets.io/v1beta1
kind: SecretStore
metadata:
name: aws-secret-store
namespace: external-secrets
spec:
provider:
aws:
service: SecretsManager
region: ap-northeast-1
auth:
jwt:
serviceAccountRef:
name: eso-service-account
3. ExternalSecret定義
apiVersion: external-secrets.io/v1beta1
kind: ExternalSecret
metadata:
name: my-db-credentials
spec:
refreshInterval: 1h
secretStoreRef:
name: aws-secret-store
kind: SecretStore
target:
name: my-db-secret
creationPolicy: Owner
data:
- secretKey: username
remoteRef:
key: prod/db
property: username
- secretKey: password
remoteRef:
key: prod/db
property: password
4. Podで利用
env:
- name: DB_USER
valueFrom:
secretKeyRef:
name: my-db-secret
key: username
- name: DB_PASS
valueFrom:
secretKeyRef:
name: my-db-secret
key: password
☁️ Azure Key Vaultとの連携
1. Azure AD アプリ（Service Principal）を作成
az ad sp create-for-rbac --name eso-keyvault-access \
--role "Key Vault Secrets User" \
--scopes /subscriptions/<SUBSCRIPTION_ID>/resourceGroups/<RESOURCE_GROUP>/providers/Microsoft.KeyVault/vaults/<KEYVAULT_NAME>
2. 認証情報をKubernetes Secretに登録
kubectl create secret generic azure-kv-secret \
--from-literal=clientId=<APP_ID> \
--from-literal=clientSecret=<CLIENT_SECRET> \
-n external-secrets
3. SecretStoreを作成
apiVersion: external-secrets.io/v1beta1
kind: SecretStore
metadata:
name: azure-keyvault-store
namespace: external-secrets
spec:
provider:
azurekv:
vaultUrl: "https://<KEYVAULT_NAME>.vault.azure.net/"
tenantId: "<TENANT_ID>"
authSecretRef:
clientId:
name: azure-kv-secret
key: clientId
clientSecret:
name: azure-kv-secret
key: clientSecret
4. ExternalSecret定義
apiVersion: external-secrets.io/v1beta1
kind: ExternalSecret
metadata:
name: azure-db-credentials
spec:
refreshInterval: 30m
secretStoreRef:
name: azure-keyvault-store
kind: SecretStore
target:
name: azure-db-secret
creationPolicy: Owner
data:
- secretKey: username
remoteRef:
key: db-username
- secretKey: password
remoteRef:
key: db-password
5. Podで利用
env:
- name: DB_USER
valueFrom:
secretKeyRef:
name: azure-db-secret
key: username
- name: DB_PASS
valueFrom:
secretKeyRef:
name: azure-db-secret
key: password
🧰 運用ベストプラクティス
1. refreshInterval の最適化
spec:
refreshInterval: 15m
2. マルチNamespace環境では ClusterSecretStore を活用
apiVersion: external-secrets.io/v1beta1
kind: ClusterSecretStore
metadata:
name: global-aws-store
spec:
provider:
aws:
service: SecretsManager
region: ap-northeast-1
auth:
jwt:
serviceAccountRef:
name: eso-service-account
namespace: external-secrets
3. creationPolicy: Owner で自動再作成
Secret が削除されても ESO が自動的に再作成します。
4. GitOpsとの組み合わせ
ArgoCDやFluxCDと組み合わせるときは、ExternalSecretやSecretStoreのマニフェストのみGit管理し、実際のシークレット値はクラウドストアに保存するのがベストです。
5. トラブルシューティングコマンド
kubectl get externalsecret -A
kubectl describe externalsecret my-db-credentials
kubectl logs -n external-secrets deploy/external-secrets -f
⚖️ メリット・デメリットまとめ
| メリット | デメリット |
|---|---|
| シークレットをGitに含めない安全設計 | Operatorの追加管理が必要 |
| AWS / Azure 両対応でマルチクラウドに強い | 初期設定がやや複雑 |
| 自動同期で運用負担軽減 | 認証エラー時のデバッグが難しい場合あり |
🏁 まとめ
External Secrets Operatorを導入することで、Kubernetes環境でも セキュアで自動化されたシークレット管理 を実現できます。
特に以下のようなケースでは導入効果が大きいです。
- AWSとAzureを併用しているマルチクラウド環境
- GitOps運用でSecretを安全に扱いたいチーム
- IaC（Terraform, ArgoCDなど）と統合したセキュリティ設計を行いたい場合