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 stratégies basées sur des autorisations de ressource
Cette section décrit un cas d'utilisation pour contrôler les autorisations utilisateur pour les actions Elastic Beanstalk qui accèdent à des ressources Elastic Beanstalk spécifiques. Nous suivrons les exemples de stratégies qui prennent en charge le cas d'utilisation. Pour de plus amples informations sur les stratégies des ressources Elastic Beanstalk, veuillez consulter Création d'une stratégie utilisateur personnalisée. Pour plus d'informations sur l'attachement de stratégies à des utilisateurs et des groupes, consultez Gestion des stratégies IAM dans Utilisation d'AWS Identity and Access Management.
Dans notre cas d'utilisation, Example Corp. est une petite agence de conseils développant des applications pour les deux clients différents. John est le gestionnaire de développement chargé du développement des deux applications Elastic Beanstalk : app1 et app2. John fait du développement et quelques tests sur les deux applications, et lui seul peut mettre à jour l'environnement de production pour les deux applications. Voici les autorisations dont il a besoin pour app1 et app2 :
-
Afficher des applications, des versions d'applications, des environnements et des modèles de configuration
-
Créer des versions d'applications et les déployer dans l'environnement intermédiaire
-
Mettre à jour l'environnement de production
-
Créer et résilier des environnements
Jill est testeur qui a besoin d'un accès pour afficher les ressources suivantes afin de surveiller et de tester les deux applications : applications, versions d'applications, environnements et modèles de configuration. Cependant, elle ne devrait pas être en mesure d'apporter des modifications aux ressources Elastic Beanstalk.
Jack est le développeur pour app1 qui a besoin d'un accès pour afficher toutes les ressources pour app1 ainsi que de créer des versions d'applications pour app1 et de les déployer dans l'environnement intermédiaire.
Judy est l'administratrice du compte AWS pour Example Corp. Elle a créé des utilisateurs IAM pour John, Jill et Jack, et elle attache les stratégies suivantes à ces utilisateurs pour accorder les autorisations appropriées pour les applications app1 et app2.
Exemple 1 : John – gestionnaire de développement pour app1, app2
Nous avons divisé la stratégie de John en trois stratégies distinctes afin qu'elles soient plus faciles à lire et à gérer. Ensemble, elles donnent à John les autorisations dont il a besoin pour effectuer des actions de développement, de test et de déploiement sur les deux applications.
La première stratégie spécifie les actions pour Auto Scaling, Amazon S3, Amazon EC2, CloudWatch, Amazon SNS, Elastic Load Balancing, Amazon RDS et AWS CloudFormation. Elastic Beanstalk s'appuie sur ces services supplémentaires pour fournir des ressources sous-jacentes lors de la création d'un environnement.
Notez que cette stratégie est un exemple. Elle offre un large ensemble d'autorisations aux produits AWS qu'Elastic Beanstalk utilise pour gérer des applications et des environnements. Par exemple, ec2:* permet à un utilisateur IAM d'effectuer n'importe quelle action sur n'importe quelle ressource Amazon EC2 du compte AWS. Ces autorisations ne sont pas limitées aux ressources que vous utilisez avec Elastic Beanstalk. La bonne pratique consiste à accorder aux personnes autorisées uniquement les autorisations dont elles ont besoin pour réaliser leur travail.
{
"Version": "2012-10-17",
"Statement":[
{
"Effect":"Allow",
"Action":[
"ec2:*",
"ecs:*",
"ecr:*",
"elasticloadbalancing:*",
"autoscaling:*",
"cloudwatch:*",
"s3:*",
"sns:*",
"cloudformation:*",
"dynamodb:*",
"rds:*",
"sqs:*",
"logs:*",
"iam:GetPolicyVersion",
"iam:GetRole",
"iam:PassRole",
"iam:ListRolePolicies",
"iam:ListAttachedRolePolicies",
"iam:ListInstanceProfiles",
"iam:ListRoles",
"iam:ListServerCertificates",
"acm:DescribeCertificate",
"acm:ListCertificates",
"codebuild:CreateProject",
"codebuild:DeleteProject",
"codebuild:BatchGetBuilds",
"codebuild:StartBuild"
],
"Resource":"*"
}
]
}La deuxième stratégie spécifie les actions Elastic Beanstalk que John est autorisé à effectuer sur les ressources app1 et app2. La déclaration AllCallsInApplications autorise toutes les actions Elastic Beanstalk ("elasticbeanstalk:*") effectuées sur toutes les ressources au sein d'app1 et d'app2 (par exemple, elasticbeanstalk:CreateEnvironment). La déclaration AllCallsOnApplications autorise toutes les actions Elastic Beanstalk ("elasticbeanstalk:*") sur les ressources d'application app1 et app2 (par exemple, elasticbeanstalk:DescribeApplications, elasticbeanstalk:UpdateApplication, etc..). La déclaration AllCallsOnSolutionStacks autorise toutes les actions Elastic Beanstalk ("elasticbeanstalk:*") pour les ressources d'une pile de solutions (par exemple, elasticbeanstalk:ListAvailableSolutionStacks).
{
"Version": "2012-10-17",
"Statement":[
{
"Sid":"AllCallsInApplications",
"Action":[
"elasticbeanstalk:*"
],
"Effect":"Allow",
"Resource":[
"*"
],
"Condition":{
"StringEquals":{
"elasticbeanstalk:InApplication":[
"arn:aws:elasticbeanstalk:us-east-2:123456789012:application/app1",
"arn:aws:elasticbeanstalk:us-east-2:123456789012:application/app2"
]
}
}
},
{
"Sid":"AllCallsOnApplications",
"Action":[
"elasticbeanstalk:*"
],
"Effect":"Allow",
"Resource":[
"arn:aws:elasticbeanstalk:us-east-2:123456789012:application/app1",
"arn:aws:elasticbeanstalk:us-east-2:123456789012:application/app2"
]
},
{
"Sid":"AllCallsOnSolutionStacks",
"Action":[
"elasticbeanstalk:*"
],
"Effect":"Allow",
"Resource":[
"arn:aws:elasticbeanstalk:us-east-2::solutionstack/*"
]
}
]
}La troisième stratégie spécifie les actions Elastic Beanstalk pour lesquelles la deuxième stratégie a besoin d'autorisations afin de réaliser ces actions Elastic Beanstalk. L'instruction AllNonResourceCalls autorise l'action elasticbeanstalk:CheckDNSAvailability, qui est obligatoire pour appeler elasticbeanstalk:CreateEnvironment et d'autres actions. Elle autorise également l'action elasticbeanstalk:CreateStorageLocation, qui est obligatoire pour elasticbeanstalk:CreateApplication, elasticbeanstalk:CreateEnvironment et d'autres actions.
{
"Version": "2012-10-17",
"Statement":[
{
"Sid":"AllNonResourceCalls",
"Action":[
"elasticbeanstalk:CheckDNSAvailability",
"elasticbeanstalk:CreateStorageLocation"
],
"Effect":"Allow",
"Resource":[
"*"
]
}
]
}Exemple 2 : Jill – testeur pour app1, app2
Nous avons divisé la stratégie de Jill en trois stratégies distinctes afin qu'elles soient plus faciles à lire et à gérer. Ensemble, elles donnent à Jill les autorisations dont elle a besoin pour effectuer les actions de tests et de suivi sur les deux applications.
La première stratégie spécifie les actions Describe*, List* et Get* sur Auto Scaling, Amazon S3, Amazon EC2, CloudWatch, Amazon SNS, Elastic Load Balancing, Amazon RDS et AWS CloudFormation (pour les types de conteneur non hérités) afin que les actions Elastic Beanstalk soient en mesure de récupérer les informations pertinentes sur les ressources sous-jacentes des applications app1 et app2.
{
"Version": "2012-10-17",
"Statement":[
{
"Effect":"Allow",
"Action":[
"ec2:Describe*",
"elasticloadbalancing:Describe*",
"autoscaling:Describe*",
"cloudwatch:Describe*",
"cloudwatch:List*",
"cloudwatch:Get*",
"s3:Get*",
"s3:List*",
"sns:Get*",
"sns:List*",
"rds:Describe*",
"cloudformation:Describe*",
"cloudformation:Get*",
"cloudformation:List*",
"cloudformation:Validate*",
"cloudformation:Estimate*"
],
"Resource":"*"
}
]
}La deuxième stratégie spécifie les actions Elastic Beanstalk que Jill est autorisée à effectuer sur les ressources app1 et app2. L'instruction AllReadCallsInApplications lui permet d'appeler les actions Describe* et les actions d'informations d'environnement. L'instruction AllReadCallsOnApplications lui permet d'appeler les actions DescribeApplications et DescribeEvents sur les ressources d'application app1 et app2. L'instruction AllReadCallsOnSolutionStacks permet l'affichage d'actions qui impliquent des ressources d'une pile de solutions (ListAvailableSolutionStacks, DescribeConfigurationOptions et ValidateConfigurationSettings).
{
"Version": "2012-10-17",
"Statement":[
{
"Sid":"AllReadCallsInApplications",
"Action":[
"elasticbeanstalk:Describe*",
"elasticbeanstalk:RequestEnvironmentInfo",
"elasticbeanstalk:RetrieveEnvironmentInfo"
],
"Effect":"Allow",
"Resource":[
"*"
],
"Condition":{
"StringEquals":{
"elasticbeanstalk:InApplication":[
"arn:aws:elasticbeanstalk:us-east-2:123456789012:application/app1",
"arn:aws:elasticbeanstalk:us-east-2:123456789012:application/app2"
]
}
}
},
{
"Sid":"AllReadCallsOnApplications",
"Action":[
"elasticbeanstalk:DescribeApplications",
"elasticbeanstalk:DescribeEvents"
],
"Effect":"Allow",
"Resource":[
"arn:aws:elasticbeanstalk:us-east-2:123456789012:application/app1",
"arn:aws:elasticbeanstalk:us-east-2:123456789012:application/app2"
]
},
{
"Sid":"AllReadCallsOnSolutionStacks",
"Action":[
"elasticbeanstalk:ListAvailableSolutionStacks",
"elasticbeanstalk:DescribeConfigurationOptions",
"elasticbeanstalk:ValidateConfigurationSettings"
],
"Effect":"Allow",
"Resource":[
"arn:aws:elasticbeanstalk:us-east-2::solutionstack/*"
]
}
]
}La troisième stratégie spécifie les actions Elastic Beanstalk pour lesquelles la deuxième stratégie a besoin d'autorisations afin de réaliser ces actions Elastic Beanstalk. L'instruction AllNonResourceCalls permet l'action elasticbeanstalk:CheckDNSAvailability, qui est obligatoire pour certaines actions d'affichage.
{
"Version": "2012-10-17",
"Statement":[
{
"Sid":"AllNonResourceCalls",
"Action":[
"elasticbeanstalk:CheckDNSAvailability"
],
"Effect":"Allow",
"Resource":[
"*"
]
}
]
}Exemple 3 : Jack – développeur pour app1
Nous avons divisé la stratégie de Jack en trois stratégies distinctes afin qu'elles soient plus faciles à lire et à gérer. Ensemble, elles donnent à Jack les autorisations dont il a besoin pour effectuer des tests, des contrôles et des actions de déploiement sur la ressource app1.
La première stratégie spécifie les actions sur Auto Scaling, Amazon S3, Amazon EC2, CloudWatch, Amazon SNS, Elastic Load Balancing, Amazon RDS et AWS CloudFormation (pour les types de conteneur non hérités) afin que les actions Elastic Beanstalk soient en mesure d'afficher et d'utiliser les ressources sous-jacentes de l'application app1. Pour afficher la liste des types de conteneurs non hérités pris en charge, consultez Pourquoi certaines versions de plate-forme sont-elles marquées héritées ?
Notez que cette stratégie est un exemple. Elle offre un large ensemble d'autorisations aux produits AWS qu'Elastic Beanstalk utilise pour gérer des applications et des environnements. Par exemple, ec2:* permet à un utilisateur IAM d'effectuer n'importe quelle action sur n'importe quelle ressource Amazon EC2 du compte AWS. Ces autorisations ne sont pas limitées aux ressources que vous utilisez avec Elastic Beanstalk. La bonne pratique consiste à accorder aux personnes autorisées uniquement les autorisations dont elles ont besoin pour réaliser leur travail.
{
"Version": "2012-10-17",
"Statement":[
{
"Effect":"Allow",
"Action":[
"ec2:*",
"elasticloadbalancing:*",
"autoscaling:*",
"cloudwatch:*",
"s3:*",
"sns:*",
"rds:*",
"cloudformation:*"
],
"Resource":"*"
}
]
}La deuxième stratégie spécifie les actions Elastic Beanstalk que Jack est autorisé à effectuer sur la ressource app1.
{
"Version": "2012-10-17",
"Statement":[
{
"Sid":"AllReadCallsAndAllVersionCallsInApplications",
"Action":[
"elasticbeanstalk:Describe*",
"elasticbeanstalk:RequestEnvironmentInfo",
"elasticbeanstalk:RetrieveEnvironmentInfo",
"elasticbeanstalk:CreateApplicationVersion",
"elasticbeanstalk:DeleteApplicationVersion",
"elasticbeanstalk:UpdateApplicationVersion"
],
"Effect":"Allow",
"Resource":[
"*"
],
"Condition":{
"StringEquals":{
"elasticbeanstalk:InApplication":[
"arn:aws:elasticbeanstalk:us-east-2:123456789012:application/app1"
]
}
}
},
{
"Sid":"AllReadCallsOnApplications",
"Action":[
"elasticbeanstalk:DescribeApplications",
"elasticbeanstalk:DescribeEvents"
],
"Effect":"Allow",
"Resource":[
"arn:aws:elasticbeanstalk:us-east-2:123456789012:application/app1"
]
},
{
"Sid":"UpdateEnvironmentInApplications",
"Action":[
"elasticbeanstalk:UpdateEnvironment"
],
"Effect":"Allow",
"Resource":[
"arn:aws:elasticbeanstalk:us-east-2:123456789012:environment/app1/app1-staging*"
],
"Condition":{
"StringEquals":{
"elasticbeanstalk:InApplication":[
"arn:aws:elasticbeanstalk:us-east-2:123456789012:application/app1"
]
},
"StringLike":{
"elasticbeanstalk:FromApplicationVersion":[
"arn:aws:elasticbeanstalk:us-east-2:123456789012:applicationversion/app1/*"
]
}
}
},
{
"Sid":"AllReadCallsOnSolutionStacks",
"Action":[
"elasticbeanstalk:ListAvailableSolutionStacks",
"elasticbeanstalk:DescribeConfigurationOptions",
"elasticbeanstalk:ValidateConfigurationSettings"
],
"Effect":"Allow",
"Resource":[
"arn:aws:elasticbeanstalk:us-east-2::solutionstack/*"
]
}
]
}La troisième stratégie spécifie les actions Elastic Beanstalk pour lesquelles la deuxième stratégie a besoin d'autorisations afin de réaliser ces actions Elastic Beanstalk. L'instruction AllNonResourceCalls autorise l'action elasticbeanstalk:CheckDNSAvailability, qui est obligatoire pour appeler elasticbeanstalk:CreateEnvironment et d'autres actions. Elle autorise également l'action elasticbeanstalk:CreateStorageLocation, qui est obligatoire pour elasticbeanstalk:CreateEnvironment, et d'autres actions.
{
"Version": "2012-10-17",
"Statement":[
{
"Sid":"AllNonResourceCalls",
"Action":[
"elasticbeanstalk:CheckDNSAvailability",
"elasticbeanstalk:CreateStorageLocation"
],
"Effect":"Allow",
"Resource":[
"*"
]
}
]
}