Tous les produits
Search
Centre de documentation

Container Service for Kubernetes:Utiliser RRSA pour le contrôle d'accès au niveau des pods

Dernière mise à jour :Sep 12, 2026

Attribuez à chaque pod un rôle RAM dédié avec des jetons STS éphémères plutôt que d'utiliser des identifiants partagés au niveau du nœud.

RRSA offre deux propriétés de sécurité essentielles :

  • Privilège minimum : Limitez les autorisations RAM à un compte de service spécifique, afin que seuls les pods utilisant ce compte puissent accéder aux ressources concernées. Cette approche élimine le besoin de paires AccessKey statiques.

  • Isolation des identifiants : Les pods ne peuvent pas accéder aux identifiants utilisés par d'autres pods sur le même nœud. Sans RRSA, tous les pods d'un nœud partagent les autorisations du rôle d'instance Elastic Compute Service (ECS) sous-jacent.

Fonctionnement de RRSA

Sans RRSA, tous les pods d'un nœud partagent les autorisations du rôle d'instance ECS via les métadonnées d'instance, ce qui constitue un risque de sécurité majeur.

RRSA résout ce problème en associant un rôle RAM à un compte de service Kubernetes. Au démarrage d'un pod, celui-ci reçoit un jeton OpenID Connect (OIDC) limité à son compte de service, appelle l'API AssumeRoleWithOIDC, puis obtient un jeton STS limité au rôle pour accéder aux API cloud.

Le flux d'authentification est le suivant :

  1. Injection du jeton : Lorsqu'un pod démarre, ACK utilise la projection de volume de jeton de compte de service pour monter un fichier de jeton OIDC limité au compte de service du pod.

  2. Endossement du rôle : L'application appelle l'API AssumeRoleWithOIDC en utilisant ce jeton OIDC.

  3. Réception des identifiants STS : Alibaba Cloud RAM vérifie le jeton OIDC auprès du fournisseur OIDC du cluster et renvoie des identifiants STS limités au rôle.

  4. Accès aux ressources : Le pod utilise les identifiants STS éphémères pour accéder aux API Alibaba Cloud autorisées.

Les jetons OIDC sont éphémères. Lisez le jeton depuis le fichier à chaque demande d'authentification — ne le mettez pas en cache. ACK renouvelle automatiquement les jetons avant leur expiration.

Lorsque RRSA est activé, ACK effectue automatiquement les opérations suivantes :

  • Crée un émetteur OIDC dédié pour le cluster.

  • Active la projection de volume de jeton de compte de service pour le cluster.

  • Crée un fournisseur d'identité (IdP) RAM dans votre compte, nommé ack-rrsa-<cluster_id>, configuré pour l'authentification unique (SSO) avec l'émetteur OIDC du cluster.

Avant de commencer

Vérifiez les points suivants avant de configurer RRSA :

  • Version du cluster : Le cluster ACK (Basic, Pro, Serverless ou Edge) exécute Kubernetes 1.22 ou une version ultérieure.

  • Autorisations : Accès administratif aux consoles ACK et RAM.

  • Limite de validité des jetons : Après l'activation de RRSA, les jetons ServiceAccount nouvellement créés ont une validité maximale de 12 heures.

Étape 1 : Activer RRSA pour votre cluster

Activez RRSA lors de la création du cluster ou après son déploiement. Pour les clusters ACK Serverless, activez RRSA après la création du cluster depuis la page des détails du cluster.

Activer lors de la création du cluster

Lors de la création d'un cluster ACK managé ou d'un cluster ACK Edge, accédez à l'étape Cluster Configurations, développez Advanced Options (Optional), puis cliquez sur Enable à côté de RRSA OIDC.

image

Activer pour un cluster existant

  1. Connectez-vous à la console ACK. Dans le volet de navigation de gauche, cliquez sur Clusters.

  2. Cliquez sur le nom de votre cluster. Dans le volet de navigation de gauche, cliquez sur Cluster Information.

  3. Dans l'onglet Basic Information, faites défiler jusqu'à la section Security and Auditing et cliquez sur Enable à côté de RRSA OIDC.

    image

  4. Dans la boîte de dialogue Enable RRSA, cliquez sur Confirm. Attendez que l'état du cluster passe de Updating à Running. RRSA est désormais activé.

Obtenir l'URL et l'ARN du fournisseur OIDC

Une fois RRSA activé, survolez l'étiquette Enabled à côté de RRSA OIDC dans la section Security and Auditing. L'URL et le nom de ressource Alibaba Cloud (ARN) du fournisseur OIDC s'affichent.

image

Notez ces deux valeurs, car vous en aurez besoin pour configurer les rôles RAM et les modèles d'application.

Étape 2 : Configurer une application pour utiliser RRSA

La configuration d'une application exemple comporte deux volets :

  • Configuration au niveau du cluster (à effectuer une fois par cluster) : Activez RRSA et installez ack-pod-identity-webhook.

  • Configuration par application (à répéter pour chaque application) : Créez ou utilisez un rôle RAM existant, accordez les autorisations nécessaires, puis déployez l'application.

Configuration exemple

Élément

Valeur

Namespace

rrsa-demo

Compte de service

demo-sa

Rôle RAM

demo-role-for-rrsa

Sample workflow

1. Installer ack-pod-identity-webhook

ack-pod-identity-webhook injecte automatiquement le chemin du fichier de jeton OIDC et l'ARN du rôle RAM dans les pods sous forme de variables d'environnement. Ignorez cette étape si vous souhaitez configurer manuellement les modèles de pod. Consultez la rubrique Configurer manuellement les modèles de pod.

  1. Dans la console ACK, cliquez sur le nom de votre cluster. Dans le volet de navigation de gauche, cliquez sur Add-ons.

  2. Sur la page Add-ons, cliquez sur l'onglet Security.

  3. Recherchez ack-pod-identity-webhook et cliquez sur Install.

  4. Confirmez les informations et cliquez sur OK.

2. Créer ou configurer un rôle RAM pour le fournisseur d'identité OIDC

Créer un rôle RAM

Créez un rôle RAM nommé demo-role-for-rrsa qui approuve le fournisseur d'identité (IdP) OIDC du cluster. Consultez la rubrique Créer un rôle RAM pour un IdP OIDC.

Utilisez les valeurs de paramètre suivantes :

Paramètre

Valeur

Identity Provider Type

Sélectionnez OIDC.

Identity Provider

Sélectionnez l'IdP nommé ack-rrsa-<cluster_id>, où <cluster_id> correspond à l'ID de votre cluster.

Condition

  • oidc:iss : Conservez la valeur par défaut.

  • oidc:aud : Conservez la valeur par défaut.

  • oidc:sub : Ajoutez manuellement cette condition.

    • Key : Sélectionnez oidc:sub

    • Operator : Sélectionnez StringEquals

    • Value : Saisissez system:serviceaccount:<namespace>:<serviceAccountName>, où <namespace> est le namespace de votre application et <serviceAccountName> est le nom du compte de service. Pour l'application de test présentée dans cette rubrique, saisissez system:serviceaccount:rrsa-demo:demo-sa.

Role Name

demo-role-for-rrsa

La condition oidc:sub limite l'approbation à un compte de service spécifique dans un namespace donné. Remplacez rrsa-demo et demo-sa par votre namespace et le nom de votre compte de service réels.

Configurer un rôle RAM existant

Pour utiliser un rôle RAM existant, mettez à jour sa stratégie d'approbation afin d'autoriser le compte de service à l'endosser. Consultez la rubrique Modifier la stratégie d'approbation d'un rôle RAM.

Ajoutez une entrée Statement avec la structure suivante :

{
  "Action": "sts:AssumeRole",
  "Condition": {
    "StringEquals": {
      "oidc:aud": "sts.aliyuncs.com",
      "oidc:iss": "<oidc_issuer_url>",
      "oidc:sub": "system:serviceaccount:<namespace>:<service_account>"
    }
  },
  "Effect": "Allow",
  "Principal": {
    "Federated": [
      "<oidc_provider_arn>"
    ]
  }
}

Remplacez les espaces réservés :

Espace réservé

Valeur

<oidc_issuer_url>

