Utiliser des tags pour gérer les autorisations de groupe de mise à l'échelle - Auto Scaling

Auto Scaling vous permet de classer et de contrôler l'accès aux groupes de mise à l'échelle à l'aide de tags. Vous pouvez accorder des autorisations granulaires à des groupes de mise à l'échelle individuels ou à plusieurs groupes partageant un tag spécifique. Cette rubrique explique comment utiliser l'authentification basée sur les tags pour gérer les autorisations des utilisateurs RAM, ce qui améliore l'efficacité de la gestion et réduit le risque de fuites de données.

Contexte

Un tag est un identifiant pour une ressource cloud. Vous pouvez utiliser les tags pour classer, rechercher et regrouper les ressources cloud présentant les mêmes caractéristiques selon différentes dimensions. Pour plus d'informations, consultez Tags.
Resource Access Management (RAM) vous permet de gérer les identités des utilisateurs et de contrôler l'accès ainsi que les opérations sur vos ressources cloud en fonction de politiques. Pour plus d'informations, consultez Qu'est-ce que RAM ?.

En utilisant les tags comme conditions dans une politique Resource Access Management (RAM), vous pouvez mettre en œuvre un contrôle granulaire sur Auto Scaling.

La figure suivante illustre comment utiliser les tags pour gérer l'accès aux ressources et les autorisations d'opération des utilisateurs RAM, une méthode appelée authentification basée sur les tags.

API ne prenant pas en charge l'authentification par tag

Après avoir attaché une politique d'authentification basée sur les tags à un utilisateur RAM, l'authentification par tag n'est pas prise en charge lorsque l'utilisateur RAM appelle les opérations d'API suivantes pour gérer Auto Scaling.

API	Prise en charge de l'authentification par tag
DescribeRegions	Non
Pour les tâches planifiées non associées à un groupe de mise à l'échelle : CreateScheduledTask ModifyScheduledTask DescribeScheduledTasks DeleteScheduledTask	Non
Pour les tâches déclenchées par événement non associées à un groupe de mise à l'échelle : CreateAlarm DescribeAlarms ModifyAlarm EnableAlarm DeleteAlarm	Non

Scénario d'exemple

Cette rubrique utilise le scénario suivant pour montrer comment mettre en œuvre l'authentification basée sur les tags.

Supposons que vous ayez créé deux groupes de mise à l'échelle pour le développement de jeux. Chaque groupe de mise à l'échelle est tagué par environnement et équipe. Vous devez accorder à un utilisateur RAM des autorisations spécifiques sur les groupes de mise à l'échelle suivants :

Groupe de mise à l'échelle	Nom	Tag
Groupe de mise à l'échelle 1	asg-001	Tag 1 : environment:test, où la clé de tag est environment et la valeur de tag est test. Tag 2 : team:game1, où la clé de tag est team et la valeur de tag est game1.
Groupe de mise à l'échelle 2	asg-002	Tag 1 : environment:dev, où la clé de tag est environment et la valeur de tag est dev. Tag 2 : team:game2, où la clé de tag est team et la valeur de tag est game2.

Les exigences spécifiques de contrôle d'accès sont les suivantes :

Scénario 1 : Vous ne pouvez pas créer de groupes de mise à l'échelle sans tags. Le groupe de mise à l'échelle 1 ne peut être créé avec succès que si vous lui ajoutez les tags environment:test et team:game1 lors de sa création.
Scénario 2 : Lors de la requête des groupes de mise à l'échelle, vous ne pouvez consulter que les ressources du groupe de mise à l'échelle 1, auquel sont liés les tags environment:test et team:game1.
Scénario 3 : Vous êtes autorisé à gérer uniquement les ressources du groupe de mise à l'échelle 1 (avec les tags environment:test et team:game1), mais pas les ressources du groupe de mise à l'échelle 2 (avec les tags environment:dev et team:game2).

Procédure

Remarque

Avant de commencer, assurez-vous d'avoir créé un utilisateur RAM. Pour plus d'informations, consultez Créer un utilisateur RAM.

Créez deux groupes de mise à l'échelle.

