Permissions for atlassian/aws-elasticbeanstalk-deploy:1.5.0 with OIDC

[Matthew Musgrove]

What permissions are required to use the atlassian/aws-elasticbeanstalk-deploy:1.5.0 pipe with an OIDC deployment? I want to ensure that I haven't given to many permissions to the OIDC role.

[Vitalii Rybka · Accepted solution]

Hi @Matthew Musgrove,

For the atlassian/aws-elasticbeanstalk-deploy:1.5.0 pipe with OIDC, you'll need these minimum IAM permissions:

Essential Permissions:

json

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "elasticbeanstalk:CreateApplicationVersion",
        "elasticbeanstalk:DescribeApplicationVersions",
        "elasticbeanstalk:DescribeApplications",
        "elasticbeanstalk:DescribeEnvironments",
        "elasticbeanstalk:UpdateEnvironment",
        "s3:GetObject",
        "s3:PutObject",
        "s3:DeleteObject"
      ],
      "Resource": "*"
    }
  ]
}

Additional permissions you might need:

• elasticbeanstalk:DescribeEvents - for deployment status
• elasticbeanstalk:DescribeEnvironmentHealth - for health checks
• S3 bucket-specific permissions for your deployment artifacts

Best Practice:

• Scope S3 permissions to specific buckets: arn:aws:s3:::your-eb-bucket/*
• Add condition statements to limit resource access by environment/application

OIDC Trust Policy: Make sure your OIDC role has the correct trust relationship with your Bitbucket repository.

The exact permissions can vary based on your specific EB configuration and deployment needs.

Need help with the complete IAM policy setup? Feel free to DM me!

[Matthew Musgrove]

That's what I thought as well but in practice I'm getting permission errors for things from cloudformation, autoscaling, and ec2.

[Matthew Musgrove]

I removed all of the elasticbeanstalk, cloudformation, autoscaling, ec2, etc permissions and adding the AWSElasticBeanstalkManagedUpdatesCustomerRolePolicy policy instead.

[Vitalii Rybka]

Hi @Matthew Musgrove,

Good catch! You're absolutely right - EB deployments often trigger CloudFormation, Auto Scaling, and EC2 operations behind the scenes. The AWSElasticBeanstalkManagedUpdatesCustomerRolePolicy is a solid approach.

Alternative Managed Policies to Consider:

• AWSElasticBeanstalkWebTier - for web server environments
• AWSElasticBeanstalkWorkerTier - for worker environments
• AWSElasticBeanstalkMulticontainerDocker - if using Docker

If You Want Granular Control: You'll likely need these additional permissions:

json

{
  "Effect": "Allow",
  "Action": [
    "cloudformation:DescribeStacks",
    "cloudformation:DescribeStackEvents", 
    "cloudformation:DescribeStackResources",
    "autoscaling:DescribeAutoScalingGroups",
    "autoscaling:DescribeLaunchConfigurations",
    "ec2:DescribeInstances",
    "ec2:DescribeImages",
    "ec2:DescribeSecurityGroups"
  ],
  "Resource": "*"
}

Pro Tip: Enable CloudTrail temporarily during deployment to see exactly which API calls are being made - helps identify the minimal permission set.

The managed policy route is often the safest bet for EB since AWS keeps it updated with the required permissions as the service evolves.