Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 25 Next »

AWS Credentials Sources

You currently have three 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 (please refer to the Identity Federation for AWS Documentation for more information regarding the available features and implied advantages).

Refer to Administering Identity Federation for AWS for details on how to configure the connectors.

  • (info) 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

  • (lightbulb) you can also facilitate Bamboo variables to ease managing connectors as outlined in How to parametrize the AWS connector via a Bamboo variable

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 sufficient permissions for the task at hand.

This credentials source requires the agent to be running on an Amazon EC2 instance started with an instance profile, which yields three scenarios:

  • local agent - requires the hosting Bamboo server itself to run on EC2

  • remote agent - requires the remote agent to run on EC2

  • elastic agent - requires the elastic agent to run on EC2
    (lightbulb) You can optionally specify the ARN of another role that the agent's IAM role for EC2 should assume via the 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).

Inline

No Real Encryption

This is not recommended, but easy to get started with:

  • The common pair of AWS security credentials (an AWS Access Key Id and an AWS Secret Key) is entered directly in each task and persisted after being processed with the Bamboo EncryptionService API.

Please note that the Bamboo EncryptionService API naming is misleading for the time being - as properly phrased in the method summary of com.atlassian.bamboo.security.EncryptionServiceImpl, the decrypt()/encrypt() methods just provide means to obfuscate sensitive data.

💡Real encryption is available by using the integration with Identity Federation for AWS (Bamboo) instead.

Support for temporary credentials

As of Tasks for AWS 2.14.1, you can also specify an optional session token via a Bamboo variable to support advanced scenarios where temporary AWS credentials can be retrieved from sources not directly supported yet (e.g SAML - refer to https://utoolity.atlassian.net/browse/UAA-267 for details):

  • In a preceding task, prepare a Bamboo variable to provide the session token at execution time, for example ${bamboo.awsSessionTokenPassword}

  • Check Provide Session Token Variable

  • Specify the Session Token Variable that is providing the session token at execution time.

If you prefer this solution, you might still want to ease credentials reuse via variable substitution as follows:

  • configure Access Key and Secret Key as e.g. ${bamboo.awsAccessKeyPassword} and ${bamboo.awsSecretKeyPassword}

  • define plan and/or global variables for the configured variable names (i.e. awsAccessKeyPassword and awsSecretKeyPassword given this example) with the actual credentials, which will then be substituted on task execution accordingly

AWS China Regions

The AWS China (Beijing) Region is an API compatible, but otherwise isolated AWS Region designed to allow China-based and multinational companies to make use of a broad collection of AWS services while remaining in compliance with China's legal and regulatory requirements.

Support for regions in the AWS China partition is an opt-in Labs Feature:

  • The AWS China partition provides the following regions: China (Beijing) – cn-north-1 / China (Ningxia) – cn-northwest-1

  • This partition requires dedicated credentials, see Announcing the AWS China (Beijing) Region: "Customers who wish to use the new Beijing Region are required to sign up for a separate set of account credentials unique to the China (Beijing) Region. Customers with existing AWS credentials will not be able to access resources in the new Region, and vice versa."

  • Due to being a non China-based company, we are not currently in the position to test this app with the AWS China regions directly. However, the API is compatible in general and this app should just work accordingly - please get in touch if things do not work as intended, we are very interested to collaborate on the necessary adjustments.

AWS GovCloud (US) Regions

The AWS GovCloud (US) Region is an API compatible, but otherwise isolated AWS Region designed to allow US government agencies and customers to move sensitive workloads into the cloud by addressing their specific regulatory and compliance requirements).

Support for regions in the AWS GovCloud (US) partition is an opt-in Labs Feature:

  • The AWS GovCloud (US) partition provides the following regions: AWS GovCloud (US-East) – us-gov-east-1, AWS GovCloud (US) – us-gov-west-1

  • This partition requires dedicated credentials, see How do Government agencies, contractors and customers access the AWS GovCloud (US) Region?: "Customers cannot sign up for AWS GovCloud (US) through the traditional, online AWS sign up process. AWS must engage with the customer directly to sign an agreement specific to the AWS GovCloud (US) Region. [...]"

  • Due to being a non US company, we are not currently in the position to test this add-on with the AWS GovCloud (US) Region directly. However, the API is compatible in general and we have done our best to address the documented differences - please get in touch if things do not work as intended, we are very interested to collaborate on the necessary adjustments.

  • No labels