Feature Request - Support assume roles and MFA

[andytom]

In #10 you added support for profiles would it be possible to expand support for this to include assume roles and MFA (similar to https://docs.aws.amazon.com/cli/latest/userguide/cli-roles.html) ?

[hypnoglow]

Hi @andytom ,

I will definitely consider implementing this, but could you please describe your use case?
The more details the better, because to release this feature I will need to test that implementation works within some test AWS account.

[andytom]

I will definitely consider implementing this, but could you please describe your use case?
The more details the better, because to release this feature I will need to test that implementation works within some test AWS account.

If someone is using AWS Organizations and have a single account they they use to manage all the IAM user they will need to use assume roles to access resources in other accounts. This blog post from Segment.io explains the multiple AWS account setup in the "Separate AWS Accounts" section. An example would be that assuming that there is a developer who needs to setup his local minikube environment, that user would have an account in the ops account and in order to fetch the helm charts that developer would need to be able to use assume roles to access the prod account that contains the helm-s3 bucket.

MFA is just for security, Amazon recommend the use of MFA devices to increase security (see https://aws.amazon.com/iam/details/mfa/).

Hopefully that explains my use case but please let me know if you want me to expand anything or if anything is unclear please let me know.

[andytom]

@hypnoglow I believe @ConradKurth has done some work relating to switching roles in #24. Would it make sense to create a separate issue to the MFA stuff and keep this issue for the switching roles (I'm not sure how granular you want to get with your issues)?

[ConradKurth]

@andytom So I have updated my PR to allow for MFA token per AWS documentation for you. Let me know if that works for. Also if you would like some more reference, take a look here https://aws.amazon.com/blogs/developer/assume-aws-iam-roles-with-mfa-using-the-aws-sdk-for-go/.

[andytom]

Fixed by #24.

[andytom]

@hypnoglow and @ConradKurth, It seems I may have been a little bit hasty in closing this. I have been doing some testing with the new version and found a few issues:

• Timeouts - The context timeout includes the time taken entering of the MFA token so if you take too long to enter the MFA code it will timeout. This seems to be relatively minor and could be fixed by increasing the default timeout.

helm s3 init s3://example-s3-bucket/charts
Assume Role MFA token code: 123456
2018/01/10 17:34:06 upload index to s3: upload index to S3 bucket: RequestCanceled: request context canceled
caused by: context deadline exceeded

• No MFA prompt - When using the proxy method there is no prompt for the MFA code, this might be because of the way that helm is calling the plugin because if you call the helms3 binary directly it does prompt. However I'm not sure how you would go about fixing this.

helm repo add example s3://example-s3-bucket/charts
2018/01/10 17:42:02 fetch from s3: fetch object from s3: EOF
Error: Looks like "s3://example-s3-bucket/charts" is not a valid chart repository or cannot be reached: plugin "bin/helms3" exited with error

$(helm home)/plugins/helm-s3.git/bin/helms3 certFile keyFile caFile s3://example-s3-bucket/charts/index.yaml
Assume Role MFA token code: 123456
apiVersion: v1
entries: {}
generated: 2018-01-10T16:58:45.608539Z

[hypnoglow]

@andytom @ConradKurth

Timeouts - The context timeout includes the time taken entering of the MFA token so if you take too long to enter the MFA code it will timeout. This seems to be relatively minor and could be fixed by increasing the default timeout.

I think that increasing timeout is not an option. What is a reasonable timeout for a user with MFA enabled? It can take quite a time for him in some cases to get the code.

We either have to

• a) refuse interactivity and pass the code as a flag like helm s3 push --mfa-token-code
• b) or remove the timeout completely even from not mfa-enabled requests (because we delegated all the creds job to the AWS library itself, and we cannot distinguish auth details from the plugin code anymore).

No MFA prompt - When using the proxy method there is no prompt for the MFA code, this might be because of the way that helm is calling the plugin because if you call the helms3 binary directly it does prompt. However I'm not sure how you would go about fixing this.

I've tried to fix this by using stderr instead of stdin-stdout, and it worked 😳 But we need to decide what to do with the problem above, because the a) solution will not work with this proxy method, as helm commands do not support any third-party flags:

$ helm repo add hypnoglow2 "s3://hypnoglow-charts" --mfa-token-code
Error: unknown flag: --mfa-token-code

So, I guess, we are forced to remove the timeouts completely because there is no other way to make MFA happy?

[andytom]

I've tried to fix this by using stderr instead of stdin-stdout, and it worked 😳 But we need to decide what to do with the problem above, because the a) solution will not work with this proxy method, as helm commands do not support any third-party flags:

Ah that would make sense, I've just read the plugin downloader docs and helm must be capturing the prompt as part of the output.

We could increase the timeout to a few minutes, that would give someone plenty of time to enter an MFA code and still keep the timeout for things like CI systems.

[hypnoglow]

I've set a timeout of 5 minutes (helm default timeout in actions like helm install is 5 minutes, so let it be), also I think MFA for a proxy action is fixed, at least I tested and it works for me.

[andytom]

@hypnoglow I've given the PR a bit of testing and it works great 👍. Thanks for the hard work.

[viennewan]

What I did is

1. Set your assumed role profile in ~/.aws/credentials
2. aws sts assume-role --role-arn arn:aws:iam::1234567890:role/your-assumed-role-name --role-session-name "your-role-session-name" --profile your-assumed-role-profile > assume-role-output.txt
3. You will need the info in the assume-role-output.txt for following steps
4. export AWS_REGION=region-of-your-bucket
5. export AWS_ACCESS_KEY_ID=your-AccessKeyId
6. export AWS_SECRET_ACCESS_KEY=your-SecretAccessKey
7. export AWS_SESSION_TOKEN=your-SessionToken

It works for me. Hopefully save a lot of time for people who encounter the same problem. :)))))