Assume Role Support? about aws-toolkit-azure-devops

[hunterwerlla]

I think the comment was deleted for some reason, but opened issue #291 which captures that the AWS CLI task does not assume role.

[stevejroberts]

The AWS service endpoint is currently written to use just a single access/secret key pair so this isn't possible at the moment. It's on our backlog to add in a future release.

[cameronattard]

I should also add we'd like to be able to use the instance profile of the agent to assume roles.

[stevejroberts]

Ok.

A first pass at assume role support was released yesterday (v1.0.10); all tasks except for the AWS CLI and Lambda .NET Core Deployment are now able to handle having the role to assume be specified in the AWS endpoint type (the two remaining tasks will be updated soon). Interested in feedback!

For the agent using instance profile, are you envisaging the agent running in the scope of a role (ie it's already assumed and the same role is used in all tasks) or are you looking for the ability to take the credentials from the profile and use them in conjunction with a different role arn specified somewhere in the build or endpoint, so tasks can assume different roles?

[cameronattard]

Thanks so much for such a quick turnaround on that!

I think ideally we'd like it so if you don't specify any API credentials in the service endpoint, it'll fall back to the instance role of the agent. From there you'd be be able to perform any of the existing tasks, including the ability to assume other roles from the instance role.

[stevejroberts]

We'll likely have to introduce a new endpoint type that doesn't have access and secret keys to get this to work, as in the current endpoint these are mandatory. The tasks would then need to detect what kind of endpoint they received and behave accordingly. It could also of course contain role data to allow use of instance profile credentials to assume a different role.

[melih154]

Hi @steveataws

Does "AWS Lambda .NET Core Deployment" task supports assume role? I think not, tested with below scenarios. I think it is required for users who is trying to setup suggestions done on AWS Landing Zone using VSTS and dotnet lambda global tool.

Scenario 1
Steps:

1. Set up Service Connection with Access Key ID, Secret Access Key and Role To Assume
2. Add S3 Upload Step, to make sure issue is not regarding IAM user or S3 Bucket policies - Worked.
3. Add "AWS Lambda .NET Core Deployment" task - Failed. Error message: The AWS Access Key Id you provided does not exist in our records.

Scenario 2
Steps:

1. Included below command line arguments on "AWS Lambda .NET Core Deployment" task - Worked.
   --aws-access-key-id $(AWSAccessKeyID) --aws-secret-key $(AWSSecretKey) --aws-session-token $(AwsSessionToken)
   Ps. Retrieved those tokens from local .aws\cli\cache folder.

Scenario 3
Steps

1. Setup the assume role profile on AWS CLI on my local machine.
2. Run below command - It worked.
   dotnet lambda package-ci -ot serverless.template --region *** --s3-bucket *** --disable-interactive true --profile build

What we are trying to achieve?
As suggested on AWS Landing Zone, have Identity(IAM Users ) and Build(S3 Buckets for Lambda packages) AWS accounts. vsts-build user should assume role on Build account to PutObject to S3 Bucket, which stores Lambda Deployment packages.

[jeffrey-opdam]

@hunterwerlla any progress on this?

[hunterwerlla]

The letter of this issue is that that all tasks support assume role, which they do now. There seems to be discussion about other feature requests on this ticket, so please file them as different tickets if you are still having issues/have a different feature request.

[Slooz]

@hunterwerlla, yes, sorry about that. I wasn't sure if my comment was accurate. Glad to see that you opened an issue for it.