すべてのプロダクト
Search
ドキュメントセンター

Container Service for Kubernetes:csi-secrets-store-provider-alibabacloud を使用した Alibaba Cloud KMS 認証情報のインポート

最終更新日:Mar 26, 2026

csi-secrets-store-provider-alibabacloud を使用すると、Key Management Service (KMS) から ACK クラスターにシークレットをプルできます。これは、CSI (Container Storage Interface) インラインボリュームを介してマウントされたファイルとして、または同期された Kubernetes Secrets として行われます。ファイルシステム API を介して機密データを読み取るアプリケーションは、ファイルマウントアプローチの恩恵を受け、Kubernetes Secret の同期により、認証情報が環境変数として利用可能になります。

image

セキュリティに関する注意事項

プラグインを設定する前に、次のリスクを評価してください。

  • ファイルシステムアクセス:シークレットがファイルシステムを介してアクセス可能な場合、攻撃者は CVE 脆弱性を悪用してクラスターディレクトリを走査し、シークレットを漏洩させる可能性があります。

  • デバッグとログの公開:誤って設定されたデバッグブレークポイントや過剰なログアクセス権限は、シークレットを公開する可能性があります。可能な限り、環境変数を介してシークレットを参照することは避けてください。

  • シークレットの同期:Kubernetes Secret の同期を有効にする場合は、最小権限の原則に従い、アクセス権限を厳密に制限してください。

アプリケーションでシークレットを永続化する必要がない場合は、RRSA を使用して Pod に必要最小限の権限を付与し、GetSecretValue を直接呼び出します。これにより、Pod ファイルシステムまたは Kubernetes Secrets 内でシークレットが公開されることを回避できます。

前提条件

開始する前に、次のことを確認してください。

ステップ 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 クラスターに適用されます。

  1. [ACK コンソール] でクラスターの RRSA を有効化します。 これにより、クラスター用の OpenID Connect (OIDC) ID プロバイダー (IdP) が作成されます。 詳細については、「RRSA の有効化」をご参照ください。

  2. 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-alibabacloud
  3. KMS シークレットへのアクセスを許可するカスタム RAM ポリシーを作成し、前のステップで作成した RAM ロールにアタッチします。ポリシーの内容は次のとおりです。

    {
        "Action": [
           "kms:GetSecretValue",
           "kms:Decrypt"
        ],
        "Resource": [
            "*"
        ],
        "Effect": "Allow"
    }

    詳細については、「カスタムポリシーの作成」および「RAM ロールへの権限付与」をご参照ください。

  4. クラスターに alibaba-credentials Secret を作成します。以下を 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 ARN

    Secret を適用します。

    kubectl apply -f secretstore-rrsa.yaml

Worker RAM ロールへの権限付与

この方法は、ACK マネージドクラスター、ACK 専用クラスター、および登録済みクラスターに適用されます。プラグインは、クラスターの Worker RAM ロールから権限を継承します。

  1. 次の内容でカスタム RAM ポリシーを作成します。詳細については、「カスタムポリシーの作成」をご参照ください。

    {
      "Action": [
        "kms:GetSecretValue",
        "kms:Decrypt"
      ],
      "Resource": [
        "*"
      ],
      "Effect": "Allow"
    }
  2. ポリシーを Worker RAM ロールにアタッチします。詳細については、「Worker RAM ロールへの権限付与」をご参照ください。

この方法では、認証情報 Secret は不要です。

AccessKey ペアを使用した RAM ロールの引き受け

この方法は、すべての ACK クラスタータイプで機能します。RAM ユーザーの AccessKey ペアを使用して、KMS アクセス用の専用 RAM ロールを引き受けます。

  1. 現在の Alibaba Cloud アカウントを信頼する RAM ロールを作成します。プリンシパル名に [現在のアカウント] を選択します。詳細については、「信頼できる Alibaba Cloud アカウント用の RAM ロールを作成する」をご参照ください。

  2. KMS アクセスポリシーを作成して RAM ロールにアタッチします。詳細については、「カスタムポリシーの作成」および「RAM ロールへの権限付与」をご参照ください。ポリシーの内容は次のとおりです。

    {
      "Action": [
        "kms:GetSecretValue",
        "kms:Decrypt"
      ],
      "Resource": [
        "*"
      ],
      "Effect": "Allow"
    }
  3. ロール引き受けポリシーを作成し、使用する 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 ユーザーへの権限付与」をご参照ください。

  4. クラスター内に 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 ロールの ARN

    Secret の適用:

    kubectl apply -f alibaba-credentials.yaml

