-
Notifications
You must be signed in to change notification settings - Fork 1.2k
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
Aws::SharedCredentials does not appear to respect the source_profile option #1256
Comments
If you're setting To be clear, which failure mode are you seeing?
I'm going to suspect 2, but want to be sure so I'm checking the correct use case. |
Actually wait, I'm sorry, I misunderstood. I was looking at the behavior of the default credential provider chain, your example is something different. In your file above, you're not using the Shared Config logic for assuming a role, you're calling Is the script above the exact (or approximate) script you're trying to debug? |
Thinking some more about this, I believe what I am seeing is that there seems to be no way to pass credentials parsed from the config file using But I would like to essentially be able to construct a SharedCredentials instance, which then can be used by The use case here is that I am building a wrapper for another product that does not support STS. So I am obtaining the temporary credentials from the target STS role, using whatever local credentials that are specified under a profile in the config file. I am then getting those credentials, and passing them along to a new sub-process using environmental variables. I hope this helps to clarify my issue/request. |
Another way I have tried this: credentials = Aws::SharedCredentials.new("config_profile_name")
sts = Aws::STS::Client.new(credentials: credentials)
sts.assume_role({ role_arn = "ARN", role_session_name = "Session"}) This resulted in the following error: The error only occurs when I specify a CLI profile that sources credentials from another CLI profile. E.g. 'default' profile has actual API keys in the credentials file. Other CLI profiles use the source_profile directive to reference those credentials. They don't themselves have API keys, only the role_arn parameter and region is specified. So the root of my problem, other than my trial-and-error programming approach, seems to be the fact that Aws:SharedCredentials does not seem to load the credentials from source_profile, unlike the CLI. My setup is pretty vanilla, as it follows the example listed in AWS docs:
|
Is there any reason not to just use the default credential provider chain? For your example above, if you ran Ruby with the ENV variable already set (not set in code), this should work: client = Aws::S3::Client.new(profile: "account2", region: REGION) Substitute S3 for whichever client you need. This will follow the config resolution path for AssumeRole, and will provide automatically refreshed credentials. |
Thanks so much for the continued assistance! I tried the example you have provided in aws.rb. It does appear to work, as long as the environmental variable is set, and MFA is not required. Could you provide a quick example of how I would make this work with MFA? Here's what I tried:
When initializing a new STS client, there is nowhere to provide the token_code. Again, my use case here is that I need to export raw access_key_id, secret_key and session_token from assumerole, so that I can pass it onto an app that does not support profiles/STS. |
Starting with the base class used by this system: Let's say you wanted to assume a given sts_client = Aws::STS::Client.new(profile: 'account1', region: REGION)
credentials = Aws::AssumeRoleCredentials.new(
client: client,
role_arn: role_arn,
role_session_name: "mysession",
serial_number: mfa_serial,
token_code: token_code
)
s3_client = Aws::S3::Client.new(credentials: credentials, region: REGION) If you start from the basic usage pattern, sourcing values from config is a matter of parsing that config source. Currently, the method used by the default chain is behind a private API, so I can take it as a feature request to expose a method to directly create an MFA Assume Role call with config values. |
OK, I think we finally got to the bottom of my request. Sorry if I haven't done a good job explaining this. Looks like in the meantime I will be forced to implement my own parser for the config (or some other way to supply all of the STS parameters) to make this easy for the users. |
the suggested AssumeRoleCredentials code works for me. I use this for reading credentials and config: and STDIN.get.chomp to read in the token_code |
Added to feature request backlog. |
Reopening - deprecating usage of Feature Requests backlog markdown file. |
This does not respect the following as well.
This is because of how the This method only contains the following code:
This method should be updated to check to support all role_arn and both source_profile |
It is an AWS bug, as stated in this closed issue - dtan4#235 Indeed, it is an old one - aws/aws-sdk-ruby#1256, let's temporarily fix it here with this PR.
I believe this has been fixed with PR #2223 - and you should be able to pass profile when creating a client and the credential resolution chain will correctly use I'm going to close this out but feel free to re-open if this doesn't fix the underlying issue for you. |
Example of ~/.aws/config
[profile account1]
region = us-east-1
[profile account2]
role_arn = arn:aws:iam::XXXXX:role/STSRole
source_profile = account1
mfa_serial = arn:aws:iam::XXXXX:mfa/adminuser
Example of ~/.aws/credentials
[account1]
aws_access_key_id = XXX
aws_secret_access_key = XXX
Expected behavior:
Aws::AssumeRoleCredentials
uses credentials of the IAM user in account1, in order to assume STS role in account2.What Actually happens:
Aws::AssumeRoleCredentials
uses the default credentials to assume the STS role in account2. This fails due to lack of access.Either
Aws::SharedCredentials
does not respect the source_profile directive, or Aws:AssumeRoleCredentials does not use theSharedCredentials
object to obtain it's access key (possibly both).So this issue might include a hidden request for
AssumeRoleCredentials
to support passing it an instance ofSharedCredentials
, instead of passing it the role_arn manually. Currently, I am parsing the ~/.aws/config file manually and extract role_arn from there.Sample Ruby snippet:
The text was updated successfully, but these errors were encountered: