Add support for process-based credential providers #1316
Conversation
Codecov Report
@@ Coverage Diff @@
## develop #1316 +/- ##
===========================================
+ Coverage 98.1% 98.11% +<.01%
===========================================
Files 46 46
Lines 7608 7644 +36
===========================================
+ Hits 7464 7500 +36
Misses 144 144
Continue to review full report at Codecov.
|
| @@ -474,8 +705,79 @@ def _extract_creds_from_mapping(self, mapping, *key_names): | |||
| return found | |||
|
|
|||
|
|
|||
| class ProcessProvider(CredentialProvider): | |||
There was a problem hiding this comment.
We should probably work to get a canonical name added for this provider (though I don't think it should block the merge).
JordonPhillips
force-pushed
the
process-provider
branch
from
1221ae5 to
b4ffe0f
Compare
This allows credentials to be sourced by running an external process.
JordonPhillips
force-pushed
the
process-provider
branch
from
07d3a03 to
c67182f
Compare
| @@ -82,6 +84,8 @@ def create_credential_resolver(session): | |||
| creds_filename=credential_file, | |||
| profile_name=profile_name | |||
| ), | |||
| ProcessProvider(profile_name=profile_name, | |||
There was a problem hiding this comment.
Can the ProcessProvider take precedence over the SharedCredentialProvider or would this cause issues?
I can submit a PR with the change if there's no obvious reasons not to do it. It'll allow me to re-use a saml provider CLI tool more efficiently.
There was a problem hiding this comment.
Existing providers always take precedence over new providers (except for EC2 metadata, which is always last). This is to make sure that people's config files continue to work the same as they had before if they don't change them.
Regardless, all you will need to do to make sure you're using this provider is to make a new profile where it's the only one set and use that profile explicitly.
There was a problem hiding this comment.
Guess where it feels a bit inconsistent to me is source_profile/role_arn win over hardcoded credentials:
[profile1]
source_profile = rd
role_arn = arn:blah:blah
# These will be ignored and it will use assumeRole provider
aws_access_key_id = ...
aws_secret_access_key = ...
aws_session_token = ...
But when using the credential_process it's the other way around, the hardcoded credentials win over the config option.
There was a problem hiding this comment.
The ability to have hard-coded credentials in a profile along with static credentials was never intended behavior. We won't break that (because people rely on it now), but we also don't want to continue doing that for other providers.
This allows users to configure an external process to provide
credentials using the
credential_processconfig variable.Note that this is built on top of the assume role provider since
there is rebasing necessary.