ステップ 2: csi-secrets-store-provider-alibabacloud のインストール

  1. ACK コンソール」にログインし、左側のナビゲーションウィンドウで [クラスター] をクリックします。

  2. クラスター名をクリックし、左側のナビゲーションウィンドウで [アプリケーション] > [Helm] を選択します。

  3. [Deploy] をクリックします。 「Chart」セクションで [csi-secrets-store-provider-alibabacloud] を検索し、デフォルト設定のままにして [Next] をクリックします。 ダイアログボックスに、インストール名前空間 (kube-system) とリリース名が表示されます。 必要に応じてこれらを調整します。

  4. チャート バージョン」を最新バージョンに設定します。パラメーター セクションで、ステップ 1で選択した認証方式に基づいて値を設定し、「OK」をクリックします。「RRSA」: rrsa.enabletrue に設定します。envVarsFromSecret セクションは、以下のようになります(AccessKey フィールドはコメントアウトされています):

    • secrets-store-csi-driver.enableSecretRotationtrue に設定します。

    • 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: oidcproviderarn

    Worker 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
  5. (オプション) シークレットのローテーションの有効化:マウントされたシークレットを自動的に最新の状態に保つには、次のパラメーターを設定します。

    image

    image

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

    image.png

ステップ 3: SecretProviderClass の定義

SecretProviderClass は、KMS シークレットをアプリケーションが認識するファイルおよび Kubernetes シークレットにマップします。アプリケーションが必要とする各シークレットのセットに対して、1 つずつ作成してください。

パラメーター

spec.parameters セクションは、次のフィールドをサポートします。

objects (必須)

マウントする KMS シークレットを定義する YAML リストです。各エントリは次のサブフィールドをサポートします。

サブフィールド必須説明
objectNameはいKMS Secrets Manager のシークレット名。詳細については、「SecretName」をご参照ください。
objectTypeいいえ同期元のサービス。有効な値: kmsoos。デフォルト: 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 シークレットの場合、ACSPreviousACSCurrent のみがサポートされます。
jmesPathいいえJSON 形式のシークレットから特定のキーを抽出します。path サブフィールド (必須) とオプションで objectAlias が必要です。詳細については、「JMESPath」をご参照ください。
kmsEndpointいいえこのシークレットの KMS エンドポイント。シークレットごとに設定されます。省略された場合、デフォルトの共有ゲートウェイ VPC エンドポイントが使用されます。

region (オプション)

KMS Secrets Manager サーバーのリージョン。省略された場合、プラグインは現在のノードのリージョンを使用します。多数の Pod を持つクラスターの場合、リクエストごとのルックアップオーバーヘッドを回避するためにこのフィールドを指定してください。

pathTranslation (オプション)

シークレット名内のパス区切り文字の置換文字 (例: My/Path/SecretMy_Path_Secret になります)。デフォルト: _。パス区切り文字の置換を無効にするには "False" に設定します。

KMS エンドポイント

各シークレットエントリは kmsEndpoint を指定して、どの KMS ゲートウェイがリクエストを処理するかを制御できます。専用ゲートウェイと共有ゲートウェイの違いの詳細については、「KMS にアクセスするための共有ゲートウェイと専用ゲートウェイの違い」をご参照ください。

ゲートウェイタイプドメインタイプエンドポイント形式要件
専用ゲートウェイKMS プライベートドメイン{kms-instance-id}.cryptoservice.kms.aliyuncs.comクラスターと同じリージョンおよび VPC。KMS インスタンスバージョン 3.0 以降。
共有ゲートウェイVPC ドメインkms-vpc.{region}.aliyuncs.comKMS シークレットと同じリージョン。追加の設定は不要です。
共有ゲートウェイパブリックドメイン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.yaml

2. シークレットをマウントする 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: true
kubectl apply -f deploy.yaml

3. シークレットがマウントされていることの確認

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"            # パブリックエンドポイントを介したクロスリージョンアクセス

次のステップ

参照