Added support for AWS profiles as argument

[toniblyx]

No description provided.

[HenrikJaySmith]

Looking into this.
Will likely use the default profile option instead of session profile to simplify when adding new clients.

[toniblyx]

Hi @HenrikJaySmith thanks for looking at this. I'm probably missing something, not a boto expert. Can you use multiple AWS profiles without session profile? My use case, I guess, like many others is: I have multiple profiles in my ~/.aws/credentials, most of them with token (saml), how would you use them without having to edit credentials beforehand or having to provide keys?

[toniblyx]

Actually I don't know what is be best practice here, I just wrote my code based on http://boto3.readthedocs.io/en/latest/guide/configuration.html

[HenrikJaySmith]

In boto you can reference the profiles in ~/.aws/credentials in multiple ways. By using your method you can use different profiles for different clients in the same script. But, you have the initiate all clients from that session. A more suitable alternative for this use case is to set the default profile for all clients in the script to the desired profile. I will make some changes to show.

[grettir]

If I can make a plea…

I work with multiple (8+) Amazon accounts every single day. First thing every morning, I initiate new STS sessions (the keys for which are automatically updated in ~/.aws/credentials) and re-assume roles (the keys for which are cached in ~/.aws/cli/cache), and then I bounce back and forth between those different accounts hundreds of times over the course of the day running various AWS CLI commands, scripts, tools, reports, etc.

What makes that sort of thing possible is that every single tool that I use supports multiple profiles via the AWS CLI-standard --profile profilename command line option (and multiple regions via the --region regionname command line option). In fact, at this point, anything without that support feels almost barbaric.

Trying to maintain multiple versions of configuration files, multiple versions of scripts, or, even worse, having to edit the script every time you want to run it in order to cover all possible permutations of account/profile/region, simply doesn't scale.

If you added support for multiple profiles via the --profile profilename command line option (and multiple regions via the --region regionname command line option), you'd be following Amazon's standard practice/syntax, you'd be allowing boto3 to do all the heavy lifting when it comes to profile/role/key management, and you would earn the eternal thanks of users like me who have to deal with multiple accounts/profiles/regions on a regular basis.

[HenrikJaySmith]

profile support is coming. Keep in mind that you can also run this script using Config Rules, put the report in central bucket and collect info from all accounts. You can also collect the info on compliance result using "aws configservice get-compliance-details-by-config-rule
--config-rule-name ". This will show the reported annotation info.

Regarding region, the script will iterate through all regions vs a single region so no need for setting a region for it.

[grettir]

Actually, the first time I ran the script it failed, saying that I had to specify a region. (Which I then tried to do via the --region command line option, which obviously didn't work.)

Ironically, that failure was caused by the fact that I don't have a [default] account specified in my configuration files, specifically to avoid problems caused by scripts that don't support multiple profiles and that run against the default profile no matter what (which can be disastrous).

A Catch-22. But a self-inflected, precautionary one.

[HenrikJaySmith]

Ah, thanks, that makes sense. Will add that to the new update.

[derricksong]

Having some issues deploying this lambda function with Config Rules.. wanted to run the benchmark audit every 24h but doesn't seem to work. Running the script locally with creds setup in boto works, but deploying the code into a lambda function with the provided policy on a periodic (24h) schedule doesn't seem to work. Any idea? Apologies if this is the wrong avenue to ask for help with this.

[HenrikJaySmith]

Derricksong: Can you post this to https://github.com/awslabs/aws-security-benchmark/issues and add output from cloudwatch logs for the lambda function?

[HenrikJaySmith]

Closing this since I have added support for profiles in the main branch in the latest push