URL du fournisseur OIDC du cluster — consultez la rubrique Obtenir l'URL et l'ARN du fournisseur OIDC

<oidc_provider_arn>

ARN du fournisseur OIDC du cluster — consultez la rubrique Obtenir l'URL et l'ARN du fournisseur OIDC

<namespace>

Namespace de l'application

<service_account>

Compte de service utilisé par l'application

Pour automatiser les mises à jour de la stratégie d'approbation, utilisez ack-ram-tool :

ack-ram-tool rrsa associate-role --cluster-id <cluster_id> \
    --namespace <namespace> --service-account <service_account> \
    --role-name <role_name> --create-role-if-not-exist

3. Accorder des autorisations au rôle RAM

Attachez la stratégie AliyunCSReadOnlyAccess au rôle demo-role-for-rrsa. Consultez la rubrique Accorder des autorisations à un rôle RAM.

Cette opération accorde à l'application un accès en lecture seule aux informations du cluster ACK.

4. Déployer votre application

Créez un fichier nommé demo.yaml avec le contenu suivant. L'étiquette de namespace pod-identity.alibabacloud.com/injection: 'on' et l'annotation du compte de service pod-identity.alibabacloud.com/role-name: demo-role-for-rrsa activent l'injection automatique par ack-pod-identity-webhook. Consultez la rubrique ack-pod-identity-webhook.

---
apiVersion: v1
kind: Namespace
metadata:
  name: rrsa-demo
  labels:
    pod-identity.alibabacloud.com/injection: 'on'

---
apiVersion: v1
kind: ServiceAccount
metadata:
  name: demo-sa
  namespace: rrsa-demo
  annotations:
    pod-identity.alibabacloud.com/role-name: demo-role-for-rrsa

---
apiVersion: v1
kind: Pod
metadata:
  name: demo
  namespace: rrsa-demo
spec:
  serviceAccountName: demo-sa
  containers:
    - image: registry.cn-hangzhou.aliyuncs.com/acs/ack-ram-tool:1.3.0
      args:
        - rrsa
        - demo
      name: demo
  restartPolicy: OnFailure

Déployez l'application :

kubectl apply -f demo.yaml

5. Vérifier la configuration injectée

Confirmez que ack-pod-identity-webhook a injecté les variables d'environnement et les montages de volume requis :

kubectl -n rrsa-demo get pod demo -o yaml

La sortie attendue inclut les éléments injectés suivants :

Catégorie

Élément

Description

Variable d'environnement

ALIBABA_CLOUD_ROLE_ARN

ARN du rôle RAM à endosser

ALIBABA_CLOUD_OIDC_PROVIDER_ARN

ARN du fournisseur d'identité OIDC

ALIBABA_CLOUD_OIDC_TOKEN_FILE

Chemin d'accès au fichier de jeton OIDC

ALIBABA_CLOUD_STS_ENDPOINT

Endpoint VPC STS pour la région actuelle

ALIBABA_CLOUD_STS_REGION

Identifiant de région pour l'endpoint STS

ALIBABA_CLOUD_VPC_ENDPOINT_ENABLED

Indique si l'accès à STS se fait via l'endpoint interne VPC

VolumeMount

rrsa-oidc-token

Monte le jeton OIDC dans le conteneur

Volume

rrsa-oidc-token

Source de volume projeté pour le jeton OIDC

Voici à quoi ressemble une spécification de pod correctement injectée :

apiVersion: v1
kind: Pod
metadata:
  name: demo
  namespace: rrsa-demo
