marceloboeira / awsudo Goto Github PK

Improve #1

It's often necessary to use unix pipes with awsudo credentials injection...

cat foo.csv | awsudo -u staging s3_uploader

where s3_uploader is a binary that takes stdin and stream upload to S3.

Make it possible to force / purge the cache

e.g.:
awsudo -u production --force ... -> forces the token generation

Right now, errors are not handled in a way...

$ awsudo -u invalid echo bar
thread 'main' panicked at 'Profile not found', src/main.rs:34:27
note: Run with `RUST_BACKTRACE=1` environment variable to display a backtrace.

it would be better to use something like:

$ awsudo -u invalid echo bar
Error: Profile not found

Sort of hard at this point, since there is no "docker-image" for AWS STS, it would have to be a REAL account structure, with some ROLE authorisation configured...

Might be something nice to do with terraform.

Create a brew formula so its easy to install on macOS :)

According to the docs here (and the behavior of the aws-cli tool), the profiles, ie. the section names in the ~/.aws/config file should be prefixed with "profile", for example:

[profile user1]
region=us-east-1
output=text

while awsudo, expects it to be just [user1].

At this moment, we use stdin/out to both print the Please type your MFA token... and collect the MFA token. That can be intrusive to users that might want to pipe/redirect its output:

awsudo -u production read_consul_logs > logs.txt

If an MFA token needs to be collected, the file output will include the printed stdin:

Please type your MFA token for arn:aws:iam::9999999999:user/bezos: 

MY LOGS

Therefore, we might be better served using /dev/tty.

Reference:

• marceloboeira/confirm-before@372415f

aws-cli supports a source_profile option in the config file which specifies which profile to get the credentials from. I actually don't have a [default] section in my ~/.aws/credentials file, so that a random aws command would fail to do anything. All my profiles explicitly specify where to get the credentials from.

Some examples here:
https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-role.html

ps.
When I have time, I'll take a look at implementing this. unless someone beats me to it.

Find a way you can use:

awsudo -u production aws s3 ls
instead of
awsudo -u production 'aws s3 ls'

That would make it more acceptable since we would be able to create aliases, such as:

alias awsp="awsudo -u production"

awsp AWS_KINESIS_STREAM=funky-stream ./my_project

Update

Still trying to figure a way around clap with this one: clap-rs/clap#1344

Make sure to cache the token only during its life time...

Start extracting, abstracting and testing. I don't know exactly how I'll do that, but I want to have some parts as independent modules so that it's easier to test and compose/change if needed.

• CLI - Parses the CLI command to trigger other modules
• Config - Loads the config from ~/.aws/credentials ...
• State Controller - Looks at the current state based on Config and figure what to do (takes care of caching, triggering command runner, token generator and such)
• Command Runner - Run the command with the injected variables (ENV)
• Token Generator - Receives information about the profile and return the token

Store the tokens while they are valid

Figure how to:

• Compile Rust for Production macOS (with Cargo?)
• Integrate that into the release process with Github (new GitHub Actions?)

AWS allows us to get the STS expiration timestamp from the response, at this point we just assume 1 hour and use that hardcoded all around.

More info:
https://docs.aws.amazon.com/STS/latest/APIReference/API_GetSessionToken.html