gimme-aws-creds
gimme-aws-creds copied to clipboard
Automatically selects config section matching AWS_PROFILE
When a user has exported an AWS_PROFILE environment variable, the logic in this PR will find a matching section in ~/.okta_aws_login_config, if configured.
Description
See motivation section below. To enable the new feature for a given profile, the corresponding section in ~/.okta_aws_login_config must add a new attribute e.g., the following...
[someProfile]
aws_profile_env_match = foo
...would activate the profile when the AWS_PROFILE environment variable is set to foo
Related Issue
https://github.com/Nike-Inc/gimme-aws-creds/issues/271
Motivation and Context
E.g., Existing usage with many explicit profile references:
gimme-aws-creds --profile foo
aws --profile foo s3 ls
aws --profile foo ec2 describe-instances
AWS_PROFILE=foo terraform apply
Optional new usage for those of us who wish to type less:
export AWS_PROFILE=foo
gimme-aws-creds # After this PR, gimme recognizes the same environment variable as the AWS CLI and SDK.
aws s3 ls # The AWS CLI already recognizes the AWS_PROFILE environment variable
aws ec2 describe-instances
terraform apply # Other tools built on an AWS SDK already recognize the AWS_PROFILE environment variable
How Has This Been Tested?
I'm using it locally. If I have more time in the near future, I may provide additional documentation and testing. I tried to make the new feature at least a little bit self-discoverable without external documentation. I also did some manual testing for the existing cases.
For some reason, if I run nosetests --verbosity=2 tests/
, I get errors like the ones below, even though I ranpip3 install -r requirements.txt
:
from mock import patch
ModuleNotFoundError: No module named 'mock'
import responses
ModuleNotFoundError: No module named 'responses'
Screenshots (if appropriate):
Types of changes
- [ ] Bug fix (non-breaking change which fixes an issue)
- [x] New feature (non-breaking change which adds functionality)
- [ ] Breaking change (fix or feature that would cause existing functionality to change)
Checklist:
- [x] My code follows the code style of this project.
- [x] My change requires a change to the documentation.
- [ ] I have updated the documentation accordingly.
- [x] I have read the CONTRIBUTING document.
- [x] I have added tests to cover my changes.
- [x] All new and existing tests passed.
Need to use requirements_dev.txt
for running the tests.
The CLA at https://www.clahub.com/agreements/Nike-Inc/fastbreak isn't loading for me (tried both Brave and Firefox).
I tested this and it seems to work (ignore my previous review) One obstacle here is that the user does have to go in and manually alter their okta config to add a line, which is a little painful. I get the concept there, but seems like a bit painful anyway. I'll think about this.
One obstacle here is that the user does have to go in and manually alter their okta config to add a line, which is a little painful.
In theory, we could add a question to the --action-configure
wizard to help users when creating new profiles in their okta config. Unfortunately, in practice, I'm not sure how soon I'll be available to help with that effort. Would you be willing to take an iterative approach i.e., merge this sooner if I open a backlog issue to improve --action-configure
later?
I'm late to the party here. Am starting to use gimme-aws-creds again after several years of not needing it.
I need this functionality too and started implementing my own change without knowing this issue and PR were out there.
My code change is just 3 lines in config.py
:
https://github.com/jcreyf/gimme-aws-creds/blob/e4a5e5a43715dcbf436e4a2bb8d4e5a490571761/gimme_aws_creds/config.py#L177
1 line is a simple change to pick up the AWS_PROFILE
value (if set) and the 2 other lines are to display the selected profile on the command line to inform the user.
What do you guys think? It doesn't need any updates to the okta config.