spec:
  containers:
  - args:
    - rrsa
    - demo
    env:
    - name: ALIBABA_CLOUD_ROLE_ARN
      value: acs:ram::1***:role/demo-role-for-rrsa
    - name: ALIBABA_CLOUD_OIDC_PROVIDER_ARN
      value: acs:ram::1***:oidc-provider/ack-rrsa-c***
    - name: ALIBABA_CLOUD_OIDC_TOKEN_FILE
      value: /var/run/secrets/ack.alibabacloud.com/rrsa-tokens/token
    - name: ALIBABA_CLOUD_STS_ENDPOINT
      value: sts-vpc.cn-hangzhou.aliyuncs.com
    - name: ALIBABA_CLOUD_STS_REGION
      value: cn-hangzhou
    - name: ALIBABA_CLOUD_VPC_ENDPOINT_ENABLED
      value: "true"
    image: registry.cn-hangzhou.aliyuncs.com/acs/ack-ram-tool:1.3.0
    imagePullPolicy: Always
    name: demo
    volumeMounts:
    - mountPath: /var/run/secrets/kubernetes.io/serviceaccount
      name: kube-api-access-4bwdg
      readOnly: true
    - mountPath: /var/run/secrets/ack.alibabacloud.com/rrsa-tokens
      name: rrsa-oidc-token
      readOnly: true
  restartPolicy: OnFailure
  serviceAccount: demo-sa
  serviceAccountName: demo-sa
  volumes:
  - name: kube-api-access-4bwdg
    projected:
      defaultMode: 420
      sources:
      - serviceAccountToken:
          expirationSeconds: 3607
          path: token
      - configMap:
          items:
          - key: ca.crt
            path: ca.crt
          name: kube-root-ca.crt
      - downwardAPI:
          items:
          - fieldRef:
              apiVersion: v1
              fieldPath: metadata.namespace
            path: namespace
  - name: rrsa-oidc-token
    projected:
      defaultMode: 420
      sources:
      - serviceAccountToken:
          audience: sts.aliyuncs.com
          expirationSeconds: 3600
          path: token

6. Consulter les journaux de l'application

Affichez les journaux de l'application :

kubectl -n rrsa-demo logs demo

En cas de réussite, la commande liste les clusters de votre compte Alibaba Cloud :

cluster id: cf***, cluster name: foo*
cluster id: c8***, cluster name: bar*
cluster id: c4***, cluster name: foob*

Facultatif : Pour vérifier l'application du principe de privilège minimum, détachez la stratégie AliyunCSReadOnlyAccess du rôle RAM (consultez la rubrique Supprimer des autorisations d'un rôle RAM). Attendez 30 secondes, puis exécutez à nouveau la commande d'affichage des journaux. L'application renvoie une erreur 403 similaire à celle-ci :

   StatusCode: 403
   Code: StatusForbidden
   Message: code: 403, STSToken policy Forbidden for action cs:DescribeClustersForRegion request id: E78A2E2D-***
   Data: {"accessDeniedDetail":{"AuthAction":"cs:DescribeClustersForRegion","AuthPrincipalDisplayName":"demo-role-for-rrsa:ack-ram-tool","AuthPrincipalOwnerId":"11***","AuthPrincipalType":"AssumedRoleUser","NoPermissionType":"ImplicitDeny","PolicyType":"ResourceGroupLevelIdentityBasedPolicy"},"code":"StatusForbidden","message":"STSToken policy Forbidden for action cs:DescribeClustersForRegion","requestId":"E78A2E2D-***","status":403,"statusCode":403}

Cela confirme que RRSA applique les autorisations au niveau du pod.

Avancé : Configurer manuellement les modèles de pod

Pour éviter d'utiliser ack-pod-identity-webhook, ajoutez manuellement les variables d'environnement requises et le volume projeté à la spécification du pod :

apiVersion: v1
kind: Pod
metadata:
  name: demo
  namespace: rrsa-demo
spec:
  containers:
  - args:
    - rrsa
    - demo
    env:
    - name: ALIBABA_CLOUD_ROLE_ARN
      value: <role_arn>
    - name: ALIBABA_CLOUD_OIDC_PROVIDER_ARN
      value: <oidc_provider_arn>
    - name: ALIBABA_CLOUD_OIDC_TOKEN_FILE
      value: /var/run/secrets/ack.alibabacloud.com/rrsa-tokens/token
    image: registry.cn-hangzhou.aliyuncs.com/acs/ack-ram-tool:1.3.0
    imagePullPolicy: Always
    name: demo
    volumeMounts:
    - mountPath: /var/run/secrets/ack.alibabacloud.com/rrsa-tokens
      name: rrsa-oidc-token
      readOnly: true
  restartPolicy: OnFailure
  serviceAccount: demo-sa
  serviceAccountName: demo-sa
  volumes:
  - name: rrsa-oidc-token
    projected:
      defaultMode: 420
      sources:
      - serviceAccountToken:
          audience: sts.aliyuncs.com
          expirationSeconds: 3600
          path: token

