News for hackers. Stuff that matters.
Re:Awsviz.dev simplifying AWS IAM policies by jjice on Wednesday July 10, 2024 @08:47AM (#40926298)
> I have seen so many people just slam the root credentials into config in order to never touch IAM

Anecdotally, at a startup I worked for, our devops and security engineers pulled me into a call once because they needed my help finding where the root credentials were being used in our code. I logged into our dev, staging, and production servers, but they were nowhere to be seen in any place you'd expect AWS creds (like ~/.aws).

Then it hit me. I pulled up our git repo and pulled up a function that handled file upload to s3 for something incredibly unimportant. Right there, in plain text, checked into git. The git blame read something like "4 years ago".

Creds weren't even needed since the AWS SDK does whatever magic to know the creds based on the EC2 instances role. I immediately put up PR just removing the creds as the empty constructor for our SDK used the EC2 role (this pattern was used in multiple other parts of the code base).

The CEO (the author of the code) didn't want to merge it in case it stopped working, despite me demoing in our staging environment and the feature using this code was only used like twice a week.

Thankfully, we convinced him, got it removed from the codebase, and either cycled or deleted the root creds, I don't recall how that worked at the moment.

I wasn't familiar with root creds at the time either, but damn is it scary to think that anyone of the engineers had access to root creds for a company of the size that we were.

And the CEO wrote it like that originally because he didn't want to mess with IAM. I can see why he did it, but man was that a bad idea.

Re:Awsviz.dev simplifying AWS IAM policies by egorfine on Wednesday July 10, 2024 @09:31AM (#40926706)
> And the CEO wrote it like that originally because he didn't want to mess with IAM. I can see why he did it, but man was that a bad idea.

This is a very common case. It's okay in the very early development (rarely we start projects with a definition of IAM policies), but then it gets shoved into backlog forever.

Re:Awsviz.dev simplifying AWS IAM policies by SOLAR_FIELDS on Wednesday July 10, 2024 @09:58AM (#40926976)
There’s a pattern I see (and indeed have even perpetuated once or twice) of “AWSguide based development” where someone copy pasted the default policy/roles directly from a guide into AWS CLI commands and just forgot about them after. Not as bad as the root credentials being used but certainly doesn’t help maintain a sane and understandable access system.

I know it’s a lot of extra maintenance effort and probably more difficult but AWS could go a long way towards making this more sane and transparent by giving gitops examples alongside their CLI ones. Even someone just copy pasting terraform or cloud formation is going to be way more visible than AWS CLI

Re:Awsviz.dev simplifying AWS IAM policies by Lutger on Wednesday July 10, 2024 @10:58AM (#40927641)
I'm not sure how it is ever ok to put your _root_ credentials into version control? I am not even comfortably doing that with my personal private repositories that I share with nobody.
Re:Awsviz.dev simplifying AWS IAM policies by egorfine on Wednesday July 10, 2024 @12:50PM (#40928831)
Oops, I replied to an out-of-context comment. I mean it's okay to use a wildcard policy in the early stage of a project.

Of course, committing credentials into a repo is absolutely never ever ok.

Re:Awsviz.dev simplifying AWS IAM policies by Aperocky on Wednesday July 10, 2024 @09:31AM (#40926705)
Not a good sign...