Create
cancel
Showing results for 
Search instead for 
Did you mean: 
Sign up Log in

It's not the same without you

Join the community to find out what other Atlassian users are discussing, debating and creating.

Atlassian Community Hero Image Collage

aws-cloudformation-deploy does not work with Role_ARN / cross account

Hi,

Using the pipe with ROLE_ARN does not seem to work when using 2 different accounts.

- pipe: atlassian/aws-cloudformation-deploy:0.10.0
variables:
STACK_NAME: $SERVICE-$BITBUCKET_DEPLOYMENT_ENVIRONMENT
ROLE_ARN: arn:aws:iam::$AWS_ACCOUNT_ID:role/Deployment
AWS_ACCESS_KEY_ID: $AWS_ACCESS_KEY_ID_V2
AWS_SECRET_ACCESS_KEY: $AWS_SECRET_ACCESS_KEY_V2

The AWS_ACCESS_KEY_ID_V2 & AWS_SECRET_ACCESS_KEY_V2 are credentials of a IAM User that is defined in Account A but can assume the Deployment Role in account B where the deployment needs to happen. However this does not work.

Error below for the stack being deployed first time in Account B.

Status: Downloaded newer image for bitbucketpipelines/aws-cloudformation-deploy:0.10.0INFO: 
Using default authentication with AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY.
INFO: Found credentials in environment variables.INFO:
Using stack template from template.yml for deploy.
INFO: Validating the template.INFO: Updating the stack for notebook-dev.ERROR:
Failed to get information about stack notebook-dev.
An error occurred (ValidationError) when calling the DescribeStacks operation: Stack with id notebook-dev does not exist
Failed to update the stack.
An error occurred (AccessDenied) when calling the UpdateStack operation: Cross-account pass role is not allowed.

It could be possible that the AWS_ACCESS_KEY_ID & AWS_SECRET_ACCESS_KEY variables are not being used properly as the default environment variables in Bitbucket environment is for another account C where user cannot assume role.

The following configuration works without using the pipe -

- export AWS_ACCESS_KEY_ID=$AWS_ACCESS_KEY_ID_V2
- export AWS_SECRET_ACCESS_KEY=$AWS_SECRET_ACCESS_KEY_V2
- aws s3 cp s3://$GROUP_V2/deploymentArchives/$SERVICE/$BITBUCKET_BUILD_NUMBER/template.yml .
- eval $(aws sts assume-role --role-arn arn:aws:iam::$AWS_ACCOUNT_ID:role/Deployment --role-session-name Bitbucket | jq -r '.Credentials | "export AWS_ACCESS_KEY_ID=\(.AccessKeyId)\nexport AWS_SECRET_ACCESS_KEY=\(.SecretAccessKey)\nexport AWS_SESSION_TOKEN=\(.SessionToken)\n"')
- >
aws cloudformation deploy \
--stack-name $SERVICE-$BITBUCKET_DEPLOYMENT_ENVIRONMENT \
--template-file template.yml \
--capabilities CAPABILITY_NAMED_IAM CAPABILITY_IAM CAPABILITY_AUTO_EXPAND \
--parameter-overrides \
AppId=$SERVICE \
BuildNumber=$BITBUCKET_BUILD_NUMBER \
Environment=$BITBUCKET_DEPLOYMENT_ENVIRONMENT \
Group=$GROUP_V2 \
--tags \
AppID=$SERVICE \
BuildNumber=$BITBUCKET_BUILD_NUMBER \
Environment=$BITBUCKET_DEPLOYMENT_ENVIRONMENT \
Branch=$BITBUCKET_BRANCH \
Name=$SERVICE-$BITBUCKET_DEPLOYMENT_ENVIRONMENT \
Project=$GROUP_V2 \
Immutable=True

 

Expected behavior should be like this pipe where a similar configuration works.

https://bitbucket.org/sightsoundtheatres/aws-cdk-deploy/src/master/

 

2 answers

Hi @Oleksandr Kyrdan

My team has the same issue.

It seems like the pipe is trying to pass the role rather than assuming it. As far as I understand there is no way to have a user from, say, Account A have the permission to pass a role from Account B unless it first assumes a role from Account B. Since the pipe does not have the ability to assume a role it cannot deploy a cloudformation stack to another AWS account.

OIDC is not an option for us. The resource we want to deploy should not be per BB workspace. And we do not want to create or update a OIDC role for every new BB repository we create.

0 votes

Hi @Rahul Arora

Thank you for your question!

It could be a good case for the new feature OpenID Connect provided by Bitbucket Pipelines:

Deploy a new version of your CloudFormation stack with OpenID Connect (OIDC) alternative authentication without required AWS_ACCESS_KEY_IDAWS_SECRET_ACCESS_KEY.

Parameter oidc: true in the step configuration and variable AWS_OIDC_ROLE_ARN are required:

- step:
    oidc: true
    script:
      - pipe: atlassian/aws-cloudformation-deploy:0.10.0
        variables:
          AWS_DEFAULT_REGION: $AWS_DEFAULT_REGION
          AWS_OIDC_ROLE_ARN: 'arn:aws:iam::123456789012:role/role_name'
          STACK_NAME: 'my-stack-name'
          TEMPLATE: 'stack_template.json'

 

Cheers,
Oleksandr Kyrdan

While the OIDC approach may work, but it would requires us to setup Bitbucket as a trusted web identify provider in AWS. I should be able to use a profile (access key/secret key) and be able to assume the role. 

Suggest an answer

Log in or Sign up to answer
TAGS
Community showcase
Published in Jira

Admins, notify your Jira instance of system-wide changes with the new admin announcement banner

Hi All! We’re excited to share the launch of an announcement banner that lets Jira site administrators communicate directly to their users across their  Jira Cloud instance.  ...

506 views 16 17
Read article

Community Events

Connect with like-minded Atlassian users at free events near you!

Find an event

Connect with like-minded Atlassian users at free events near you!

Unfortunately there are no Community Events near you at the moment.

Host an event

You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events

Events near you