Recently, I began auditing my AWS account and I saw how secure I had made it when deploying applications and managing external access. I even wrote a blog post recently on how people should adopt OpenID Connect to authenticate in CI/CD pipelines and deploy their applications to AWS.Recently, I was deploying a Terraform script locally and I could not authenticate to AWS. I figured out my static keys were expired and I needed to generate another. That was when I realized my real admin access wasn’t secure at all. I was still moving static keys around for admin access, and they were permanent.
I checked the IAM portal to see if I could find a solution to eliminate this completely, and I found a much better approach by using a federated identity through IAM Identity Center. I always thought only organizations should use this since they manage a lot of users, but now I can see why those orgs use this approach. Authenticating with a federated identity can be complex when setting up, but AWS identity center has made it easy and high-level enough to implement even for personal accounts.
What I Wanted
I knew I wanted simplicity, traceability, and the ability to eliminate static keys completely. Only a federated identity with Single Sign-On can provide that access, so I decided to implement it. I went deep into IAM Identity Center. I saw that I could create a user that authenticates through AWS’s identity provider, give it some permission sets, and time its permissions for limited access. In this setup, MFA can be enforced on all users with a single click, which is much better than IAM users authenticating with just a username and password.I also saw how I could integrate added extras like creating a separate account for the admin and using SCPs to manage the accounts and also limiting admin privileges with policies, such as blocking the creation of new IAM users. Then I came up with my own flow.
What I Tried
I experimented with a lot of things. I gave myself no permissions and created another role to elevate only when i need to perform admin tasks. Logged in as admin and saw I couldn’t access anything. All console dashboards were showing “access denied,” and I realized that was too extreme. That was when I started seeing how zero trust actually works.
I tried again, increased little privileges, and switched to read-only access. Everything worked, but the admin couldn’t still create anything. Then I logged in to the console CloudShell and assumed the AdministratorAccess role which i created alongside to elevate priviledges when i need to perform admin tasks. Now the temporary tokens came into play which is valid for only 1 hour. I had to put them in manually to access any resource, and that’s when I realized how critical it is to balance security and ease of use.
Checking the roles, I saw the permissions assigned by the identity provider were also short-lived, and there was no need to limit them further since they would be rotated automatically. That’s when I saw it was AWS Security Token Service (STS) still giving access behind the scenes to the SSO.
What I Eventually Arrived At
I eliminated the extra admin role I created for admin to assume because that was redundant. I went back to IAM Identity Center permissions and changed access from read-only to admin, but limited the session to 1 hour. This isn’t fully zero trust, but the admin still has to verify every hour if they are truly admin. It’s better than IAM users that give implicit trust. This setup is different because admin is never trusted it’s always verified.the fact that the sessions are logged through cloudtrail means the administrator actions can also be audited if warranted.
It’s like asking a police officer to always identify who he is by showing his badge. If he can’t, he doesn’t get access. So here’s the high-level overview I arrived at.
everything starts with the cloud admin logging in through the sso portal. mfa is enforced first thing so no one just walks in without verification. once i’m in, aws identity center takes over, assigns the right permission set and handles federation internally using saml. i don’t manage any credentials or keys myself anymore, aws does it all behind the scenes.
after that, sts kicks in and gives me temporary credentials. these are short lived, valid for just about an hour. once they expire, i have to re-authenticate again through sso. that’s where the zero trust idea really comes in. the admin role i assume is AWSReservedSSO_AdministratorAccess, and it only gives me access for that short window. when the session ends, that access disappears.
on the governance side, scps are set to restrict what even admin can do, like creating another identity center instance. cloudtrail logs every single action i take so i can trace anything later. cloudwatch helps with visualizing and alerting on those logs when something unusual happens.
so at the end of the day, this flow gives me full control when i need it, but zero standing privileges when i don’t.
The Realization Moment
Coming back to my failed Terraform script, I checked AWS docs, configured local SSO, created an admin profile, and was able to authenticate using the single-sign-on from the browser to the CLI and that was it. No access keys, sessions are timed. Now I have one hour to do what I need before I’m asked to show my badge again.
If you still think IAM users are enough or still moving static keys , and you’re still using them because your personal AWS account is “just for labs,” think about security, reliability, and how things are done the modern way. When the newer route is clearly better than the old one, take it ,no matter the complexity.
Top comments (0)