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 :
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.
Endossement du rôle : L'application appelle l'API
AssumeRoleWithOIDCen utilisant ce jeton OIDC.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.
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.

Activer pour un cluster existant
Connectez-vous à la console ACK. Dans le volet de navigation de gauche, cliquez sur Clusters.
Cliquez sur le nom de votre cluster. Dans le volet de navigation de gauche, cliquez sur Cluster Information.
-
Dans l'onglet Basic Information, faites défiler jusqu'à la section Security and Auditing et cliquez sur Enable à côté de RRSA OIDC.

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.

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 |
|
|
Compte de service |
|
|
Rôle RAM |
|

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.
Dans la console ACK, cliquez sur le nom de votre cluster. Dans le volet de navigation de gauche, cliquez sur Add-ons.
Sur la page Add-ons, cliquez sur l'onglet Security.
Recherchez ack-pod-identity-webhook et cliquez sur Install.
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é |
Condition |
|
Role Name |
|
La conditionoidc:sublimite l'approbation à un compte de service spécifique dans un namespace donné. Remplacezrrsa-demoetdemo-sapar 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 |
|
|
URL du fournisseur OIDC du cluster — consultez la rubrique Obtenir l'URL et l'ARN du fournisseur OIDC |
|
|
ARN du fournisseur OIDC du cluster — consultez la rubrique Obtenir l'URL et l'ARN du fournisseur OIDC |
|
|
Namespace de l'application |
|
|
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 |
| ARN du rôle RAM à endosser |
| ARN du fournisseur d'identité OIDC | |
| Chemin d'accès au fichier de jeton OIDC | |
| Endpoint VPC STS pour la région actuelle | |
| Identifiant de région pour l'endpoint STS | |
| Indique si l'accès à STS se fait via l'endpoint interne VPC | |
VolumeMount |
| Monte le jeton OIDC dans le conteneur |
Volume |
| 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 |
|
|
ARN du rôle RAM |
Page Roles de la console RAM |
|
|
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. |
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. |
|
|
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. |
|
|
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. |
|
|
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. |
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. | |
OSS Java SDK. Pour obtenir des instructions, consultez la rubrique Utiliser un OIDCRoleARN. | ||
OSS Python SDK. Pour obtenir des instructions, consultez la rubrique Utiliser le rôle d'un IdP OIDC. | ||
Simple Log Service (SLS) | SLS SDK for Java. Pour obtenir des instructions, consultez la rubrique Premiers pas avec Simple Log Service SDK for 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 chargeassume_role_with_oidc. Définissezregionsur 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 |
|
|
L'application a mis en cache le jeton OIDC et utilise une copie expirée. |
Lisez le jeton depuis le fichier ( |
|
|
L'application appelle |
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. |
|
|
Le paramètre |
Définissez |
|
|
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. |
|
|
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. |
|
|
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. |