Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
Exemples de politiques basées sur l'identité Amazon EC2 Auto Scaling
Par défaut, un nouvel utilisateur n' Compte AWS est pas autorisé à faire quoi que ce soit. Un administrateur IAM doit créer et attribuer des politiques IAM qui donnent à une identité IAM (telle qu'un utilisateur ou un rôle) l'autorisation d'effectuer des actions sur l'API Amazon EC2 Auto Scaling.
Pour savoir comment créer une stratégie IAM à partir de ces exemples de documents de stratégie JSON, consultez Création de stratégies dans l'onglet JSON dans le Guide de l'utilisateur IAM.
Un exemple de politique d’autorisation est exposé ci-dessous.
{ "Version": "2012-10-17", "Statement": [{ "Effect": "Allow", "Action": [ "autoscaling:CreateAutoScalingGroup", "autoscaling:UpdateAutoScalingGroup", "autoscaling:DeleteAutoScalingGroup" ], "Resource": "*", "Condition": { "StringEquals": { "autoscaling:ResourceTag/
purpose
": "testing
" } } }, { "Effect": "Allow", "Action": "autoscaling:Describe*", "Resource": "*" }] }
Cet exemple de politique accorde les autorisations de créer, mettre à jour et supprimer des groupes Auto Scaling, mais uniquement si le groupe utilise la balise
. Comme les actions purpose=testing
Describe
ne prennent pas en charge les autorisations au niveau des ressources, vous devez les spécifier dans une instruction distincte sans condition. Pour lancer des instances avec un modèle de lancement, l’utilisateur doit également disposer de l’autorisation ec2:RunInstances
. Pour de plus amples informations, veuillez consulter Contrôlez l'utilisation des modèles de EC2 lancement Amazon dans les groupes Auto Scaling.
Note
Vous pouvez créer vos propres politiques IAM personnalisées pour autoriser ou refuser les autorisations aux identités IAM (utilisateurs ou rôles) pour effectuer des actions Amazon EC2 Auto Scaling. Vous pouvez attacher ces politiques personnalisées aux identités IAM qui nécessitent les autorisations spécifiées. Les exemples suivants présentent des autorisations pour quelques cas d’utilisation courants.
Certaines actions de l'API Amazon EC2 Auto Scaling vous permettent d'inclure dans votre politique des groupes Auto Scaling spécifiques qui peuvent être créés ou modifiés par l'action. Vous pouvez limiter les ressources cibles pour ces actions en spécifiant un groupe Auto Scaling individuel ARNs. Toutefois, nous vous recommandons d'utiliser des politiques basées sur des balises qui autorisent (ou refusent) les actions sur les groupes Auto Scaling avec une balise spécifique.
Exemples
- Contrôler la taille des groupes Auto Scaling qui peuvent être créés
- Contrôler les clés de balise et les valeurs de balise pouvant être utilisées
- Contrôler les groupes Auto Scaling pouvant être supprimés
- Contrôler les politiques de mise à l’échelle pouvant être supprimées
- Contrôler l’accès aux actions d’actualisation des instances
- Créer un rôle lié à un service
- Contrôler quel rôle lié à un service peut être transmis (en utilisant) PassRole
Contrôler la taille des groupes Auto Scaling qui peuvent être créés
La politique suivante accorde les autorisations de créer et de mettre à jour tous les groupes Auto Scaling avec la balise
, à condition que le demandeur ne spécifie pas une taille minimale inférieure à environment=development
1
ou une taille maximale supérieure à 10
. Dans la mesure du possible, utilisez des balises pour contrôler l’accès aux groupes Auto Scaling de votre compte.
{ "Version": "2012-10-17", "Statement": [{ "Effect": "Allow", "Action": [ "autoscaling:CreateAutoScalingGroup", "autoscaling:UpdateAutoScalingGroup" ], "Resource": "*", "Condition": { "StringEquals": { "autoscaling:ResourceTag/
environment
": "development
" }, "NumericGreaterThanEqualsIfExists": { "autoscaling:MinSize":1
}, "NumericLessThanEqualsIfExists": { "autoscaling:MaxSize":10
} } }] }
Sinon, si vous n'utilisez pas de balises pour contrôler l'accès aux groupes Auto Scaling, vous pouvez les utiliser ARNs pour identifier les groupes Auto Scaling auxquels s'applique la politique IAM.
Un groupe Auto Scaling comprend l'ARN suivant.
"Resource": "arn:aws:autoscaling:
region
:account-id
:autoScalingGroup:*:autoScalingGroupName/my-asg
"
Vous pouvez également en spécifier plusieurs ARNs en les incluant dans une liste. Pour plus d'informations sur la spécification ARNs des ressources Amazon EC2 Auto Scaling dans l'Resource
élément, consultezRessources relatives aux politiques pour Amazon EC2 Auto Scaling.
Contrôler les clés de balise et les valeurs de balise pouvant être utilisées
Vous pouvez également utiliser des conditions dans vos politiques IAM pour contrôler les clés de balise et les valeurs de balise qui peuvent être appliquées aux groupes Auto Scaling. Pour accorder les autorisations de créer ou baliser un groupe Auto Scaling uniquement si le demandeur spécifie des balises spécifiques, utilisez la clé de condition aws:RequestTag
. Pour autoriser uniquement des clés de balise spécifiques, utilisez la clé de condition aws:TagKeys
avec le modificateur ForAllValues
.
La politique suivante exige que le demandeur spécifie une balise avec la clé
dans la demande. La valeur environment
impose qu'une valeur existe pour la clé de balise. Pour utiliser un caractère générique, vous devez utiliser l'opérateur de condition "?*"
StringLike
.
{ "Version": "2012-10-17", "Statement": [{ "Effect": "Allow", "Action": [ "autoscaling:CreateAutoScalingGroup", "autoscaling:CreateOrUpdateTags" ], "Resource": "*", "Condition": { "StringLike": { "aws:RequestTag/
environment
": "?*
" } } }] }
La politique suivante spécifie que le demandeur peut uniquement marquer les groupes Auto Scaling avec les balises
et purpose=webserver
, et autorise uniquement les balises cost-center=cc123
et purpose
(aucune autre balise ne peut être spécifiée).cost-center
{ "Version": "2012-10-17", "Statement": [{ "Effect": "Allow", "Action": [ "autoscaling:CreateAutoScalingGroup", "autoscaling:CreateOrUpdateTags" ], "Resource": "*", "Condition": { "StringEquals": { "aws:RequestTag/
purpose
": "webserver
", "aws:RequestTag/cost-center
": "cc123
" }, "ForAllValues:StringEquals": { "aws:TagKeys": ["purpose
", "cost-center
"] } } }] }
La politique suivante exige que le demandeur spécifie au moins une balise dans la demande, et autorise uniquement les clés
et cost-center
.owner
{ "Version": "2012-10-17", "Statement": [{ "Effect": "Allow", "Action": [ "autoscaling:CreateAutoScalingGroup", "autoscaling:CreateOrUpdateTags" ], "Resource": "*", "Condition": { "ForAnyValue:StringEquals": { "aws:TagKeys": ["
cost-center
", "owner
"] } } }] }
Note
Pour les conditions, la clé de condition n’est pas sensible à la casse et la valeur de la condition est sensible à la casse. Par conséquent pour forcer la sensibilité à la casse d’une clé de balise, utilisez la clé de condition aws:TagKeys
, où la clé de balise est indiquée comme une valeur dans la condition.
Contrôler les groupes Auto Scaling pouvant être supprimés
La politique suivante autorise la suppression d’un groupe Auto Scaling uniquement si le groupe comporte la balise
.environment=development
{ "Version": "2012-10-17", "Statement": [{ "Effect": "Allow", "Action": "autoscaling:DeleteAutoScalingGroup", "Resource": "*", "Condition": { "StringEquals": { "aws:ResourceTag/
environment
": "development
" } } }] }
Sinon, si vous n'utilisez pas de clés de condition pour contrôler l'accès aux groupes Auto Scaling, vous pouvez spécifier les ressources ARNs de l'Resource
élément pour contrôler l'accès à la place.
La politique suivante autorise les utilisateurs à utiliser l’action API DeleteAutoScalingGroup
, mais uniquement pour les groupes Auto Scaling dont le nom commence par
.devteam-
{ "Version": "2012-10-17", "Statement": [{ "Effect": "Allow", "Action": "autoscaling:DeleteAutoScalingGroup", "Resource": "arn:aws:autoscaling:
region
:account-id
:autoScalingGroup:*:autoScalingGroupName/devteam-
*" }] }
Vous pouvez également en spécifier plusieurs ARNs en les incluant dans une liste. L'inclusion de l'UUID permet de s'assurer que l'accès est accordé au groupe Auto Scaling spécifique. L'UUID d'un nouveau groupe est différent de celui d'un groupe supprimé avec le même nom.
"Resource": [ "arn:aws:autoscaling:
region
:account-id
:autoScalingGroup:uuid
:autoScalingGroupName/devteam-1
", "arn:aws:autoscaling:region
:account-id
:autoScalingGroup:uuid
:autoScalingGroupName/devteam-2
", "arn:aws:autoscaling:region
:account-id
:autoScalingGroup:uuid
:autoScalingGroupName/devteam-3
" ]
Contrôler les politiques de mise à l’échelle pouvant être supprimées
La politique suivante accorde les autorisations d'utiliser l'action DeletePolicy
pour supprimer une politique de mise à l'échelle. Cependant, elle refuse également l'action si le groupe Auto Scaling cible dispose de la balise
. Dans la mesure du possible, utilisez des balises pour contrôler l’accès aux groupes Auto Scaling de votre compte.environment=production
{ "Version": "2012-10-17", "Statement": [{ "Effect": "Allow", "Action": "autoscaling:DeletePolicy", "Resource": "*" }, { "Effect": "Deny", "Action": "autoscaling:DeletePolicy", "Resource": "*", "Condition": { "StringEquals": { "autoscaling:ResourceTag/
environment
": "production
" } } }] }
Contrôler l’accès aux actions d’actualisation des instances
La politique suivante autorise le démarrage, la restauration et l’annulation d’une actualisation d’instance uniquement si le groupe Auto Scaling concerné comporte la balise
. Comme les actions environment=testing
Describe
ne prennent pas en charge les autorisations au niveau des ressources, vous devez les spécifier dans une instruction distincte sans condition.
{ "Version": "2012-10-17", "Statement": [{ "Effect": "Allow", "Action": [ "autoscaling:StartInstanceRefresh", "autoscaling:CancelInstanceRefresh", "autoscaling:RollbackInstanceRefresh" ], "Resource": "*", "Condition": { "StringEquals": { "autoscaling:ResourceTag/
environment
": "testing
" } } }, { "Effect": "Allow", "Action": "autoscaling:DescribeInstanceRefreshes", "Resource": "*" }] }
Pour spécifier la configuration souhaitée dans l’appel StartInstanceRefresh
, les utilisateurs peuvent avoir besoin de certaines autorisations associées, telles que :
-
ec2 : RunInstances — Pour lancer des EC2 instances à l'aide d'un modèle de lancement, l'utilisateur doit avoir l'
ec2:RunInstances
autorisation requise dans une politique IAM. Pour de plus amples informations, veuillez consulter Contrôlez l'utilisation des modèles de EC2 lancement Amazon dans les groupes Auto Scaling. -
ec2 : CreateTags — Pour lancer des EC2 instances à partir d'un modèle de lancement qui ajoute des balises aux instances et aux volumes lors de leur création, l'utilisateur doit disposer de l'
ec2:CreateTags
autorisation prévue dans une politique IAM. Pour de plus amples informations, veuillez consulter Autorisations requises pour baliser des instances et des volumes. -
iam : PassRole — Pour lancer des EC2 instances à partir d'un modèle de lancement contenant un profil d'instance (un conteneur pour un rôle IAM), l'utilisateur doit également disposer de l'
iam:PassRole
autorisation prévue dans une politique IAM. Pour plus d’informations, et un exemple de politique IAM, consultez Rôle IAM pour les applications qui s'exécutent sur des instances Amazon EC2. -
ssm : GetParameters — Pour lancer des EC2 instances à partir d'un modèle de lancement utilisant un AWS Systems Manager paramètre, l'utilisateur doit également disposer de l'
ssm:GetParameters
autorisation dans une politique IAM. Pour de plus amples informations, veuillez consulter Utiliser des AWS Systems Manager paramètres au lieu de l'AMI IDs dans les modèles de lancement.
Créer un rôle lié à un service
Amazon EC2 Auto Scaling a besoin d'autorisations pour créer un rôle lié à un service la première fois qu'un de vos utilisateurs appelle des actions d'API Compte AWS Amazon EC2 Auto Scaling. Si le rôle lié au service n'existe pas déjà, Amazon EC2 Auto Scaling le crée dans votre compte. Le rôle lié à un service donne des autorisations à Amazon EC2 Auto Scaling afin qu'il puisse appeler d'autres personnes en votre Services AWS nom.
Pour que cette création de rôle automatique aboutisse, les utilisateurs doivent disposer des autorisations nécessaires pour l'action iam:CreateServiceLinkedRole
.
"Action": "iam:CreateServiceLinkedRole"
Voici un exemple de politique d'autorisation qui permet à un utilisateur de créer un rôle lié au service Amazon EC2 Auto Scaling pour Amazon EC2 Auto Scaling.
{ "Version": "2012-10-17", "Statement": [{ "Effect": "Allow", "Action": "iam:CreateServiceLinkedRole", "Resource": "arn:aws:iam::*:role/aws-service-role/autoscaling.amazonaws.com/
AWSServiceRoleForAutoScaling
", "Condition": { "StringLike": { "iam:AWSServiceName":"autoscaling.amazonaws.com
" } } }] }
Contrôler quel rôle lié à un service peut être transmis (en utilisant) PassRole
Les utilisateurs qui créent ou mettent à jour des groupes Auto Scaling et qui spécifient un rôle lié à un service avec suffixe personnalisé dans la demande ont besoin de l'autorisation iam:PassRole
.
Vous pouvez utiliser cette iam:PassRole
autorisation pour protéger la sécurité des clés gérées par vos AWS KMS clients si vous autorisez différents rôles liés au service à accéder à différentes clés. En fonction des besoins de votre organisation, vous pouvez avoir une clé pour l'équipe de développement, une autre pour l'équipe assurance qualité et encore une autre pour l'équipe financière. Tout d'abord, créez un rôle lié à un service qui a accès à la clé requise, par exemple, un rôle lié à un service nommé AWSServiceRoleForAutoScaling_devteamkeyaccess. Attachez ensuite la politique à une identité IAM, telle qu'un utilisateur ou un rôle.
La politique suivante accorde les autorisations de transmettre le rôle AWSServiceRoleForAutoScaling_devteamkeyaccess
à un groupe Auto Scaling dont le nom commence par
. Si l'identité IAM qui crée le groupe Auto Scaling essaie de spécifier un rôle lié à un service différent, elle reçoit une erreur. S'ils choisissent de ne pas spécifier un rôle lié à un service, le rôle AWSServiceRoleForAutoScaling par défaut est utilisé à la place.devteam-
{ "Version": "2012-10-17", "Statement": [{ "Effect": "Allow", "Action": "iam:PassRole", "Resource": "arn:aws:iam::
account-id
:role/aws-service-role/autoscaling.amazonaws.com/AWSServiceRoleForAutoScaling_devteamkeyaccess
", "Condition": { "StringEquals": { "iam:PassedToService": [ "autoscaling.amazonaws.com" ] }, "StringLike": { "iam:AssociatedResourceARN": [ "arn:aws:autoscaling:region
:account-id
:autoScalingGroup:*:autoScalingGroupName/devteam-
*" ] } } }] }
Pour plus d'informations sur les rôles liés à un service avec suffixe personnalisé, consultez Rôles liés à un service pour Amazon Auto Scaling EC2 .