Pour plus d'informations, consultez Configurer les groupes de mise à l'échelle. Consultez la section Scénario d'exemple pour obtenir des détails sur les groupes de mise à l'échelle.
Connectez-vous à la console RAM.

Créez une politique personnalisée.

Pour plus d'informations, consultez Créer une politique personnalisée.

Vous pouvez définir plusieurs conditions de tag pour les ressources cloud dans le bloc Condition d'une politique afin de restreindre les autorisations d'exécution des opérations sur les ressources Auto Scaling. Conditions d'authentification basées sur les tags prises en charge :

Condition basée sur les tags

Description

acs:RequestTag

Vérifie si la requête inclut un tag spécifique.

Si une requête API n'inclut aucun paramètre de tag, l'utilisation de acs:RequestTag entraînera un échec de l'authentification.

acs:ResourceTag

Vérifie si la ressource spécifiée dans la requête contient un tag spécifique.

Si vous utilisez acs:ResourceTag dans une requête API qui ne contient pas de paramètre d'ID de ressource, l'authentification échouera.

Le bloc de code suivant montre un exemple de politique complet :

{
    "Version": "1",
    "Statement": [
         {
           "Effect": "Allow",
           "Action": "ess:Create*",
           "Resource": "*",
           "Condition": {
                   "StringEquals": {
                        "acs:RequestTag/environment": "test",
                        "acs:RequestTag/team": "game1"
                   }
              }
         },
         {
            "Effect": "Allow",
            "Action": "ess:Describe*",
            "Resource": "*",
            "Condition": {
                    "StringEquals": {
                    "acs:RequestTag/environment": "test",
                    "acs:RequestTag/team": "game1"
                    }
              }
         },
         {
            "Action": "ess:*",
            "Effect": "Allow",
            "Resource": "*",
            "Condition": {
                "StringEquals": {
                    "acs:ResourceTag/environment": "test",
                    "acs:ResourceTag/team": "game1"
                  }
              }
         },
         {
            "Effect": "Allow",
            "Action": [
                   "ess:Describe*",
                   "ess:List*",
                   "ess:DescribeRegions",
                   "ess:CreateScheduledTask",
                   "ess:ModifyScheduledTask",
                   "ess:DescribeScheduledTasks",
                   "ess:DeleteScheduledTask",
                   "ess:CreateAlarm",
                   "ess:DescribeAlarms",
                   "ess:ModifyAlarm",
                   "ess:EnableAlarm",
                   "ess:DeleteAlarm"
                ],
    "Resource": "*"
      }
   ]
}

Scénario 1 : Imposer des tags spécifiques lors de la création du groupe de mise à l'échelle

Autrement dit, le groupe de mise à l'échelle 1 ne peut être créé avec succès que si les tags environment:test et team:game1 lui sont liés lors de la création.

La politique suivante correspond à ce scénario :
```
{
    "Effect": "Allow",
    "Action": "ess:Create*",
    "Resource": "*",
    "Condition": {
        "StringEquals": {
            "acs:RequestTag/environment": "test",
            "acs:RequestTag/team": "game1"
        }
    }
}
```
Scénario 2 : Autoriser les utilisateurs à afficher uniquement le groupe de mise à l'échelle 1

Cela signifie que si vous attachez les tags environment:test et team:game1 au groupe de mise à l'échelle 1, seules les ressources du groupe de mise à l'échelle 1 sont renvoyées lorsque vous interrogez les groupes de mise à l'échelle.

La politique suivante correspond à ce scénario :
```
{
    "Effect": "Allow",
    "Action": "ess:Describe*",
    "Resource": "*",
    "Condition": {
        "StringEquals": {
            "acs:RequestTag/environment": "test",
            "acs:RequestTag/team": "game1"
        }
    }
}
```

Scénario 3 : Autoriser les utilisateurs à gérer uniquement le groupe de mise à l'échelle 1 et refuser l'accès au groupe de mise à l'échelle 2

Par exemple, le groupe de mise à l'échelle 1 est lié aux tags environment:test et team:game1, tandis que le groupe de mise à l'échelle 2 est lié aux tags environment:dev et team:game2.

