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 14 Current »

Labs features are giving you a sneak preview of new features coming in future releases of Identity Federation for AWS. You can enable/disable each feature individually at any time.

Please note that Labs features represent work-in-progress and are not officially supported by Utoolity. They may be incomplete, or may change before being incorporated into the product (some Labs features may never be incorporated into the product).

That being said, Labs features allow us to gather feedback on "work-in-progress" features to help us improve them - please get in touch for any issues, questions or suggestions you might have.

On this page:

Enable AWS China partition (experimental)

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.


Enable AWS GovCloud (US) partition (experimental)

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 app 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.

Disable implicit connector visibility for administrators (experimental)

By default, administrators can always edit, see and use all connectors, whereas visibility and usage of connectors in the 'AWS Resources' menu, the connector selection widget, and via the REST API is scoped to the selected groups for all non administrators to allow the delegation of temporary AWS credentials retrieval.

While this behavior properly reflects the security barriers in the Atlassian Server universe (where administrators are generally able to get access to all data one way or another), it turns out to be a usability flaw for scenarios where many users have been granted administrative rights to overcome insufficient permission granularity in the host product (e.g. Bamboo before the permission changes introduced in release 6.2) - as a preliminary workaround, this feature flag allows to change the default behavior as follows:

  • by default, members of the administrator group (e.g. bamboo-admin) will not be able to see and use any connectors via the REST API or dependent resources like the 'AWS Resources' menu and the connector selection widgets anymore, except if explicitly being granted access by including the resp. group within the Groups selection 

  • regardless, members of the administrator group (e.g. bamboo-admin) will still be able to edit all connectors via the configuration screen

No security barrier

This change mostly comprises a usability improvement, but not an impenetrable security barrier, because administrators can still grant themselves access to connectors at any time simply by adjusting the connector to group associations or their own group membership etc.!

Refer to https://utoolity.atlassian.net/browse/UAA-298 for more details regarding the relation of this preliminary workaround to more far reaching possible changes to Identity Federation for AWS permission granularity in future release.

Enable connector management by restricted administrators

By default, only system administrator can configure AWS connectors, but you can also enable connector management by restricted administrators. This is the first step in our journey to move AWS credentials management into user space while retaining tight administrative control where desired.

Enable IAM role for EC2/ECS credentials provider (experimental)

If you have provisioned your Atlassian workloads on Amazon EC2 (for example via the Atlassian Data Center on AWS Quick Starts), Amazon ECS, or AWS Fargate, you can benefit from the convenience and flexibility of providing AWS security credentials via IAM roles for Amazon EC2 instances and IAM roles for Amazon ECS tasks by enabling the IAM role for EC2/ECS credentials provider.

Security assessment

The convenience of IAM roles for Amazon EC2 instances have the downside of a less explicit security posture and more indirect regression potential, as further outlined in https://utoolity.atlassian.net/browse/UAA-49 . The feature currently requires an opt-in accordingly, and we also recommend the principal type 'Assume Role' rather than 'Provided' to gain the actual permissions via another role instead of the one directly attached to the EC2 instance. Either way, please make sure you have thoroughly assessed the security configuration of your underlying EC2 instance(s) and the attached or assumed IAM roles.

Feature flag status

We are committed to fully support this feature going forward, which is the first exploratory step in our journey to offer more choices and flexibility in providing AWS security credentials via a dedicated SPI. However, due to requiring architectural changes, we are releasing an opt-in early version as a labs feature so that we can provide it sooner and gather feedback around usability and security questions before bringing it front and center to all customers. Please provide feedback via the built-in Jira integration, or contact us us directly.


  • No labels