-
Notifications
You must be signed in to change notification settings - Fork 65
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Roles are not supported #54
Comments
@joshdholtz, is this issue resolved by PR #86? I will try to test myself, but don't have an environment setup at the moment. I have doubts as I thought Instance profiles were for EC2. If my understanding is correct, then shouldn't PR #86 have introduced a boolean flag to indicate whether to use InstanceProfile or not. If false and no other s3_* flags are set then the credentials would be resolved from the environment, which is what I am proposing in this ticket / PR #55 |
@timothy-volvo I’ll take a deeper look today! I thought it did but I will make sure. |
#86 still won't resolve this. As an example, using AWS uses some non-trivial logic to initialize a session, so unless this plugin is doing something special or custom to initialize the session, I would strongly suggest using the default credential provider chain as the default if you don't specify explicit credentials instead of using Here's the source to what the credential chain tries to do: It includes:
|
I wonder if we can simply add a option variable for AWS_SESSION_TOKEN to use I touched up the code a little and it looks working fine for my case:
|
The way the client is being instantiated, the role_arn is being ignored from the config/credentials file. According to a comment in issue 1256 of the aws-ruby-sdk, it appears the recommended way of instantiating a client is to pass the options in as a hash and let the SDK work out the security configuration.
For example:
Here is a sample ~/.aws/credential
I will create a PR
The text was updated successfully, but these errors were encountered: