Automation with AWS 1.9

The Utoolity team is pleased to present Automation with AWS 1.9 – this release adds an action to get parameters from the AWS Systems Manager Parameter Store to evaluate remote conditions and inject remote configuration data and secrets. It also adds an IAM role for EC2/ECS credentials provider and introduces namespace and scope handling for generated Bamboo variables.

You can now use the Get Systems Manager Parameter action to evaluate remote conditions so that you can control Jira Service Management automation rules via the Automate with AWS if condition, control Jira workflow transitions via the Automate with AWS workflow condition and Automate with AWS workflow validator, and fail or succeed Bamboo builds and deployments via the Automate with AWS task. You can also use this action to inject remote configuration data and secrets stored as secure parameters in the AWS Systems Manager Parameter Store, or stored as secrets within AWS Secrets Manager. Further, you can now provide AWS security credentials via an IAM role for EC2/ECS when you run your Atlassian products on Amazon EC2, Amazon ECS, or AWS Fargate, and you can adjust the namespace and scope of generated Bamboo variables.

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

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:

• Currently supported integrations are the Bamboo Automate with AWS task.

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.

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:

• An Inside Look at AWS Secrets Manager vs Parameter Store
• AWS Parameter Store vs. AWS Secrets Manager

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 workloads on Amazon EC2, 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, which is bundled and free for Automation with AWS licensees, see the resp. FAQ for details.

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.

Release notes

For more details about this release, please refer to the Automation with AWS 1.9 Release Notes.