IAM policy that we attach to CI users so that our CI server can deploy new versions of our applications to our EB environments without giving them too many permissions. When some permissions are missing, deploys may fail with the useless and misleading ERROR event log
Service:AmazonCloudFormation, Message:TemplateURL must reference a valid S3 object to which you have access.
(Notice that in many cases the error has nothing to do with S3 but can be caused by any missing permissions, for instance autoscaling:SuspendProcesse
. Yes, it sucks.)
The policy can certainly be tightened more, it is not the most restrictive policy that works. As Kyle points out, the full EC2 rights are likely the biggest problem.
If a deployment to Elastic Beanstalk fails with this policy:
- Give the user full access and retry to verify that it as a permission problem.
- Revert. You might already have fixed the problem - some deployments need elevated permissions, for example when you change anything in
.ebextensions
, anelasticbeanstalk.UpdateEnvironment
will pass but it will consequently try toUpdateStack
, which my fail. But once it succeeds for a given Beanstalk environment, it won't be done again (well, untiil you change the config again). - You are out of luck. AWS is very opaque about what it does and it is hard, if not impossible, to find out what operation failed. CloudTrail does not really help.
Check out also the popular AWS Elastic Beanstalk deploy user restricted IAM policy by magnetikonline and the comments under it. (Among others, it limits access to only a particular EB application. I am sure I could make my policy more restrictive based on its example.)
- 2017-04-21 Added
"s3:Get*","s3:List*"
,"autoscaling:UpdateAutoScalingGroup", "autoscaling:DescribeLaunchConfigurations"
to fix a problem with "Rolling with additional batch" deployments (the infamous "Service:AmazonCloudFormation, Message:TemplateURL must reference a valid S3 object to which you have access.")