Assume AWS role when executing AWS API

[neowulf]

The shared role doesn't get assumed when executing the following:

sbt -DAWS_DEFAULT_PROFILE=shared ecr:createRepository

I have the following in my aws files:

[default]
aws_access_key_id = xxx
aws_secret_access_key = yyy

[shared]
aws_access_key_id = xxx
aws_secret_access_key = yyy

[default]
output = json
region = us-west-2

[profile shared]
role_arn = zzz
source_profile = default
output = json
region = us-west-2

I see this line in AWS.scala:

...
new ProfileCredentialsProvider(sys.env.getOrElse("AWS_DEFAULT_PROFILE", "default")),
...

Any pointers would be be helpful! I see Thank you!

[neowulf]

In the sbt console, I have confirmed that the system property is being set:

$ sbt -DAWS_DEFAULT_PROFILE=shared console
[info]...
[info]...
scala> System.getProperty("AWS_DEFAULT_PROFILE")
res0: String = shared

scala> sys.env.getOrElse("AWS_DEFAULT_PROFILE", "default")
res1: String = shared

[sjednac]

Hi @neowulf33,

I'm not sure why sys.env.getOrElse("AWS_DEFAULT_PROFILE", "default") returns shared in your context as -D would suggest a JVM system property, not an environment variable as expected by the plugin.

I'm executing my tasks like this:

 AWS_DEFAULT_PROFILE=shared sbt ecr:createRepository

Let me know if that works for you.

[neowulf]

Hi @sbilinski,

Thank you for the tip. Unfortunately, it didn't work as the error message hasn't changed which is:

com.amazonaws.services.ecr.model.AmazonECRException: User: arn:aws:iam::wrong_role is not authorized to perform: ecr:CreateRepository on resource: * (Service: AmazonECR; Status Code: 400; Error Code: AccessDeniedException; Request ID: xxx)

I get the same error when I execute a AWS CLI without providing the correct profile.

[neowulf]

Hi @sbilinski ,

Do you know if the role within the aws profile gets automatically picked up by the AWS Java SDK?

[sjednac]

I'm not sure what could go wrong here, since repository creation is just a direct call to the Amazon SDK. That being said, does it work if you put your shared credentials under the [default] profile and skip the settings completely?

Also, double check if you have a proper policy attached. I'm using the predefined AmazonEC2ContainerRegistryFullAccess, which seems like a good start for development / testing such issues.

[neowulf]

I have pulled the credentials into the [default] profile.

I am able to create a repository without specifying the profile using the AWS CLI SDK:

aws ecr create-repository --repository-name test5

The role doesn't get switched when executing the sbt task, though.

[sjednac]

Do you know if the role within the aws profile gets automatically picked up by the AWS Java SDK?

I suppose the role is inherited from the aws_access_key_id.

I have pulled the credentials into the [default] profile.

Does the sbt ecr:createRepository command work in this context?

[neowulf]

Sorry, no, sbt ecr:createRepository doesn't work in the new context either.

I see that there are other *CredentialsProvider which can assume roles but I don't know enough of the AWS SDK to know about it. I'm looking.

[sjednac]

Credential providers are taken in order, until some value is found.

Maybe you should check if there is no AWS_ACCESS_KEY_ID or AWS_ACCESS_KEY in your environment variables as they will override any profile settings?

Same goes for aws.accessKeyId and aws.secretKey system properties.

[neowulf]

I believe those are getting picked up as evident from the incorrect credentials. However, the role_arn doesn't get "assumed".

[neowulf]

Please see my PR #10 for a fix for this.

[sjednac]

@neowulf33: Given the content of the PR and the comment above, I think the main issue is that you need to assume the role before you run any plugin commands (different responsibility).

For reference:

• AWS Security Blog: How to Implement a General Solution for Federated API/CLI Access Using SAML 2.0
• samlapi_formauth.py

Let me know, if you've managed to resolve the issue.

[neowulf]

Thank you for the references.

However, please note that the generated credentials are short lived and will have to be re-run before executing the AWS commands - which may not be ideal when automating the build process and pushing the docker images to ECR.

1. How is this automated in your project?
2. Does the project use role assumption?

[sjednac]

Assuming that your CI services will run in the cloud, you can assume role on the instance itself and use the InstanceProfileCredentialsProvider, which is already in the credentials provider chain. This is the "standard" way to do it in my project (i.e we deal with security in a very "declarative" way). Short-lived credentials are used for development and manual tasks though.

When running on-premises, I'd probably setup a dedicated AWS user for CI purposes (with a proper Amazon ECR policy) or do exactly what you did, but in a dedicated task (i.e outside of the plugin; maybe even outside of sbt - depends on the situation really).

[michaelgroening]

Hi!
I have exactly this problem atm. Is there any workaround for this or a howto?

[sjednac]

@michaelgroening Try attaching AmazonEC2ContainerRegistryFullAccess to your user account in the IAM panel (for example).