Using the pipe with ROLE_ARN does not seem to work when using 2 different accounts.
- pipe: atlassian/aws-cloudformation-deploy:0.10.0
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.0
Using default authentication with AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY.
INFO: Found credentials in environment variables.
Using stack template from template.yml for deploy.
INFO: Validating the template.
INFO: Updating the stack for notebook-dev.
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 \
Expected behavior should be like this pipe where a similar configuration works.
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.
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
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'