Updates to the AWS Tools for Visual Studio Team Services

Today we released version 1.1.0 of the AWS Tools for Microsoft Visual Studio Team Services (VSTS). This version includes new tasks, updates to existing tasks, and a change to how AWS credentials and region are handled by the tasks to make using them easier and more convenient. In this post, we’ll take a brief look at the changes, starting with the updates to credentials and region handling.

Setting credentials and region for tasks

In previous releases, you had to configure each task for credentials by using one or more Team Services endpoints of type AWS. A service endpoint defines a named set of AWS access and secret key data (or optionally, credentials based on an assumed role), which is very similar to how our AWS SDKs and other tools define credential profiles. When configuring a task, the endpoint was then referenced by name in the AWS Credentials field. This field was a required element when configuring a task.

Feedback from users was that needing to manage and use service endpoint instances was a problem for them. They wanted more flexibility for specifying credentials. In some cases, users wanted to generate temporary credentials from their own in-house federated credential mechanisms, and inject the credentials into the build process using their own custom tasks at build time.

We’re pleased to announce that in the version 1.1.0 release, we’ve expanded on the mechanisms you can use to supply credentials to tasks. Setting the name of an endpoint into the AWS Credentials field for all tasks is now optional (you can, as before, continue to supply the name of a service endpoint containing credentials if you wish). But now you can also supply credentials using Team Services build variables and environment variables in the build agent process. In addition, if your build hosts are running on Amazon EC2 instances that were started with an instance profile associated with a role, tasks can obtain credentials from the EC2 instance metadata.

The following is the full set of options that you can use to supply credentials for tasks, in the order in which tasks search for credentials:

• By configuring the name of a service endpoint, of type AWS, in the AWS Credentials field when setting up the task (this is preexisting behavior).
• By creating Team Services variables AWS.AccessKeyId, AWS.SecretAccessKey, and optionally AWS.SessionToken to the credentials to be used.
• By setting the standard AWS environment variables (AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, and optionally AWS_SESSION_TOKEN) in the build agent process that is running your build or release pipeline.

When no credentials are found using the above sources, the tasks will automatically attempt to obtain credentials from EC2 instance metadata. Obviously, this works only if the build host is an Amazon EC2 instance! For more information about using instance metadata to supply credentials on Amazon EC2 instances, see Using an IAM Role to Grant Permissions to Applications Running on Amazon EC2 Instances.

Similarly to credentials, in previous releases of the tools you also had to configure tasks with an AWS region. With this update we’ve increased your flexibility to supply this data, first by also making the field optional when configuring the task, and then by adding the ability for the tasks to obtain the region data they need from their running environment.

The following is the set of options that you can now use, in order, to specify the region that tasks should operate against:

• By configuring the region in the AWS Region field when setting up the task (preexisting behavior).
• By creating a Team Services variable, AWS.Region.
• By setting the standard AWS environment variable AWS_REGION in the build agent process that is running your build or release pipeline.

Just as with credentials, tasks can also fall back to attempting to determine the AWS region they should operate in from EC2 instance metadata, if the build host is an Amazon EC2 instance and if no region data can be sourced from the inputs above.

We’ve made one other user-requested change of note to the AWS Region field when configuring tasks. In previous releases, you needed to enter the region code (us-east-1, us-west-2, etc.) of the region you needed into the field. Now the field supports a drop-down list of regions, and also offers the ability to enter the code of a region that’s not listed. Just like our AWS SDKs, this means you don’t need to wait for the tools to be updated when a new AWS region becomes available. Instead, you can simply start using the new region right away.

New tasks

The version 1.1.0 update also contains some new tasks for AWS Systems Manager and AWS Secrets Manager, and also a new user-requested AWS Shell task, as follows.

AWS Systems Manager Set Parameter task

To complement the existing task that you use to retrieve the values of one or more parameters from the AWS Systems Manager Parameter Store, you can now also create or update a parameter by using the new Set Parameter task. You can create or update  parameters with values that are a simple string or string list (a comma-delimited set of strings). You can also update secure string parameters if you are, for example, rotating secrets. Note that when updating a parameter that is of a secure string type, the parameter type field in the task configuration is ignored. The task detects that the existing parameter is a secure string and updates it to retain the secure string type.

AWS Secrets Manager Create/Update Secret and Get Secret tasks

AWS Secrets Manager is a service that helps you to securely encrypt, store, and retrieve credentials for your databases and other services. Two tasks have been added to enable you to create and update secrets held in the service, and retrieve a secret’s value into a Team Services variable that other tasks in your build can then use. Just like handling secure string parameter types in the Systems Manager Get Parameter task, the new Get Secret task creates a secret Team Services variable. When creating or updating a secret, you can specify the value for the secret as binary or text, and supply the value either inline in the task configuration or from a file.

AWS Shell

The new AWS Shell task enables you to run a script in a Bash shell that is automatically configured with AWS credentials by using the standard AWS environment variables for credentials. You can specify the script inline in the task configuration or from a file. This enables you to run multiple AWS CLI commands within a single task or to run other tools that understand AWS credentials held in environment variables from a shell script. Note that when running AWS CLI commands, or other tools, you need to preinstall them onto the build host that will run your script.

Updates to existing tasks

We’ve also addressed some user feature and pull requests on existing tasks.

The AWS CloudFormation Create/Update Stack and AWS CodeDeploy Deploy Application tasks now support a new timeout option, expressed in minutes. This update was requested by users whose stack creation or application deployments needed more than the default 30 minutes to complete. Create/Update Stack also supports an option to ignore the “no work was done” warning that is displayed in the task logs when the service determines on a stack update, with or without a change set, that no resources need to be changed. In the new VSTS UI displaying this warning message to the logs causes the build or release phase to show has having an issue which for some users was not appropriate. By toggling this option off the specific warning is not emitted. The default behavior is to emit the warning.

We’ve updated the AWS Lambda .NET Core Deployment task so that you can now use it in package-only mode in a build pipeline, allowing the release pipeline to perform the actual deployment. Depending on whether you are working with a Lambda function or a serverless application, in package-only mode the task emits either the ZIP file of the function code as the built artifact, or uploads the ZIP file to Amazon S3 and updates the CodeUri property in the serverless template file to point to the S3 object. The updated template then becomes the built artifact from the task. Using the general-purpose Lambda Deployment task or the AWS CloudFormation Create/Update Stack task in your release pipeline, you can then deploy the Lambda function code or serverless template. A full walkthrough of both of these packaging and deployment steps for functions and serverless applications will be the subject of our next blog post.

And finally…we’ve updated the general-purpose Lambda Deployment task to add support for the .NET Core 2.1 runtime. We’ve also made the field editable so in the future, as new runtimes are added to AWS Lambda, you don’t need to wait for an update to the tools to start working with the new runtime straightaway.

Summary

We hope you enjoy the new flexibility for credentials and region handling for the tools, and the enhancements and additions to the tasks. As always, we welcome questions, feedback, feature requests and pull requests in the GitHub repository for the tools.