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 stratégies gérées
Cette section montre comment contrôler l'accès utilisateur à AWS Elastic Beanstalk et inclut des exemples de stratégies qui fournissent l'accès requis pour les scénarios courants. Ces stratégies sont dérivées des stratégies gérées par Elastic Beanstalk. Pour plus d'informations sur l'attachement de stratégies gérées à des groupes et des utilisateurs, consultez Gestion des stratégies utilisateur Elastic Beanstalk.
Dans ce scénario, Example Corp. est une société de logiciels avec trois équipes chargées du site web d'entreprise : les administrateurs qui gèrent l'infrastructure, les développeurs qui construisent le logiciel du site web et une équipe d'assurance qualité qui teste le site web. Pour aider à gérer les autorisations pour ses ressources Elastic Beanstalk, Example Corp. crée trois groupes auxquels appartiennent les membres de chaque équipe respective : administrateurs, développeurs et testeurs. Example Corp. souhaite que le groupe des administrateurs dispose d'un accès complet à toutes les applications, tous les environnements et leurs ressources sous-jacentes afin qu'ils puissent créer, dépanner et supprimer toutes les ressources Elastic Beanstalk. Les développeurs ont besoin d'autorisations pour afficher toutes les ressources Elastic Beanstalk ainsi que créer et déployer des versions d'application. Les développeurs ne doivent pas pouvoir créer de nouvelles applications ou de nouveaux environnements ou encore interrompre des environnements en cours d'exécution. Les testeurs doivent consulter toutes les ressources Elastic Beanstalk pour surveiller et tester les applications. Les testeurs ne devraient pas être en mesure d'apporter des modifications aux ressources Elastic Beanstalk.
Les exemples de stratégies suivants fournissent les autorisations requises pour chaque groupe.
Exemple 1 : Groupe d'administrateurs – Toutes les API Elastic Beanstalk et les API des services connexes
La stratégie suivante fournit aux utilisateurs des autorisations pour toutes les actions requises pour utiliser Elastic Beanstalk. Cette stratégie permet également à Elastic Beanstalk de mettre en service et de gérer des ressources en votre nom dans les services suivants. Elastic Beanstalk s'appuie sur ces services supplémentaires pour fournir des ressources sous-jacentes lors de la création d'un environnement.
-
Amazon Elastic Compute Cloud
-
Elastic Load Balancing
-
Auto Scaling
-
Amazon CloudWatch
-
Amazon Simple Storage Service
-
Amazon Simple Notification Service
-
Amazon Relational Database Service
-
AWS CloudFormation
Notez que cette stratégie est un exemple. Elle offre un large ensemble d'autorisations pour les services AWS qu'Elastic Beanstalk utilise pour gérer les applications et les environnements. Par exemple, ec2:*
permet à un utilisateur AWS Identity and Access Management (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" : [
"elasticbeanstalk:*",
"ec2:*",
"elasticloadbalancing:*",
"autoscaling:*",
"cloudwatch:*",
"s3:*",
"sns:*",
"rds:*",
"cloudformation:*"
],
"Resource" : "*"
}
]
}
Exemple 2 : Groupe de développeurs – Toutes les opérations à l'exception des opérations nécessitant des privilèges élevés
La stratégie suivante refuse l'autorisation de créer des applications et des environnements, mais autorise toutes les autres actions Elastic Beanstalk.
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" : [
{
"Action" : [
"elasticbeanstalk:CreateApplication",
"elasticbeanstalk:CreateEnvironment",
"elasticbeanstalk:DeleteApplication",
"elasticbeanstalk:RebuildEnvironment",
"elasticbeanstalk:SwapEnvironmentCNAMEs",
"elasticbeanstalk:TerminateEnvironment"],
"Effect" : "Deny",
"Resource" : "*"
},
{
"Action" : [
"elasticbeanstalk:*",
"ec2:*",
"elasticloadbalancing:*",
"autoscaling:*",
"cloudwatch:*",
"s3:*",
"sns:*",
"rds:*",
"cloudformation:*"],
"Effect" : "Allow",
"Resource" : "*"
}
]
}
Exemple 3 : Testeurs – Affichage uniquement
La stratégie suivante autorise l'accès en lecture seule à toutes les applications, toutes les versions d'applications, tous les événements et tous les environnements. Elle ne permet d'effectuer aucune action.
{
"Version" : "2012-10-17",
"Statement" : [
{
"Effect" : "Allow",
"Action" : [
"elasticbeanstalk:Check*",
"elasticbeanstalk:Describe*",
"elasticbeanstalk:List*",
"elasticbeanstalk:RequestEnvironmentInfo",
"elasticbeanstalk:RetrieveEnvironmentInfo",
"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" : "*"
}
]
}