AWS SSO is one of the best and most popular ways to centrally manage access of users/developers to AWS Accounts, especially when combined with AWS Organizations for multi-account access and management.
AWS SSO Usually integrates with an IDP (like, Okta, Gsuite, AzureAD). This approach has many benefits, for instance: Only users that are in your Okta, Gsuite, AzureAD directory can access the AWS accounts. Authentication and MFA is managed centrally at IDP level. Any user that leaves the organisation is also automatically revoked access from AWS.
One issue that remains from the access and security perspective is the handling of IAM Keys. IAM Keys can be created by users in the IAM Console for dev/test/prod purposes.
When managing IAM Keys, we have to account for couple of scenarios:
To solve these issues, we first need to be able to locate/correlate IAM keys and their creators. The best way to do this in AWS (and usually in other cloud providers) is via a tagging policy. You can add a tag for each IAM key
creator=user@your_domain.com . You can also enforce this policy via AWS Policy.
Currently the standard way to solve the "Lost IAM Keys" issue would be to write a small/medium script that will do the following:
This approach will work, but will require writing quite a bit of code, testing and maintaining. It will also require integrating with at least two APIs/SDKs (AWS/Okta/Gsuite).
The other approach (and the reason why we started CloudQuery) is the belief the following issue should be solved in two simple steps:
The first step in our case is taken care of by CloudQuery (GitHub), - all you have to do is download a single binary from our GitHub and run it against your cloud account and Okta/Gsuite/AzureAD. You can fetch the configuration with the following commands:
Once CloudQuery loads the data into PostgreSQL, you can run the following queries to answer the above questions:
You can run CQ periodically, either from a local machine or a server/lambda, and create alerts using the above queries and CQ Policies.