AWS Documentation » AWS Elastic Beanstalk » AWS Elastic Beanstalk Developer Guide » Using AWS Elastic Beanstalk with Other AWS Services » Using AWS Elastic Beanstalk with AWS Identity and Access Management (IAM) » Example Policies Based on Resource Permissions	« Previous Next »
	Did this page help you? Yes \| No \| Tell us about it...

Example Policies Based on Resource Permissions

This section walks through a use case for controlling user permissions for AWS Elastic Beanstalk actions that access specific AWS Elastic Beanstalk resources. We'll walk through the sample policies that support the use case. For more information policies on AWS Elastic Beanstalk resources, see Creating Policies to Control Access to Specific AWS Elastic Beanstalk Resources. For information about attaching policies to users and groups, go to Managing IAM Policies in Using AWS 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 AWS 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 AWS 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.

Joe is the administrator of the AWS account for Example Corp. He 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: Policies that allow John to perform his development, test, and deployment actions on app1 and 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 the AWS Elastic Beanstalk actions on the two applications.

The first policy specifies actions for Auto Scaling, Amazon S3, Amazon EC2, Amazon CloudWatch, Amazon SNS, Elastic Load Balancing, Amazon RDS, and AWS CloudFormation (for non-legacy container types). AWS Elastic Beanstalk relies on these additional services to provision underlying resources when creating an environment. For a list of supported non-legacy container types, see Why are some container types marked legacy?.

Note

The following policy is an example. It gives a broad set of permissions to the AWS products that AWS 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 AWS account. These permissions are not limited to the resources that you use with AWS Elastic Beanstalk. As a best practice, you should grant individuals only the permissions they need to perform their duties.

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

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

{
   "Statement":[
      {
         "Sid":"AllCallsInApplications",
         "Action":[
            "elasticbeanstalk:*"
         ],
         "Effect":"Allow",
         "Resource":[
            "*"
         ],
         "Condition":{
            "StringEquals":{
               "elasticbeanstalk:InApplication":[
                  "arn:aws:elasticbeanstalk:us-east-1:123456789012:application/app1",
                  "arn:aws:elasticbeanstalk:us-east-1:123456789012:application/app2"
               ]
            }
         }
      },
      {
         "Sid":"AllCallsOnApplications",
         "Action":[
            "elasticbeanstalk:*"
         ],
         "Effect":"Allow",
         "Resource":[
            "arn:aws:elasticbeanstalk:us-east-1:123456789012:application/app1",
            "arn:aws:elasticbeanstalk:us-east-1:123456789012:application/app2"
         ]
      },
      {
         "Sid":"AllCallsOnSolutionStacks",
         "Action":[
            "elasticbeanstalk:*"
         ],
         "Effect":"Allow",
         "Resource":[
            "arn:aws:elasticbeanstalk:us-east-1::solutionstack/*"
         ]
      }
   ]
}

The third policy specifies the AWS Elastic Beanstalk actions that the second policy needs permissions to in order to complete those AWS 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.

{
   "Statement":[
      {
         "Sid":"AllNonResourceCalls",
         "Action":[
            "elasticbeanstalk:CheckDNSAvailability",
            "elasticbeanstalk:CreateStorageLocation"
         ],
         "Effect":"Allow",
         "Resource":[
            "*"
         ]
      }
   ]
}

Example 2: Policies that allow Jill to test and monitor app1 and 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 the AWS Elastic Beanstalk actions on the two applications.

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

{
   "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 AWS 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).

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

{
   "Statement":[
      {
         "Sid":"AllNonResourceCalls",
         "Action":[
            "elasticbeanstalk:CheckDNSAvailability"
         ],
         "Effect":"Allow",
         "Resource":[
            "*"
         ]
      }
   ]
}

Example 3: Policies that allow Jack to access app1 to test, monitor, create application versions, and deploy to the staging environment

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 the AWS Elastic Beanstalk actions on the app1 resource.

The first policy specifies the actions on Auto Scaling, Amazon S3, Amazon EC2, Amazon CloudWatch, Amazon SNS, Elastic Load Balancing, Amazon RDS, and AWS CloudFormation (for non-legacy container types) so that the AWS 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 container types marked legacy?.

Note

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

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

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

{
   "Statement":[
      {
         "Sid":"AllNonResourceCalls",
         "Action":[
            "elasticbeanstalk:CheckDNSAvailability",
            "elasticbeanstalk:CreateStorageLocation"
         ],
         "Effect":"Allow",
         "Resource":[
            "*"
         ]
      }
   ]
}

Document Conventions	« Previous Next »
Terms of Use	Did this page help you? Yes \| No \| Tell us about it...