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

[Rahul Arora]

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/

[David Lindskog Hedström]

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.

[Oleksandr Kyrdan]

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_ID, AWS_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

[Rahul Arora]

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.