Highlights (Core)
Evaluate remote conditions with the Get Systems Manager Parameter action
You can now use the Get Systems Manager Parameter action in applicable integrations to evaluate arbitrary remote conditions by persisting a JSON result shape that adheres to the action response format schema:
{ 'result': false, 'errorMessage': "Workflow transition blocked due to a prerequisite condition being false" }
This allows you to use an event-based architecture to decouple condition evaluation in AWS from condition evaluation in Atlassian to ensure that any prerequisites for your workflows are automatically checked right before dependent steps are initiated, thereby reducing cost and latency over using the Invoke Lambda Function action to synchronously call AWS services and third-party REST APIs at evaluation time.
Currently supported integrations are the Jira Service Management Automate with AWS if condition, the Jira Automate with AWS workflow condition and Automate with AWS workflow validator, and the Bamboo Automate with AWS task.
Inject remote configuration data and secrets with the Get Systems Manager Parameter action
You can now use the Get Systems Manager Parameter action in applicable integrations to inject arbitrary remote configuration data and secrets via the Systems Manager Parameter Store:
This allows you to maintain configuration data and regular secrets as (secure) parameters in the Systems Manager Parameter Store, and optionally maintain secrets in AWS Secrets Manager when you require more advanced secret lifecycle management.
Parameter Store vs. Secrets Manager
Depending on your use case and security governance requirements, you can store secrets as Parameter Store parameters of type SecureString
, or as actual Secrets Manager secrets as outlined in Referencing AWS Secrets Manager secrets from Parameter Store parameters. The following articles provide a comparison between the two services:
Currently supported integrations are the Bamboo Automate with AWS task.
Provide AWS security credentials via an IAM role for EC2/ECS
You can now enable the IAM role for EC2/ECS credentials provider via a feature flag. If you have provisioned your Atlassian product on Amazon EC2 (for example, via the Atlassian Data Center on AWS Quick Starts), Amazon ECS, or AWS Fargate, you can now 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.
This feature is provided by Identity Federation for AWS (Bamboo), which is bundled and free for Automation with AWS licensees, see the resp. FAQ for details.
Security assessment
The convenience of IAM roles for Amazon EC2 instances has 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 via a feature flag 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
LABS FEATURE
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 directly.
Highlights (Bamboo)
Adjust generated Bamboo variable namespace and scope
Similar to the Inject Bamboo variables task that has been included with Bamboo as of release 6.7, you can now specify the namespace and scope for Bamboo variables generated by the Automate with AWS task to enable more flexible build orchestration. You can now pass a variable between stages, pass a variable from a plan to a deployment project, and you can use multiple tasks within the same job without overriding variables from preceding tasks by adjusting the namespace. The task defaults to the preceding behavior with local
scope and a custom.aws
namespace so that this remains an opt-in choice for advanced use cases.
Resolved issues
Release 1.9.0
2020-11-30
This release addresses the following issues:
Core
Stories
AAWS-731 – As a user, I want to get a Systems Manager (SSM) parameter so that I can inject remote data
AAWS-739 – As a user, I want to get a Systems Manager (SSM) parameter so that I can check remote conditions
Jira
Tasks
AAWS-759 – Drop support for Jira 7.9
AAWS-764 – Drop support for Jira 7.10
AAWS-802 – Drop support for Jira 7.11
AAWS-805 – Drop support for Jira 7.12
Bamboo
Stories
AAWS-814 – As a user, I want to be in control of variable namespace and scope so that I gain simplified plan composition
Tasks
AAWS-760 – Drop support for Bamboo 6.5
AAWS-799 – Drop support for Bamboo 6.6