Configuration
Address limitations with the AWS CLI
The most frequent use case for the AWS Credentials Variables task is to address scenarios not (yet) covered by dedicated tasks, see How to work around limitations with the AWS Command Line Interface (AWS CLI) for details.
To configure an AWS Credentials Variables task:
- Navigate to the Tasks configuration tab for the job (this will be the default job if creating a new plan).
- Click the name of an existing AWS Credentials Variables task, or click Add Task and then AWS Credentials Variables to create a new task.
Complete the following settings:
Task Description | (Optional) Identify the purpose of the task. |
Disable this task | Check, or clear, to selectively run this task. |
Add Caller Identity | Check to add variables with details about the IAM identity whose credentials are used to call the API (see get-caller-identity). Clear to skip the additional API call required to retrieve these details. |
Source | Select the AWS Credentials Source (see below). Can be either Identity Federation for AWS or an IAM Role for EC2. |
Connector | (Conditional) Select the shared Identity Federation for AWS Connector. Alternatively, select [Use connector variable ...] to supply the connector dynamically via Bamboo variables (needs to be a connector id such as |
Role ARN | (Conditional | Optional) Specify the ARN of another role that the agent's IAM role for EC2 should assume. |
AWS Credentials Sources
IAM Policy
The AWS Credentials Variables task requires IAM permissions to retrieve temporary security credentials via the AWS Security Token Service (STS) - an all-encompassing policy might look as follows:
Refer to Granting Permissions to Create Temporary Security Credentials for details on how to create more granular/secure policies, for example:
- you can remove permissions for unused principal types.
- you can further restrict permissions via more specific resource declarations
You have the following options to provide AWS Security Credentials:
Identity Federation for AWS
Federated Amazon Web Services access
This is the recommended approach to share and manage AWS credentials:
- It provides benefits like easy credentials sharing and reuse, fine grained access control for AWS resources, strong encryption and more.
Refer to the Administrator's Guide for details on how to configure the connectors.
- this option requires at least one AWS Connector to be configured with System Scope to allow usage from Bamboo builds, where no user session is available
- a connector yields a set of temporary credentials on task execution (optionally limiting the IAM permissions)
- you can configure multiple connectors to provide credentials with different IAM permissions tailored for specific use cases
IAM Role for EC2 (Agent)
You can use IAM Roles for Amazon EC2 to optionally skip credentials configuration all together: if an agent happens to run on an EC2 instance started with an instance profile (IAM role), the tasks can be configured to facilitate those credentials. Of course, the underlying IAM role needs to have a sufficient policy attached to grant the the required permissions for the task at hand.
This feature requires the Amazon EC2 instance running the agent to be started with an EC2 instance profile. There are three different scenarios:
- local agents - requires the hosting Bamboo server itself to run on EC2
- remote/elastic agents - requires the remote agent to run on EC2
- elastic agents - requires the elastic agent to run on EC2
- As of release 2.4, you can optionally specify the ARN of another role that the agent's IAM role for EC2 should assume via the EC2 instance profile credentials - this enables various scenarios, notably switching to roles across your own AWS accounts and third-party.AWS accounts (cross-account IAM roles).
- Elastic Bamboo only supports configuring elastic images with an instance profile as of Bamboo 5.6.
Usage
Bamboo variables
This task generates the following Bamboo variables for reuse in subsequent tasks without native integration with Identity Federation for AWS:
${bamboo.custom.aws.accessKeyId} ${bamboo.custom.aws.secretAccessKey.password} ${bamboo.custom.aws.sessionToken.password} # Optional: the callerIdentity namespace is only present when option 'Add Caller Identity' is checked. ${bamboo.custom.aws.callerIdentity.account} ${bamboo.custom.aws.callerIdentity.arn} ${bamboo.custom.aws.callerIdentity.userId}
The '
*.password
' suffix ensures that these sensitive variables are masked with asterisks ('*******') in the Bamboo build log.
An alternative representation as a JSON object for automated processing with tools like jq is available too:
${bamboo.custom.aws.credentials.json.password} # Optional: the callerIdentity namespace is only present when option 'Add Caller Identity' is checked. ${bamboo.custom.aws.callerIdentity.json}
Environment variables
Aforementioned variables will also be available as environment variables for use in Bamboo Script tasks. The syntax differs between shells, as illustrated in these examples for assigning them to the standardized variables used by tools like the AWS Command Line Interface (AWS CLI):
export AWS_ACCESS_KEY_ID=$bamboo_custom_aws_accessKeyId export AWS_SECRET_ACCESS_KEY=$bamboo_custom_aws_secretAccessKey_password export AWS_SESSION_TOKEN=$bamboo_custom_aws_sessionToken_password
$AWS_ACCESS_KEY_ID = $bamboo_custom_aws_accessKeyId $AWS_SECRET_ACCESS_KEY = $bamboo_custom_aws_secretAccessKey_password $AWS_SESSION_TOKEN = $bamboo_custom_aws_sessionToken_password
set AWS_ACCESS_KEY_ID=%bamboo_custom_aws_accessKeyId% set AWS_SECRET_ACCESS_KEY=%bamboo_custom_aws_secretAccessKey_password% set AWS_SESSION_TOKEN=%bamboo_custom_aws_sessionToken_password%
How-to Articles