Support for the credential_process feature of the AWS Shared Config?

[lorengordon]

Have folks here thought about implementing support for the credential_process feature of the AWS Shared Config? I didn't see any docs or issues or PRs about it, so figured I'd ask. It's been supported in the AWS SDK for GO since v1.16.0. Basic idea is that you would be able to execute aws "normally" and its credential chain would execute aws-okta to retrieve credentials.

More info:

• https://docs.aws.amazon.com/cli/latest/topic/config-vars.html#sourcing-credentials-from-external-processes
• https://docs.aws.amazon.com/sdk-for-go/api/aws/credentials/processcreds/

[nickatsegment]

That sounds pretty rad. I wasn't aware of such a feature. Looks like aws-vault has it/is working on it.

[llamahunter]

See also https://github.com/oktadeveloper/okta-aws-cli-assume-role. Supports credential_process,
but it's written in java.

[smiller171]

I'm only just learning about this for the first time myself and now I NEED it. I'm probably gonna end up writing a wrapper around env that supplies the json. Unfortunately don't understand Go well enough to confidently contribute directly.

[wilsonjackson]

I needed this for my org, too, so I started with the simplest possible wrapper: an inline credential_process that used aws-okta exec and output the variables in the expected JSON format.

credential_process = aws-okta exec okta-saml -- sh -c 'echo "{\"Version\":1,\"AccessKeyId\":\"$AWS_ACCESS_KEY_ID\",\"SecretAccessKey\":\"$AWS_SECRET_ACCESS_KEY\",\"SessionToken\":\"$AWS_SESSION_TOKEN\",\"Expiration\":\"`date -u -v+15M +"%Y-%m-%dT%H:%M:%SZ"`\"}"'

This works fine for the basic case, but if you require MFA (e.g. with Google Authenticator), the interactive prompt doesn't really agree with the way the credential process is executed from the AWS SDK. We frequently use both awscli and kubectl with aws-iam-authenticator, and both exhibited issues. (Weirdly, different ones.)

To work around this I made this bash script wrapper: https://gist.github.com/wilsonjackson/2ec2a6f5c5330bf1207daef3306fbd74

It's for Mac only, as it uses AppleScript to raise a GUI prompt for an MFA code when it detects a challenge, which prevents it from disrupting the calling process. Works well with both awscli and kubectl/aws-iam-authenticator.

The only thing I'm not certain about (with both of the above workarounds) is what, exactly, to set for Expiration, so I went with 15 minutes in the future. So far it's been fine.

I'd love to see the JSON output handled natively by aws-okta, especially since it would have a better idea of what to set for Expiration.

[lorengordon]

@wilsonjackson Is there an issue on the aws-sdk-go for the issue you encountered with the interactive prompt? Our team contributed the initial credential_process support to the sdk, so we might be able to put an eyeball on it and get it fixed. Some kind of sample code/script demonstrating the problem would help...

[wilsonjackson]

@lorengordon I didn't open an issue, and didn't see an existing one. Based on problems being present with both aws-sdk-go and botocore, I figured it was my own problem to solve for the foreseeable future.

A simple repro would be just enabling an OTP-based factor on an Okta account and using aws-okta as your credential process. If you can't enable MFA you could fake it with a wrapper like this:

#!/usr/bin/env bash

echo "Enter your fake MFA code: "
read code

aws-okta exec okta-saml -- sh -c 'echo "{\"Version\":1,\"AccessKeyId\":\"$AWS_ACCESS_KEY_ID\",\"SecretAccessKey\":\"$AWS_SECRET_ACCESS_KEY\",\"SessionToken\":\"$AWS_SESSION_TOKEN\",\"Expiration\":\"$(date -u -v+15M +"%Y-%m-%dT%H:%M:%SZ")\"}"'

Interestingly, in putting that simple repro together I believe I discovered at least part of the issue: whereas aws-okta emits the initial "Requesting MFA" message via stderr, the "Enter MFA Code:" prompt comes via stdout, so it's picked up by credential_process and interpreted as invalid json.

However, another issue is that when run through credential_process none of the prompt output makes it to the user, so they can't even tell they're being prompted.

[lorengordon]

@wilsonjackson Ahh, yes, ok, so the stderr response is swallowed by the awscli, which is a known issue in botocore. Can I ask that you comment/upvote on the corresponding issue/pr? It's been a long-standing problem with no movement from the aws devs, but maybe with more eyeballs/activity, we can get it moving!

• Issue: credential_process should connect subprocess stderr to caller stderr boto/botocore#1348
• PR: #1348 - map subprocess stderr to caller stderr boto/botocore#1349

[lorengordon]

the "Enter MFA Code:" prompt comes via stdout

Also, should that part be considered a bug in aws-okta???

[wilsonjackson]

I'd say it's a normally benign behavior in aws-okta that becomes a bug when used in a credential_process context. 😄 I'd certainly like to see it fixed as part of a broader credential_process support PR. I wish desperately I had the time to submit that PR, but unfortunately I don't.

[ryanking]

I would love to work on this feature, but am still learning about how aws + saml + aws-okta work.

Thanks to the comments here, I got this working in the hacky way for myself for now, but am working if I am missing something to make this simpler.

Here's what I have in my ~/.aws/config:

# for initial login in credentials_process
[profile okta-profile]
role_arn = arn:aws:iam::123:role/okta-login
aws_saml_url = ...

[profile default]
credential_process = aws-okta exec --mfa-duo-device u2f okta-profile -- aws_vault_credential_process # <- from @wilsonjackson 's comment

# for use with cli
[profile id]
role_arn = arn:aws:iam::123:role/admin
source_profile = default

# for using aws-okta login ...
[profile id-login]
role_arn = arn:aws:iam::134:role/admin
source_profile = okta-profile

Is there a way to avoid two separate entries for use with the cli and browser login? I haven't been able to find a way to simplify this.

[eexit]

Hello here,

I pushed a PR. Would you mind reviewing it and 👍 it so it could get merged?

Thanks!