Docs feedback: AWS credential best practices

Everyone can contribute. Help move this issue forward while earning points, leveling up and collecting rewards.

• Close this issue

Document: https://docs.gitlab.com/ee/ci/cloud_deployment/#run-aws-commands-from-gitlab-cicd

Feedback:

I raised a thread on #26777 (comment 215634883) for security considerations on using AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY variables. Security-conscious users may prefer to use self-hosted runners on Amazon EC2 with instance profiles associated, as is the AWS best practice. IAM roles use short-term credentials which require three values instead of two and automatically rotate after a certain period (default: 1 hour). IAM user access keys do not automatically rotate and can more easily be compromised. This issue is further complicated for security-conscious users when GitLab-hosted runners are added to the mix.

There was a suggestion on supporting a balance between "ease of use/customer enablement" and "encouragement of best practices":

We could have links in the interface with information on the best practices when the AWS Variable option is chosen and, should they decide to go against the best practice, we could offer better default values for those keys (protected/masked by default, or maybe even force it?).

When it came down to it, these security considerations or references never made it into the docs.

The risk:

• IAM user credentials used in GitLab projects will most likely have AdministratorAccess such that they can use them to launch any AWS resources without "worrying" about permission errors
• Users are likely to use this same set of credentials across multiple GitLab projects
• Users are unlikely to rotate those credentials often, especially if they use them for multiple GitLab projects, because updating project variables in multiple places requires a lot of clicks
• Exposure of those credentials through any one of several vectors (exposure on shared runners, someone having privileges on a project that they shouldn't have, etc.) can be devastating for an organization since that person would in theory have administrator rights to their AWS account to use from anywhere in the world and can use them for an innumerable list of nefarious purposes.

I'm not suggesting that all IAM users are bad or that this feature is bad. Far from it; on the contrary, I am happy to see GitLab supporting AWS more natively. My suggestion is simply that GitLab make an effort to inform users of the available options so that they can make an informed decision on their own practices and risk tolerances.