Remplacez les valeurs des espaces réservés :

Espace réservé

Valeur

Où le trouver

<role_arn>

ARN du rôle RAM

Page Roles de la console RAM

<oidc_provider_arn>

ARN du fournisseur OIDC

Section Security and Auditing de la page des détails du cluster. Consultez la rubrique Obtenir l'URL et l'ARN du fournisseur OIDC.

Important

Définissez audience sur sts.aliyuncs.com. Il s'agit de l'ID client du fournisseur OIDC, et non du domaine de l'endpoint STS utilisé par le SDK.

Définissez expirationSeconds sur une valeur comprise entre 600 et 43200 (secondes). Les valeurs supérieures à 43200 sont plafonnées à 12 heures.

Après le redéploiement, l'application lit le jeton OIDC depuis ALIBABA_CLOUD_OIDC_TOKEN_FILE, l'échange contre un jeton STS via AssumeRoleWithOIDC, puis appelle les API cloud avec le jeton STS. Consultez la rubrique AssumeRoleWithOIDC.

Prise en charge par les SDK

Le SDK Alibaba Cloud V2.0 prend en charge l'authentification par jeton OIDC RRSA. Tout SDK de service cloud basé sur la version 2.0 qui prend en charge les jetons STS est également compatible avec RRSA.

Versions de SDK prises en charge et démos

Langage

Version minimale

Démo

Go

Alibaba Cloud Credentials for Go 1.2.6 ou ultérieure. Pour obtenir des instructions, consultez la rubrique Méthode 6 : Utiliser OIDCRoleArn.

Démo Go SDK

Java

Alibaba Cloud Credentials for Java 0.2.10 ou ultérieure. Pour obtenir des instructions, consultez la rubrique Méthode 6 : ARN de rôle OIDC.

Démo Java SDK

Python 3

Alibaba Cloud Credentials for Python 0.3.1 ou ultérieure. Pour obtenir des instructions, consultez la rubrique Gérer les identifiants d'accès.

Démo Python SDK

Node.js / TypeScript

Alibaba Cloud Credentials for TypeScript/Node.js 2.2.6 ou ultérieure. Pour obtenir des instructions, consultez la rubrique Méthode 6 : Utiliser OIDCRoleArn.

Démo Node.js SDK

Consultez la documentation relative aux identifiants pour chaque langage — Méthode 6 : Utiliser le rôle RAM d'un IdP OIDC.

Démos de SDK spécifiques aux services cloud

Certains SDK de services cloud offrent une prise en charge native des jetons OIDC :

Service cloud

SDK

Démo

Object Storage Service (OSS)

OSS Go SDK. Pour obtenir des instructions, consultez la rubrique Méthode 5 : Utiliser un ARN de rôle OIDC.

Démo Go

OSS Java SDK. Pour obtenir des instructions, consultez la rubrique Utiliser un OIDCRoleARN.

Démo Java

OSS Python SDK. Pour obtenir des instructions, consultez la rubrique Utiliser le rôle d'un IdP OIDC.

Démo Python

Simple Log Service (SLS)

SLS SDK for Java. Pour obtenir des instructions, consultez la rubrique Premiers pas avec Simple Log Service SDK for Java.

Démo Java

Activer l'authentification RRSA pour les interfaces CLI

Utilisez ack-ram-tool pour configurer les interfaces CLI afin qu'elles utilisent l'authentification par jeton OIDC RRSA depuis un pod.

Alibaba Cloud CLI

Alibaba Cloud CLI v3.0.206 et versions ultérieures prennent en charge RRSA. Définissez region_id sur votre région cible.

Option A : Fichier de configuration. Définissez mode sur OIDC dans ~/.aliyun/config.json :

{
  "current": "rrsa",
  "profiles": [
    {
      "name": "rrsa",
      "mode": "OIDC",
      "region_id": "cn-hangzhou",
      "ram_session_name": "test-rrsa"
    }
  ],
  "meta_path": ""
}

