Skip to content
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

read_credentials() can't parse nested values #19

Open
kenahoo opened this issue Sep 21, 2017 · 8 comments
Open

read_credentials() can't parse nested values #19

kenahoo opened this issue Sep 21, 2017 · 8 comments
Labels

Comments

@kenahoo
Copy link

kenahoo commented Sep 21, 2017

I have a section in my ~/.aws/credentials file that looks like this:

[devrole]
role_arn = arn:aws:iam::912345678902:role/my-role-dev
source_profile = default
s3 =
    signature_version = s3v4

That fails to parse properly:

> aws.signature::read_credentials()$devrole
$ROLE_ARN
[1] "arn:aws:iam::912345678902:role/my-role-dev"

$SOURCE_PROFILE
[1] "default"

$S3
[1] NA

$`    SIGNATURE_VERSION`
[1] "s3v4"

http://boto3.readthedocs.io/en/latest/guide/configuration.html#configuration-file says that this is a "nested configuration value", but doesn't give much more guidance - I couldn't find the "Nested Configuration section" it mentions. However, this format does get parsed properly by the aws command-line tool itself.

I'm using:

> packageVersion('aws.signature')
[1] ‘0.3.5’
@kenahoo
Copy link
Author

kenahoo commented Sep 21, 2017

By the way - the reason I'm running into this is that I'm trying to use role-based authentication, and running aws.signature::use_credentials(profile = "devrole") is having no effect. I suspect (from looking at the code) that even if the file were correctly parsed, use_credentials wouldn't actually handle role-based profiles like this without some further changes, right?

@kesor
Copy link

kesor commented Oct 10, 2017

@kenahoo I tried a workaround like in the following code snippet, looks like it gets the STS credentials (as it should). My problem with it is that the created signatures from these credentials are incorrect. YMMV

awsNestedProfile <- function(profileName) {
    library(aws.signature)
    library(aws.iam)

    credentials <- aws.signature::read_credentials()[[profileName]]
    aws.signature::use_credentials(profile = credentials$SOURCE_PROFILE)
    aws.iam::assume_role(credentials$ROLE_ARN, "Rsession", use=TRUE)
}

@kesor
Copy link

kesor commented Oct 10, 2017

@kenahoo in most packages, like aws.cloudtrail, aws.iam, etc... the session_token is added to the request after the credentials are parsed. For example in stsHTTP you have the session_token argument default to NULL, and its fine when it is passed like this to signature_v4_auth but it is also used in stsHTTP itself and they are not loading the correct value from locate_credentials.

Long story short, until this is fixed - you probably need to manually pass session_token everywhere.

Example:

aws.iam::get_caller_identity(session_token = aws.signature::locate_credentials()$session_token)

@leeper
Copy link
Member

leeper commented Apr 3, 2018

@kenahoo So, that looks like a config file, not a credentials file. At present, there's no support here for config files. I'm not sure if I'll add them as it introduces a ton of further complexity but I'm open to discussion and PRs.

@kesor
Copy link

kesor commented May 22, 2018

@leeper it is not the config file, it IS the credentials file like @kenahoo specified in his example in the OP.

@leeper
Copy link
Member

leeper commented May 22, 2018

@kesor Can you show me some documentation for this? Neither the official AWS docs nor the boto docs show that these fields are part of credentials. The latter shows that as part of config, though.

@kesor
Copy link

kesor commented May 22, 2018

@leeper for me it just works, probably because aws-cli and boto and other tools just treat ~/.aws/config and ~/.aws/credentials as a single file or something. It doesn't matter in which file I put the profile definitions, just works.

@leeper
Copy link
Member

leeper commented May 22, 2018

Okay. Thanks.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants