Example policies based on resource permissions - Amazon Elastic Beanstalk
Services or capabilities described in Amazon Web Services documentation might vary by Region. To see the differences applicable to the China Regions, see Getting Started with Amazon Web Services in China (PDF).

Example policies based on resource permissions

This section walks through a use case for controlling user permissions for Elastic Beanstalk actions that access specific Elastic Beanstalk resources. We'll walk through the sample policies that support the use case. For more information policies on Elastic Beanstalk resources, see Creating a custom user policy. For information about attaching policies to users and groups, go to Managing IAM Policies in Using Amazon Identity and Access Management.

In our use case, Example Corp. is a small consulting firm developing applications for two different customers. John is the development manager overseeing the development of the two Elastic Beanstalk applications, app1 and app2. John does development and some testing on the two applications, and only he can update the production environment for the two applications. These are the permissions that he needs for app1 and app2:

  • View application, application versions, environments, and configuration templates

  • Create application versions and deploy them to the staging environment

  • Update the production environment

  • Create and terminate environments

Jill is a tester who needs access to view the following resources in order to monitor and test the two applications: applications, application versions, environments, and configuration templates. However, she should not be able to make changes to any Elastic Beanstalk resources.

Jack is the developer for app1 who needs access to view all resources for app1 and also needs to create application versions for app1 and deploy them to the staging environment.

Judy is the administrator of the Amazon account for Example Corp. She has created IAM users for John, Jill, and Jack and attaches the following policies to those users to grant the appropriate permissions to the app1 and app2 applications.

Example 1: John – Development manager for app1, app2

We have broken down John's policy into three separate policies so that they are easier to read and manage. Together, they give John the permissions he needs to perform development, testing, and deployment actions on the two applications.

The first policy specifies actions for Auto Scaling, Amazon S3, Amazon EC2, CloudWatch, Amazon SNS, Elastic Load Balancing, Amazon RDS, and Amazon CloudFormation. Elastic Beanstalk relies on these additional services to provision underlying resources when creating an environment.

Note that this policy is an example. It gives a broad set of permissions to the Amazon products that Elastic Beanstalk uses to manage applications and environments. For example, ec2:* allows an IAM user to perform any action on any Amazon EC2 resource in the Amazon account. These permissions are not limited to the resources that you use with Elastic Beanstalk. As a best practice, you should grant individuals only the permissions they need to perform their duties.

{ "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":"*" } ] }

The second policy specifies the Elastic Beanstalk actions that John is allowed to perform on the app1 and app2 resources. The AllCallsInApplications statement allows all Elastic Beanstalk actions ("elasticbeanstalk:*") performed on all resources within app1 and app2 (for example, elasticbeanstalk:CreateEnvironment). The AllCallsOnApplications statement allows all Elastic Beanstalk actions ("elasticbeanstalk:*") on the app1 and app2 application resources (for example, elasticbeanstalk:DescribeApplications, elasticbeanstalk:UpdateApplication, etc.). The AllCallsOnSolutionStacks statement allows all Elastic Beanstalk actions ("elasticbeanstalk:*") for solution stack resources (for example, elasticbeanstalk:ListAvailableSolutionStacks).

{ "Version": "2012-10-17", "Statement":[ { "Sid":"AllCallsInApplications", "Action":[ "elasticbeanstalk:*" ], "Effect":"Allow", "Resource":[ "*" ], "Condition":{ "StringEquals":{ "elasticbeanstalk:InApplication":[ "arn:aws-cn:elasticbeanstalk:us-west-2:123456789012:application/app1", "arn:aws-cn:elasticbeanstalk:us-west-2:123456789012:application/app2" ] } } }, { "Sid":"AllCallsOnApplications", "Action":[ "elasticbeanstalk:*" ], "Effect":"Allow", "Resource":[ "arn:aws-cn:elasticbeanstalk:us-west-2:123456789012:application/app1", "arn:aws-cn:elasticbeanstalk:us-west-2:123456789012:application/app2" ] }, { "Sid":"AllCallsOnSolutionStacks", "Action":[ "elasticbeanstalk:*" ], "Effect":"Allow", "Resource":[ "arn:aws-cn:elasticbeanstalk:us-west-2::solutionstack/*" ] } ] }

The third policy specifies the Elastic Beanstalk actions that the second policy needs permissions to in order to complete those Elastic Beanstalk actions. The AllNonResourceCalls statement allows the elasticbeanstalk:CheckDNSAvailability action, which is required to call elasticbeanstalk:CreateEnvironment and other actions. It also allows the elasticbeanstalk:CreateStorageLocation action, which is required for elasticbeanstalk:CreateApplication, elasticbeanstalk:CreateEnvironment, and other actions.

{ "Version": "2012-10-17", "Statement":[ { "Sid":"AllNonResourceCalls", "Action":[ "elasticbeanstalk:CheckDNSAvailability", "elasticbeanstalk:CreateStorageLocation" ], "Effect":"Allow", "Resource":[ "*" ] } ] }

Example 2: Jill – Tester for app1, app2

We have broken down Jill's policy into three separate policies so that they are easier to read and manage. Together, they give Jill the permissions she needs to perform testing and monitoring actions on the two applications.

The first policy specifies Describe*, List*, and Get* actions on Auto Scaling, Amazon S3, Amazon EC2, CloudWatch, Amazon SNS, Elastic Load Balancing, Amazon RDS, and Amazon CloudFormation (for non-legacy container types) so that the Elastic Beanstalk actions are able to retrieve the relevant information about the underlying resources of the app1 and app2 applications.

{ "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":"*" } ] }

The second policy specifies the Elastic Beanstalk actions that Jill is allowed to perform on the app1 and app2 resources. The AllReadCallsInApplications statement allows her to call the Describe* actions and the environment info actions. The AllReadCallsOnApplications statement allows her to call the DescribeApplications and DescribeEvents actions on the app1 and app2 application resources. The AllReadCallsOnSolutionStacks statement allows viewing actions that involve solution stack resources (ListAvailableSolutionStacks, DescribeConfigurationOptions, and ValidateConfigurationSettings).

{ "Version": "2012-10-17", "Statement":[ { "Sid":"AllReadCallsInApplications", "Action":[ "elasticbeanstalk:Describe*", "elasticbeanstalk:RequestEnvironmentInfo", "elasticbeanstalk:RetrieveEnvironmentInfo" ], "Effect":"Allow", "Resource":[ "*" ], "Condition":{ "StringEquals":{ "elasticbeanstalk:InApplication":[ "arn:aws-cn:elasticbeanstalk:us-west-2:123456789012:application/app1", "arn:aws-cn:elasticbeanstalk:us-west-2:123456789012:application/app2" ] } } }, { "Sid":"AllReadCallsOnApplications", "Action":[ "elasticbeanstalk:DescribeApplications", "elasticbeanstalk:DescribeEvents" ], "Effect":"Allow", "Resource":[ "arn:aws-cn:elasticbeanstalk:us-west-2:123456789012:application/app1", "arn:aws-cn:elasticbeanstalk:us-west-2:123456789012:application/app2" ] }, { "Sid":"AllReadCallsOnSolutionStacks", "Action":[ "elasticbeanstalk:ListAvailableSolutionStacks", "elasticbeanstalk:DescribeConfigurationOptions", "elasticbeanstalk:ValidateConfigurationSettings" ], "Effect":"Allow", "Resource":[ "arn:aws-cn:elasticbeanstalk:us-west-2::solutionstack/*" ] } ] }

The third policy specifies the Elastic Beanstalk actions that the second policy needs permissions to in order to complete those Elastic Beanstalk actions. The AllNonResourceCalls statement allows the elasticbeanstalk:CheckDNSAvailability action, which is required for some viewing actions.

{ "Version": "2012-10-17", "Statement":[ { "Sid":"AllNonResourceCalls", "Action":[ "elasticbeanstalk:CheckDNSAvailability" ], "Effect":"Allow", "Resource":[ "*" ] } ] }

Example 3: Jack – Developer for app1

We have broken down Jack's policy into three separate policies so that they are easier to read and manage. Together, they give Jack the permissions he needs to perform testing, monitoring, and deployment actions on the app1 resource.

The first policy specifies the actions on Auto Scaling, Amazon S3, Amazon EC2, CloudWatch, Amazon SNS, Elastic Load Balancing, Amazon RDS, and Amazon CloudFormation (for non-legacy container types) so that the Elastic Beanstalk actions are able to view and work with the underlying resources of app1. For a list of supported non-legacy container types, see Why are some platform versions marked legacy?

Note that this policy is an example. It gives a broad set of permissions to the Amazon products that Elastic Beanstalk uses to manage applications and environments. For example, ec2:* allows an IAM user to perform any action on any Amazon EC2 resource in the Amazon account. These permissions are not limited to the resources that you use with Elastic Beanstalk. As a best practice, you should grant individuals only the permissions they need to perform their duties.

{ "Version": "2012-10-17", "Statement":[ { "Effect":"Allow", "Action":[ "ec2:*", "elasticloadbalancing:*", "autoscaling:*", "cloudwatch:*", "s3:*", "sns:*", "rds:*", "cloudformation:*" ], "Resource":"*" } ] }

The second policy specifies the Elastic Beanstalk actions that Jack is allowed to perform on the app1 resource.

{ "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-cn:elasticbeanstalk:us-west-2:123456789012:application/app1" ] } } }, { "Sid":"AllReadCallsOnApplications", "Action":[ "elasticbeanstalk:DescribeApplications", "elasticbeanstalk:DescribeEvents" ], "Effect":"Allow", "Resource":[ "arn:aws-cn:elasticbeanstalk:us-west-2:123456789012:application/app1" ] }, { "Sid":"UpdateEnvironmentInApplications", "Action":[ "elasticbeanstalk:UpdateEnvironment" ], "Effect":"Allow", "Resource":[ "arn:aws-cn:elasticbeanstalk:us-west-2:123456789012:environment/app1/app1-staging*" ], "Condition":{ "StringEquals":{ "elasticbeanstalk:InApplication":[ "arn:aws-cn:elasticbeanstalk:us-west-2:123456789012:application/app1" ] }, "StringLike":{ "elasticbeanstalk:FromApplicationVersion":[ "arn:aws-cn:elasticbeanstalk:us-west-2:123456789012:applicationversion/app1/*" ] } } }, { "Sid":"AllReadCallsOnSolutionStacks", "Action":[ "elasticbeanstalk:ListAvailableSolutionStacks", "elasticbeanstalk:DescribeConfigurationOptions", "elasticbeanstalk:ValidateConfigurationSettings" ], "Effect":"Allow", "Resource":[ "arn:aws-cn:elasticbeanstalk:us-west-2::solutionstack/*" ] } ] }

The third policy specifies the Elastic Beanstalk actions that the second policy needs permissions to in order to complete those Elastic Beanstalk actions. The AllNonResourceCalls statement allows the elasticbeanstalk:CheckDNSAvailability action, which is required to call elasticbeanstalk:CreateEnvironment and other actions. It also allows the elasticbeanstalk:CreateStorageLocation action, which is required for elasticbeanstalk:CreateEnvironment, and other actions.

{ "Version": "2012-10-17", "Statement":[ { "Sid":"AllNonResourceCalls", "Action":[ "elasticbeanstalk:CheckDNSAvailability", "elasticbeanstalk:CreateStorageLocation" ], "Effect":"Allow", "Resource":[ "*" ] } ] }