csi-secrets-store-provider-alibabacloud を使用すると、Key Management Service (KMS) から ACK クラスターにシークレットをプルできます。これは、CSI (Container Storage Interface) インラインボリュームを介してマウントされたファイルとして、または同期された Kubernetes Secrets として行われます。ファイルシステム API を介して機密データを読み取るアプリケーションは、ファイルマウントアプローチの恩恵を受け、Kubernetes Secret の同期により、認証情報が環境変数として利用可能になります。
セキュリティに関する注意事項
プラグインを設定する前に、次のリスクを評価してください。
ファイルシステムアクセス:シークレットがファイルシステムを介してアクセス可能な場合、攻撃者は CVE 脆弱性を悪用してクラスターディレクトリを走査し、シークレットを漏洩させる可能性があります。
デバッグとログの公開:誤って設定されたデバッグブレークポイントや過剰なログアクセス権限は、シークレットを公開する可能性があります。可能な限り、環境変数を介してシークレットを参照することは避けてください。
シークレットの同期:Kubernetes Secret の同期を有効にする場合は、最小権限の原則に従い、アクセス権限を厳密に制限してください。
アプリケーションでシークレットを永続化する必要がない場合は、RRSA を使用して Pod に必要最小限の権限を付与し、GetSecretValue を直接呼び出します。これにより、Pod ファイルシステムまたは Kubernetes Secrets 内でシークレットが公開されることを回避できます。
前提条件
開始する前に、次のことを確認してください。
Kubernetes 1.20 以降を実行している ACK クラスター (マネージド、専用、または登録済み)。ACK Serverless クラスターはサポートされていません。詳細については、「ACK マネージドクラスターの作成」および「ACK One 登録済みクラスターの作成」をご参照ください。
クラスターと KMS シークレットが同じリージョンにあること。
ステップ 1: 認証の設定
csi-secrets-store-provider-alibabacloud は、Pod に代わって KMS を呼び出すための権限が必要です。次のいずれかの方法を選択してください。
| 方法 | 適用可能なクラスタータイプ | Kubernetes バージョン |
|---|---|---|
| RRSA (RAM Roles for Service Accounts) | ACK マネージドクラスター | 1.22 以降 |
| Worker RAM ロール | ACK マネージド、専用、および登録済みクラスター | サポートされているすべてのバージョン |
| AccessKey ペア + RAM ロールの引き受け | すべてのクラスタータイプ | サポートされているすべてのバージョン |
RRSA を使用した権限付与
RRSA (RAM Roles for Service Accounts) は、AccessKey ペアを必要とせずに Pod レベルの権限制御を提供し、認証情報の漏洩のリスクを軽減します。この方法は、Kubernetes 1.22 以降を実行する ACK マネージドクラスターおよび ACK Serverless クラスターに適用されます。
[ACK コンソール] でクラスターの RRSA を有効化します。 これにより、クラスター用の OpenID Connect (OIDC) ID プロバイダー (IdP) が作成されます。 詳細については、「RRSA の有効化」をご参照ください。
OIDC IdP 用の RAM ロールを作成します。詳細については、「OIDC IdP 用の RAM ロールの作成」をご参照ください。次のパラメーターを設定します。
上記の値は、プラグインがデフォルトの
kube-system名前空間にインストールされていることを前提としています。別の名前空間にインストールする場合は、kube-systemをその名前空間名に置き換えてください。パラメーター 値 ID プロバイダータイプ OIDC ID プロバイダー ack-rrsa-<cluster_id>(<cluster_id>をご利用のクラスター ID に置き換えてください)条件: oidc:iss デフォルト値を使用 条件: oidc:aud デフォルト値を使用 条件: oidc:sub 手動で追加します。キー: oidc:sub、演算子:StringEquals、値:system:serviceaccount:kube-system:csi-secrets-store-provider-alibabacloudKMS シークレットへのアクセスを許可するカスタム RAM ポリシーを作成し、前のステップで作成した RAM ロールにアタッチします。ポリシーの内容は次のとおりです。
{ "Action": [ "kms:GetSecretValue", "kms:Decrypt" ], "Resource": [ "*" ], "Effect": "Allow" }詳細については、「カスタムポリシーの作成」および「RAM ロールへの権限付与」をご参照ください。
クラスターに
alibaba-credentialsSecret を作成します。以下をsecretstore-rrsa.yamlとして保存し、プレースホルダー値を Base64 エンコードされた文字列に置き換えてください。{rolearn}:ステップ 2 で作成した RAM ロールの ARN{oidcproviderarn}:RRSA が有効になったときに生成された OIDC プロバイダー ARN
apiVersion: v1 kind: Secret metadata: name: alibaba-credentials namespace: kube-system type: Opaque data: rolearn: {rolearn} # Base64-encoded RAM role ARN oidcproviderarn: {oidcproviderarn} # Base64-encoded OIDC provider ARNSecret を適用します。
kubectl apply -f secretstore-rrsa.yaml
Worker RAM ロールへの権限付与
この方法は、ACK マネージドクラスター、ACK 専用クラスター、および登録済みクラスターに適用されます。プラグインは、クラスターの Worker RAM ロールから権限を継承します。
次の内容でカスタム RAM ポリシーを作成します。詳細については、「カスタムポリシーの作成」をご参照ください。
{ "Action": [ "kms:GetSecretValue", "kms:Decrypt" ], "Resource": [ "*" ], "Effect": "Allow" }ポリシーを Worker RAM ロールにアタッチします。詳細については、「Worker RAM ロールへの権限付与」をご参照ください。
この方法では、認証情報 Secret は不要です。
AccessKey ペアを使用した RAM ロールの引き受け
この方法は、すべての ACK クラスタータイプで機能します。RAM ユーザーの AccessKey ペアを使用して、KMS アクセス用の専用 RAM ロールを引き受けます。
現在の Alibaba Cloud アカウントを信頼する RAM ロールを作成します。プリンシパル名に [現在のアカウント] を選択します。詳細については、「信頼できる Alibaba Cloud アカウント用の RAM ロールを作成する」をご参照ください。
KMS アクセスポリシーを作成して RAM ロールにアタッチします。詳細については、「カスタムポリシーの作成」および「RAM ロールへの権限付与」をご参照ください。ポリシーの内容は次のとおりです。
{ "Action": [ "kms:GetSecretValue", "kms:Decrypt" ], "Resource": [ "*" ], "Effect": "Allow" }ロール引き受けポリシーを作成し、使用する AccessKey ペアを持つ RAM ユーザーにアタッチします。これにより、ユーザーが RAM ロールを引き受けることが許可されます。ポリシーの内容 (
<account-id>と<role-name>を実際の値に置き換えてください):{ "Statement": [ { "Action": "sts:AssumeRole", "Effect": "Allow", "Resource": "acs:ram:*:<account-id>:role/<role-name>" } ], "Version": "1" }RAM ロールの ARN を見つけるには、「RAM ロールの ARN を表示する方法」をご参照ください。RAM ユーザーに権限を付与するには、「RAM ユーザーへの権限付与」をご参照ください。
クラスター内に
alibaba-credentialsシークレットを作成します。以下の内容をalibaba-credentials.yamlとして保存し、プレースホルダーの値を Base64 エンコードされた文字列に置き換えます:{rolearn}: ステップ 1 で作成された RAM ロールの ARN{ak}: RAM ユーザーの AccessKey ID{sk}: RAM ユーザーの AccessKey Secret
apiVersion: v1 kind: Secret metadata: name: alibaba-credentials namespace: kube-system type: Opaque data: id: {ak} # Base64 エンコードされた AccessKey ID secret: {sk} # Base64 エンコードされた AccessKey Secret rolearn: {rolearn} # Base64 エンコードされた RAM ロールの ARNSecret の適用:
kubectl apply -f alibaba-credentials.yaml
ステップ 2: csi-secrets-store-provider-alibabacloud のインストール
「ACK コンソール」にログインし、左側のナビゲーションウィンドウで [クラスター] をクリックします。
クラスター名をクリックし、左側のナビゲーションウィンドウで [アプリケーション] > [Helm] を選択します。
[Deploy] をクリックします。 「Chart」セクションで [csi-secrets-store-provider-alibabacloud] を検索し、デフォルト設定のままにして [Next] をクリックします。 ダイアログボックスに、インストール名前空間 (
kube-system) とリリース名が表示されます。 必要に応じてこれらを調整します。「チャート バージョン」を最新バージョンに設定します。パラメーター セクションで、ステップ 1で選択した認証方式に基づいて値を設定し、「OK」をクリックします。「RRSA」:
rrsa.enableをtrueに設定します。envVarsFromSecretセクションは、以下のようになります(AccessKey フィールドはコメントアウトされています):secrets-store-csi-driver.enableSecretRotation:trueに設定します。secrets-store-csi-driver.rotationPollInterval:ポーリング間隔 (秒) (例: 2 分ごとの場合は120)。
envVarsFromSecret: # ACCESS_KEY_ID: # secretKeyRef: alibaba-credentials # key: id # SECRET_ACCESS_KEY: # secretKeyRef: alibaba-credentials # key: secret ALICLOUD_ROLE_ARN: secretKeyRef: alibaba-credentials key: rolearn # ALICLOUD_ROLE_SESSION_NAME: # secretKeyRef: alibaba-credentials # key: rolesessionname # ALICLOUD_ROLE_SESSION_EXPIRATION: # secretKeyRef: alibaba-credentials # key: rolesessionexpiration ALICLOUD_OIDC_PROVIDER_ARN: secretKeyRef: alibaba-credentials key: oidcproviderarnWorker RAM ロール:デフォルトのパラメーター設定を使用します。AccessKey ペア:
envVarsFromSecretを設定して、3 つすべての認証情報フィールドを参照します。envVarsFromSecret: ACCESS_KEY_ID: secretKeyRef: alibaba-credentials key: id SECRET_ACCESS_KEY: secretKeyRef: alibaba-credentials key: secret ALICLOUD_ROLE_ARN: secretKeyRef: alibaba-credentials key: rolearn # ALICLOUD_ROLE_SESSION_NAME: # secretKeyRef: alibaba-credentials # key: rolesessionname # ALICLOUD_ROLE_SESSION_EXPIRATION: # secretKeyRef: alibaba-credentials # key: rolesessionexpiration # ALICLOUD_OIDC_PROVIDER_ARN: # secretKeyRef: alibaba-credentials # key: oidcproviderarn(オプション) シークレットのローテーションの有効化:マウントされたシークレットを自動的に最新の状態に保つには、次のパラメーターを設定します。


インストール後、クラスターの csi-secrets-store-provider-alibabacloud ページですべてのリソースが作成されていることを確認します。

ステップ 3: SecretProviderClass の定義
SecretProviderClass は、KMS シークレットをアプリケーションが認識するファイルおよび Kubernetes シークレットにマップします。アプリケーションが必要とする各シークレットのセットに対して、1 つずつ作成してください。
パラメーター
spec.parameters セクションは、次のフィールドをサポートします。
objects (必須)
マウントする KMS シークレットを定義する YAML リストです。各エントリは次のサブフィールドをサポートします。
| サブフィールド | 必須 | 説明 |
|---|---|---|
objectName | はい | KMS Secrets Manager のシークレット名。詳細については、「SecretName」をご参照ください。 |
objectType | いいえ | 同期元のサービス。有効な値: kms、oos。デフォルト: kms。 |
objectAlias | いいえ | シークレットを Pod にマウントする際に使用されるファイル名。objectName にデフォルト設定されます。 |
objectVersion | いいえ | KMS の VersionId に対応します。ApsaraDB RDS、PolarDB、ApsaraDB for Redis/Tair、RAM、ECS シークレットではサポートされていません。 |
objectVersionLabel | いいえ | KMS の VersionStage に対応します。RAM、RDS、PolarDB、Redis、Tair、ECS シークレットの場合、ACSPrevious と ACSCurrent のみがサポートされます。 |
jmesPath | いいえ | JSON 形式のシークレットから特定のキーを抽出します。path サブフィールド (必須) とオプションで objectAlias が必要です。詳細については、「JMESPath」をご参照ください。 |
kmsEndpoint | いいえ | このシークレットの KMS エンドポイント。シークレットごとに設定されます。省略された場合、デフォルトの共有ゲートウェイ VPC エンドポイントが使用されます。 |
region (オプション)
KMS Secrets Manager サーバーのリージョン。省略された場合、プラグインは現在のノードのリージョンを使用します。多数の Pod を持つクラスターの場合、リクエストごとのルックアップオーバーヘッドを回避するためにこのフィールドを指定してください。
pathTranslation (オプション)
シークレット名内のパス区切り文字の置換文字 (例: My/Path/Secret は My_Path_Secret になります)。デフォルト: _。パス区切り文字の置換を無効にするには "False" に設定します。
KMS エンドポイント
各シークレットエントリは kmsEndpoint を指定して、どの KMS ゲートウェイがリクエストを処理するかを制御できます。専用ゲートウェイと共有ゲートウェイの違いの詳細については、「KMS にアクセスするための共有ゲートウェイと専用ゲートウェイの違い」をご参照ください。
| ゲートウェイタイプ | ドメインタイプ | エンドポイント形式 | 要件 |
|---|---|---|---|
| 専用ゲートウェイ | KMS プライベートドメイン | {kms-instance-id}.cryptoservice.kms.aliyuncs.com | クラスターと同じリージョンおよび VPC。KMS インスタンスバージョン 3.0 以降。 |
| 共有ゲートウェイ | VPC ドメイン | kms-vpc.{region}.aliyuncs.com | KMS シークレットと同じリージョン。追加の設定は不要です。 |
| 共有ゲートウェイ | パブリックドメイン | kms.{region}.aliyuncs.com | クラスターはパブリックネットワークアクセスを持っている必要があります。 |
kmsEndpoint を省略すると、共有ゲートウェイ VPC エンドポイント (デフォルト) が使用されます。
例
この例では、KMS から test-hangzhou シークレットをインポートし、NGINX Pod にマウントします。
1. SecretProviderClass の作成
以下を secretstore.yaml として保存します。
apiVersion: secrets-store.csi.x-k8s.io/v1
kind: SecretProviderClass
metadata:
name: test
spec:
provider: alibabacloud
parameters:
objects: |
- objectName: "test-hangzhou"
objectType: "kms"
objectAlias: "hangzhou-public"
kmsEndpoint: "kms.{region}.aliyuncs.com" # 共有ゲートウェイ、パブリックエンドポイント
- objectName: "test-hangzhou"
objectType: "kms"
objectAlias: "hangzhou-vpc"
# kmsEndpoint omitted — デフォルトの共有ゲートウェイ VPC エンドポイントを使用
- objectName: "test-hangzhou"
objectType: "kms"
objectAlias: "hangzhou-cryptoservice"
kmsEndpoint: "{kms-instance-id}.cryptoservice.kms.aliyuncs.com" # 専用ゲートウェイ
- objectName: "test-london"
objectAlias: "london-public"
kmsEndpoint: "kms.{region}.aliyuncs.com" # パブリックエンドポイント経由のクロスリージョンアクセスkubectl apply -f secretstore.yaml2. シークレットをマウントする Deployment の作成
以下を deploy.yaml として保存します。Deployment は SecretProviderClass を CSI インラインボリュームとして /mnt/secrets-store にマウントします。
その他の例については、「Deployment の例」をご参照ください。
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment-basic
labels:
app: nginx
spec:
replicas: 2
selector:
matchLabels:
app: nginx
template:
metadata:
labels:
app: nginx
spec:
volumes:
- name: secrets-store-inline
csi:
driver: secrets-store.csi.k8s.io
readOnly: true
volumeAttributes:
secretProviderClass: "test-secrets" # SecretProviderClass 名と一致する必要があります
containers:
- name: nginx
image: anolis-registry.cn-zhangjiakou.cr.aliyuncs.com/openanolis/nginx:1.14.1-8.6
ports:
- containerPort: 80
resources:
limits:
cpu: "500m"
volumeMounts:
- name: secrets-store-inline
mountPath: "/mnt/secrets-store"
readOnly: truekubectl apply -f deploy.yaml3. シークレットがマウントされていることの確認
Pod が実行された後、Pod にログインし、SecretProviderClass で指定されたシークレットがマウントポイント /mnt/secrets-store に作成されているかどうか、およびシークレットに KMS に保存されている対応する暗号文が含まれているかどうかを確認します。
マルチエンドポイントの例
次の SecretProviderClass は、単一の構成で異なる KMS ゲートウェイを介してシークレットにアクセスする方法を示しています。すべてのエントリは KMS シークレットを参照し、kmsEndpoint フィールドは、各リクエストがどのゲートウェイを使用するかを制御します。
apiVersion: secrets-store.csi.x-k8s.io/v1
kind: SecretProviderClass
metadata:
name: test
spec:
provider: alibabacloud
parameters:
objects: |
- objectName: "test-hangzhou"
objectType: "kms"
objectAlias: "hangzhou-public"
kmsEndpoint: "kms.{region}.aliyuncs.com" # 共有ゲートウェイ、パブリックエンドポイント
- objectName: "test-hangzhou"
objectType: "kms"
objectAlias: "hangzhou-vpc"
# kmsEndpoint は省略されています — デフォルトの共有ゲートウェイ VPC エンドポイントを使用します
- objectName: "test-hangzhou"
objectType: "kms"
objectAlias: "hangzhou-cryptoservice"
kmsEndpoint: "{kms-instance-id}.cryptoservice.kms.aliyuncs.com" # 専用ゲートウェイ
- objectName: "test-london"
objectAlias: "london-public"
kmsEndpoint: "kms.{region}.aliyuncs.com" # パブリックエンドポイントを介したクロスリージョンアクセス次のステップ
KMS から ACK Serverless クラスターにシークレットをインポートするには、「ack-secret-manager を使用した KMS からのシークレットのインポート」をご参照ください。
KMS を使用して ACK クラスター内のキャッシュされたシークレットを暗号化するには、「KMS を使用した Kubernetes Secrets の暗号化」をご参照ください。