La politique suivante correspond à ce scénario :

{
    "Version": "1",
    "Statement": [
        {
            "Action": "ess:*",
            "Effect": "Allow",
            "Resource": "*",
            "Condition": {
                "StringEquals": {
                    "acs:ResourceTag/environment": "test",
                    "acs:ResourceTag/team": "game1"
                }
            }
        },
        {
            "Action": "ess:*",
            "Effect": "Deny",
            "Resource": "*",
            "Condition": {
                "StringEquals": {
                    "acs:ResourceTag/environment": "dev",
                    "acs:ResourceTag/team": "game2"
                }
            }
        },      
        {
           "Effect": "Allow",
           "Action": [
                   "ess:DescribeRegions",
                   "ess:CreateScheduledTask",
                   "ess:ModifyScheduledTask",
                   "ess:DescribeScheduledTasks",
                   "ess:DeleteScheduledTask",
                   "ess:CreateAlarm",
                   "ess:DescribeAlarms",
                   "ess:ModifyAlarm",
                   "ess:EnableAlarm",
                   "ess:DeleteAlarm"
                ],
    "Resource": "*"
      }
   ]
}

Attachez la politique personnalisée à l'utilisateur RAM.

Pour plus d'informations, consultez Accorder des autorisations à un utilisateur RAM.
Vérifiez que la politique prend effet.
- Vérifier le scénario 1 en créant le groupe de mise à l'échelle 1
  - Le groupe de mise à l'échelle 1 possède les tags environment:test et team:game1, il peut donc être créé avec succès.
  - Si vous créez le groupe de mise à l'échelle sans les tags spécifiés, la création est refusée en raison d'autorisations insuffisantes. Une erreur différente se produit si Auto Scaling ne dispose pas des autorisations OpenAPI nécessaires : l'erreur Forbidden.Unauthorized est renvoyée avec le message : The user has not fully authorized the OpenAPI interface for ESS. Please authorize and try again. Dans ce cas, accordez les autorisations requises et réessayez l'opération.
- Vérifier le scénario 2 en interrogeant les groupes de mise à l'échelle
  - Pour un groupe de mise à l'échelle possédant les tags environment:test et team:game1, vous pouvez toujours récupérer ses informations en effectuant une requête sans filtrer par tags.
  - Si vous interrogez un groupe de mise à l'échelle autre que le groupe de mise à l'échelle 1 qui n'est pas tagué avec environment:test et team:game1, la requête ne renvoie aucun résultat.
  - Si vous ne spécifiez pas de groupe de mise à l'échelle et recherchez uniquement les tags environment:test et team:game1, la requête renvoie tous les groupes de mise à l'échelle possédant ces tags.
- Vérifier le scénario 3 en supprimant des groupes de mise à l'échelle
  - Si le groupe de mise à l'échelle 1 possède les tags environment:test et team:game1, vous pouvez supprimer le groupe de mise à l'échelle.
  - Si un groupe de mise à l'échelle n'est pas associé aux tags environment:test et team:game1, ou s'il possède d'autres tags, un message s'affiche indiquant que vous ne disposez pas de l'autorisation de supprimer le groupe de mise à l'échelle.

Documents connexes

Pour créer, afficher ou supprimer un groupe de mise à l'échelle en appelant une opération d'API, consultez CreateScalingGroup, DescribeScalingGroups ou DeleteScalingGroup.
Pour créer une politique personnalisée en appelant une opération d'API, consultez CreatePolicy.
Pour accorder des autorisations à un utilisateur RAM en appelant une opération d'API, consultez AttachPolicyToUser.
Si vous disposez de plusieurs groupes de mise à l'échelle, vous pouvez utiliser un groupe de ressources pour les gérer. Pour plus d'informations, consultez Utiliser des groupes de ressources pour gérer les groupes de mise à l'échelle.
Si vous souhaitez utiliser l'authentification au niveau des ressources pour l'administration déléguée d'Auto Scaling, consultez Gérer Auto Scaling à l'aide de l'authentification au niveau des ressources.