I work at a self-hosted company that's transitioning to AWS. We've partnered with a contractor who set up a Landing Zone with multiple accounts and SSO for easier system management. While I understand the benefits of SSO, I'm feeling uneasy because the contractor told me that IAM should be completely avoided, no exceptions.
I have a specific use case where our GitLab CI/CD Runner, which isn't hosted on AWS, needs to start and stop ECS containers in a specific AWS account. Previously, I would have simply created an IAM user with the necessary roles in that account using Terraform, and set up Access Key ID and Secret as environment variables in the runner. Simple, right?
However, the contractor argues that IAM is inherently insecure and insists on using Access Tokens tied to an Ops Staff Account that expire regularly. I'm skeptical about this approach; I believe binding automation tokens to actual user accounts isn't ideal. Plus, having tokens that expire every few days or weeks could hinder automation since someone would need to replace them regularly.
I can see the rationale behind avoiding Real-Person-User-Accounts in IAM, but the contractor's suggestions seem overly complex for automation purposes. How can IAM be seen as insecure when it's the standard for authentication in AWS, which most tutorials and documentation rely on?
5 Answers
IAM users with static credentials aren't ideal, but they aren't entirely outdated. It's the long-lived credentials that pose a risk, not IAM itself. You really should explore OIDC for handling your GitLab CI/CD needs, as it avoids many pitfalls of static access keys.
Your contractor makes a valid point about avoiding long-term access keys. GitLab supports OAUTH, which you could use to configure your runner securely. Switching to a token system can enhance security by reducing the chances of leaks due to static credentials. Here's a useful guide: https://medium.com/@vjmourya/step-by-step-authenticate-gitlab-pipelines-to-aws-with-oidc-no-static-keys-ae1baa9647e5
Your contractor might have meant long-lived access keys when discussing security concerns with IAM. It's important to use IAM roles with short-lived credentials through STS, which reduces the risk significantly. IAM has its flaws, but when managed properly, it's essential for automation.
IAM itself isn't insecure. The risk comes from using static keys that can be exposed. It's similar to protecting your private ssh keys. One good solution is to use OpenID Connect (OIDC) for authentication with GitLab. You can find helpful info here: https://aws.amazon.com/blogs/apn/setting-up-openid-connect-with-gitlab-ci-cd-to-provide-secure-access-to-environments-in-aws-accounts/
Thanks for the suggestion! I'll definitely check that out.
I think there's some confusion between security and risk. IAM is fine if used correctly. For GitLab's use case, setting up an OIDC provider with IAM roles would help. You set permissions tightly and use temporary credentials with a short lifespan to minimize risk. This method aligns well with modern security practices, as it reduces reliance on long-lived access keys.
Great, thanks for the link!