Resource Access Management:Présentation des rôles RAM

Qu'est-ce qu'un rôle RAM ?

Un rôle RAM est un type d'identité RAM auquel sont associées des politiques. Contrairement à un utilisateur RAM, un rôle n'est pas lié à une personne ou à une application spécifique : toute entité de confiance peut l'endosser. Les rôles ne disposent pas d'identifiants permanents tels que des mots de passe ou des paires AccessKey. Lorsqu'une entité endosse un rôle, le Security Token Service (STS) génère des identifiants de sécurité temporaires, valables uniquement pour la durée de cette session.

Chaque rôle RAM constitue une ressource au sein de votre compte et possède un Alibaba Cloud Resource Name (ARN) unique : acs:ram::<account-id>:role/<role-name>. Cet ARN sert à référencer le rôle dans les politiques ou les appels API. Pour consulter l'ARN d'un rôle, reportez-vous à la rubrique Afficher un rôle RAM.

Les rôles RAM et les utilisateurs RAM sont gérés via des menus distincts de la console :

• Rôles RAM : Dans le volet de navigation de gauche, choisissez Identity Management > Roles.

• Utilisateurs RAM : Dans le volet de navigation de gauche, choisissez Identity Management > Users.

Vous pouvez également distinguer les types d'identité grâce au format de l'ARN : un ARN contenant :role/ identifie un rôle RAM (par exemple, acs:ram::123456789012:role/adminrole), tandis qu'un ARN contenant :user/ identifie un utilisateur RAM (par exemple, acs:ram::123456789012:user/user1).

Si vous ne trouvez pas l'identité recherchée dans la liste des rôles, cherchez dans la liste des utilisateurs, et inversement.

Concepts clés

Assimilez ces concepts avant de commencer à travailler avec les rôles RAM.

{
  "Statement": [
    {
      "Action": "sts:AssumeRole",
      "Effect": "Allow",
      "Principal": {
        "RAM": [
          "acs:ram::123456789012****:root"
        ]
      }
    }
  ],
  "Version": "1"
}

Session de rôle

Lorsqu'une entité endosse un rôle, elle initie une session de rôle. Les identifiants temporaires du STS sont liés à cette session, et toutes les actions effectuées avec ces identifiants sont attribuées à la session.

Une session de rôle comprend :

1. Nom de session (RoleSessionName) : Identifiant de session fourni par l'utilisateur, qui apparaît dans les journaux ActionTrail. Il vous permet de retracer les actions jusqu'à l'entité ayant endossé le rôle.

2. Durée de session : Cycle de vie fixe ; les identifiants expirent à la fin de la session.

Chaînage de rôles

Le chaînage de rôles se produit lorsqu'un rôle est utilisé pour en endosser un autre. Par exemple, un utilisateur RAM endosse le rôle A, puis utilise son jeton STS pour endosser le rôle B. Les rôles peuvent appartenir au même compte ou à des comptes différents.

Ce schéma est courant dans les environnements multi-comptes. Par exemple, un développeur se fédère dans un compte central de rebond (rôle A), puis endosse un rôle privilégié (rôle B) dans un compte de production pour effectuer une tâche spécifique.

Enchaînez les rôles à l'aide de la CLI Alibaba Cloud, des SDK ou de la console. Consultez la rubrique Utiliser le chaînage de rôles.

Différences entre les rôles RAM et les utilisateurs RAM

Les rôles et les utilisateurs sont tous deux des identités RAM, mais ils répondent à des objectifs différents.

Pour connaître les limites applicables aux rôles RAM, consultez la rubrique Limites.

Cas d'utilisation

• Octroi de privilèges élevés temporaires

  Un développeur disposant d'autorisations limitées au quotidien endosse un rôle doté de privilèges administratifs pour effectuer une opération sensible, telle que la modification d'une base de données de production. Une fois la tâche accomplie, les privilèges reviennent à l'ensemble limité, appliquant ainsi le principe du moindre privilège.

  Consultez la rubrique Méthodes pour endosser un rôle RAM.

• Délégation d'accès entre comptes

  Une organisation dispose de comptes Alibaba Cloud distincts pour le développement (compte A) et la production (compte B). Pour permettre à un pipeline CI/CD s'exécutant dans le compte A de déployer une application sur ECS dans le compte B, vous pouvez :

  1. Créer un rôle dans le compte B qui fait confiance au compte A.

  2. Accorder au rôle de service CI/CD du compte A l'autorisation d'endosser ce rôle dans le compte B.

  3. Le pipeline CI/CD endosse le rôle dans le compte B pour obtenir les identifiants nécessaires au déploiement de l'application.

  Consultez la rubrique Accès aux ressources intercomptes.

• Octroi d'accès aux services Alibaba Cloud

  Une application exécutée sur une instance ECS doit lire des données depuis un compartiment OSS. Au lieu d'intégrer une paire AccessKey, créez un rôle de service disposant d'autorisations de lecture et associez-le à l'instance. L'application utilise les identifiants temporaires fournis automatiquement pour accéder à OSS.

  Pour plus d'informations, consultez la rubrique Rôles RAM d'instance.

• Fourniture d'accès aux utilisateurs fédérés

  Votre entreprise utilise un IdP externe (tel que Microsoft Entra ID ou Okta). Configurez la fédération d'identités avec SAML 2.0 ou OIDC et créez un rôle RAM qui fait confiance à l'IdP. Les utilisateurs authentifiés endossent le rôle pour accéder à Alibaba Cloud, ce qui permet une gestion centralisée des utilisateurs sans créer d'utilisateurs RAM individuels.

  Consultez les rubriques Présentation de l'authentification unique basée sur les rôles avec SAML et Présentation de l'authentification unique basée sur les rôles avec OIDC.

Références

• Limites

• Rôles liés au service

• Présentation des politiques d'accès

• Présentation de l'authentification unique basée sur les rôles avec SAML

• Rôles RAM pour les instances ECS

• Accéder à Alibaba Cloud depuis une application mobile à l'aide d'un jeton STS