説明
Kubernetes 標準の Secret は、適切なアクセス制御と保存時の暗号化の下で使用できます。複数のアプリケーションやクラスターで認証情報を管理すると、更新、期限、監査、集中管理が複雑になり、外部シークレットストアとの連携が役立つ場合があります。標準の Secret の使用自体が脆弱性ではありません。
外部ストアでも認証情報の受け渡しとアクセス権限の設定が必要です。KMS による保存時暗号化は機密情報のライフサイクル管理とは別の機能であり、外部の値を Secret に同期すると Kubernetes にもコピーが残る場合があります。
想定される影響
- 手動の更新や期限管理によって、古い認証情報が使われ続ける場合があります。
- 過剰な Secret アクセス権限や、マニフェストに記録した実際の値から機密情報が露出する場合があります。
対処方法
- 規模、監査、更新の要件に応じて、標準の Secret や Vault、クラウドのシークレットストア、Secrets Store CSI Driver などの連携方式を選んでください。KMS 暗号化だけでシークレットストアの機能を代替することはできません。
- どの方式でも最小権限、保存時暗号化、監査を適用し、実際の機密情報をリポジトリにコミットしないでください。更新がファイル、環境変数、アプリケーションに反映される方法と、必要な再起動を確認してください。
例
変更前の値は非本番用の例です。変更後の SecretProviderClass は Azure Key Vault 連携の一部であり、CSI Driver、Azure プロバイダー、使用する ID と Key Vault 権限、Pod の CSI ボリュームマウントは別途設定する必要があります。プレースホルダーは実環境の値に置き換えてください。
変更前
yaml
apiVersion: v1
kind: Secret
metadata:
name: app-secret
stringData:
password: "my-password"
apiToken: "my-token"
マニフェストに機密情報の値を直接記載します。実際の値をコミットすると露出する場合があり、Secret の base64 表現は暗号化ではありません。
変更後
yaml
apiVersion: secrets-store.csi.x-k8s.io/v1
kind: SecretProviderClass
metadata:
name: app-secrets
spec:
provider: azure
parameters:
keyvaultName: "<key-vault-name>"
tenantId: "<tenant-id>"
objects: |
array:
- |
objectName: app-password
objectType: secret
外部の app-password を選択します。このリソースだけで Pod にマウントされたり、既存の Secret が削除されたりするわけではありません。