Come for the products,
stay for the community

The Atlassian Community can help you and your team get more value out of Atlassian products and practices.

Atlassian Community about banner
4,368,495
Community Members
 
Community Events
168
Community Groups

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

Atlassian Community Events