Option B : Commande directe (aucun fichier de configuration requis) :

aliyun sts GetCallerIdentity --region cn-hangzhou --role-session-name=test-rrsa

Sortie attendue :

{
  "AccountId": "11380***",
  "Arn": "acs:ram::1138***:assumed-role/test-rrsa-***/test-rrsa",
  "IdentityType": "AssumedRoleUser",
  "PrincipalId": "33300***:test-rrsa",
  "RequestId": "20F78881-F47E-5771-90D6-***",
  "RoleId": "33300***"
}

Consultez la rubrique Types d'identifiants.

ossutil 2,0

ossutil V2.1.0 et versions ultérieures prennent en charge RRSA. Remplacez region par votre région réelle.

Définissez mode sur oidcRoleArn dans ~/.ossutilconfig :

cat <<EOF > ~/.ossutilconfig
[default]
mode = oidcRoleArn
OIDCProviderArn = "${ALIBABA_CLOUD_OIDC_PROVIDER_ARN}"
OIDCTokenFilePath = "${ALIBABA_CLOUD_OIDC_TOKEN_FILE}"
roleArn = "${ALIBABA_CLOUD_ROLE_ARN}"
roleSessionName = test-rrsa
region = cn-hangzhou
EOF

Consultez la section Exemples de la documentation ossutil 2,0.

Simple Log Service CLI

Simple Log Service CLI ne prend pas en charge les fichiers de configuration OIDC. Utilisez ack-ram-tool pour injecter les identifiants au moment de l'exécution :

ack-ram-tool export-credentials -f environment-variables -- aliyunlog log list_project --region-endpoint=cn-hangzhou.log.aliyuncs.com

Terraform

Alibaba Cloud Provider V1.222.0 et versions ultérieures prennent en charge assume_role_with_oidc . Définissez region sur votre région cible.

Ajoutez assume_role_with_oidc à la configuration de votre fournisseur :

provider "alicloud" {
  assume_role_with_oidc {
    role_session_name = "terraform-with-rrsa-auth-example"
  }
  region = "cn-hangzhou"
}

Consultez la démo Terraform RRSA.

Dépannage

Erreurs de SDK

Erreur

Cause

Solution

AuthenticationFail.OIDCToken.Expired — « This JsonWebToken is expired. »

L'application a mis en cache le jeton OIDC et utilise une copie expirée.

Lisez le jeton depuis le fichier (ALIBABA_CLOUD_OIDC_TOKEN_FILE) à chaque authentification. Utilisez un SDK Alibaba Cloud pour gérer cette opération automatiquement. Consultez la section Prise en charge par les SDK.

Throttling.User — « Request was denied due to user flow control. »

L'application appelle AssumeRoleWithOIDC trop fréquemment.

Réutilisez le jeton STS jusqu'à son expiration. Utilisez un SDK Alibaba Cloud pour la gestion automatique des jetons. Consultez la section Prise en charge par les SDK.

AuthenticationFail.OIDCToken.AudienceNotMatch — « Invalid audience. »

Le paramètre audience dans la spécification du pod n'est pas défini sur sts.aliyuncs.com.

Définissez audience: sts.aliyuncs.com dans la source de volume projeté de la spécification du pod.

AuthenticationFail.OIDCToken.IssuerConfigurationBroken / IssuerNotMatch / AuthenticationFail.NoPermission — « No such OIDC Provider registered. »

RRSA n'est pas activé pour le cluster.

Consultez l'Étape 1 : Activer RRSA pour votre cluster. Après l'activation, recréez tous les pods qui utilisent RRSA.

EntityNotExist.Role — « The role not exists: acs:ram::... »

Le rôle RAM endossé par l'application n'existe pas.

Créez le rôle RAM. Consultez les rubriques Créer un rôle RAM pour un IdP OIDC et Étape 2 : Créer un rôle RAM pour le fournisseur d'identité OIDC.

AuthenticationFail.NoPermission — « There is no permission »

La stratégie d'approbation du rôle RAM n'autorise pas le compte de service à l'endosser.

Mettez à jour la stratégie d'approbation. Consultez la section Configurer un rôle RAM existant.

Références