nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

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.

Accepted answers

Vitalii Rybka

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

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

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!

All comments

Vitalii Rybka

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

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

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

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

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.

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

cloud

bitbucket

bitbucket-cloud

bitbucket-pipelines

aws

pipes