[HN Gopher] Awsviz.dev simplifying AWS IAM policies
___________________________________________________________________
Awsviz.dev simplifying AWS IAM policies
Author : bscript
Score : 157 points
Date : 2024-07-10 00:35 UTC (22 hours ago)
(HTM) web link (www.awsviz.dev)
(TXT) w3m dump (www.awsviz.dev)
| bscript wrote:
| Sometimes, reading AWS IAM policies can be tough for me. I prefer
| visuals, so I often use the IAM Policy Simulator. To make things
| even easier, I built a small tool that turns IAM policies into
| simple graphs. awsviz.dev is a good tool designed to help users
| visualize, analyze, and improve their AWS IAM policies.
|
| More details: https://medium.com/@Bohr/introducing-awsviz-dev-
| simplifying-...
| kaladin-jasnah wrote:
| Should this be a "Show HN" post?
| bscript wrote:
| First time here, did not know about Show NH
| ckozlowski wrote:
| Welcome!
| dandrew5 wrote:
| New Hackers, I like it. A Hacker News clone strictly for
| new developers. Instead of articles, the links just map to
| posts on r/programmerhumor
|
| Welcome btw!
| itscrush wrote:
| Welcome, it's detailed here;
| https://news.ycombinator.com/showhn.html worth considering
| a post.
| lhousa wrote:
| Just skimmed through the post but how is it different from a
| plain json visualiser like https://jsoncrack.com?
| l3x4ur1n wrote:
| First thing that came to me after reading the url
| https://en.m.wikipedia.org/wiki/Auschwitz_concentration_camp
| bdcravens wrote:
| Perhaps it would make sense to link to the repo on the page? As
| best I can tell, you can easily self-host your tool (would need
| to update the redirects in the index.html).
|
| https://github.com/BourAbdelhadi/awsviz
| zarzavat wrote:
| This is a very bad name for a product.
| bscript wrote:
| You might be right. My focus wasn't on the name; I just wanted
| to create something useful for my day-to-day job and share it
| with others. The goal was never to commercialize the product
| ... so maybe that's why the name was bad!
| sclangdon wrote:
| He may be referring to the fact that it could be pronounced
| Auschwitz. I must admit, my immediate thought on reading the
| name was "why would someone name their app after a
| concentration camp?"
| bscript wrote:
| wow, I learned something new today
| dgb23 wrote:
| I had the same reaction. Even just a hyphen between like
| aws-viz would probably do wonders.
| zarzavat wrote:
| Yes I think any minor tweak would remove the effect.
| awsvizul, vizaws, awsvista.
|
| It's just a bit too on the nose at present.
| bn-l wrote:
| This is also what I immediately saw and heard also.
| linkgoron wrote:
| yes, I immediately thought that the pronunciation was
| Auschwitz...
| cyberax wrote:
| IAM policies can be so complex, that become close to unusable.
|
| Use multiple AWS accounts, and keep your policies simple. One
| account for DB, one for the backend servers, etc. Each
| environment (prod, staging, dev) also gets its own set of
| accounts.
|
| This way, a misconfigured policy won't give admin access to
| everything.
| potamic wrote:
| Wouldn't that lead to cross account policies, which appear to
| be even more quirky?
| devonkim wrote:
| Yeah, error messages start to become more opaque as well
| which makes debugging even tougher, which is kind of the
| opposite of the point of using multiple accounts. But really,
| AWS not having proper namespaces in its constructs that's
| ubiquitously supported (IAM paths were attempted. Attempted)
| hampers a lot of things
| cyberax wrote:
| In my practice? Not really.
|
| For resources like databases, you don't need cross-account
| access if you're using internal DB authentication systems.
| For IAM-based DB authentication, you can simply write
| policies to trust the target accounts.
|
| Occasionally, you'll need to create a cross-account trust
| (via AssumeRole), but it's not at all that frequent.
|
| My personal wish is for AWS to allow account _names_ instead
| of ID numbers in policies.
| laurent_du wrote:
| I honestly can't imagine a situation where this would be a good
| advice. Can you give an example of such an IAM policy?
| cyberax wrote:
| For example, if you want your CI/CD to deploy to
| CloudFormation and allow it to generate IAM resources, then
| it's essentially root-level access. Because you can simply
| create an IAM role that gives admin permissions to you.
|
| Or even without that, there are plenty of footguns. AWS has a
| good blog post:
| https://aws.amazon.com/blogs/security/protect-sensitive-
| data...
| Hikikomori wrote:
| One account per system and environment with shared vpcs is
| great.
| shakiXBT wrote:
| Having one account per database/backend/frontend is not only
| overkill, but actually a bad practice. You're going to have to
| expose your DB to the internet instead of having everything
| inside a single VPC.
|
| What you should do instead is have one account per environment
| (as you said).
| kroolik wrote:
| You can peer-connect vpcs cross-account
| dilyevsky wrote:
| Up to 125 peers before you have to setup a transit vpc
| which is a lot more complex
| Hikikomori wrote:
| Transit gateway can have 5000 VPCs connected in a region,
| and you have multiple TGWs. And rather than have a VPC
| per account you can use Shared VPCs instead.
| tenplusfive wrote:
| I've recently stumbled upon the possibility to share a VPC
| and use one VPC with multiple accounts:
| https://docs.aws.amazon.com/whitepapers/latest/building-
| scal...
|
| I'm honestly not sure if thats a great idea, but this might
| be a possible way to do one account per DB/backend/frontend
| in a somewhat sane way.
| LilBytes wrote:
| It's fine, but you're going to attract a lot of network
| costs bridging data between AWS accounts.
|
| Generally I'd stick to accounts per environment, you'll be
| worrying about a lot more when you get to FAANG scale.
| visualphoenix wrote:
| Sharing a VPC between accounts with AWS RAM incurs no
| network costs between the accounts and greatly simplifies
| AWS networking. Additionally you can share and re-use
| security groups from the shared vpc across account
| boundaries.
| lijok wrote:
| It's a great idea if you know how manage it. This is
| current recommended practice for corporate. Single Network
| account that interconnects everything and dishes out
| subnets to other accounts for use exclusively by them.
| shakiXBT wrote:
| oh, that's cool, I didn't know that was possible.
|
| That said, I still think it's overkill and doesn't bring
| any real benefit? Sure you're reducing the blast radius of
| a security breach, but are the overcomplications worth it?
| Also, you now have to manage multiple accounts with
| multiple policies and users / roles, won't that extra
| complexity actually increase the attack surface?
| thedougd wrote:
| I do this. Technically you share the subnets. It's a
| fantastic pattern and enables greater autonomy for
| application teams. They're given an AWS account per app
| environment (e.g. WidgetApp Test, WidgetApp Prod, etc) and
| are able to build their stuff and attach it to existing
| subnets without a care about 'how' it communicates with the
| Internet or the greater organization.
| Hikikomori wrote:
| You'll find that a plan like this is not overkill once you
| outgrow single accounts. Though I would do one account per
| system with Shared VPCs instead.
| chippiewill wrote:
| We use peered VPCs at work. We have a central account per
| environment that has the VPC that's shared to all the other
| accounts in that environment for databases etc.
|
| To be honest, I'd probably prefer a single account per
| environment. But managing the IAM for that would be much more
| work.
| cyberax wrote:
| > Having one account per database/backend/frontend is not
| only overkill, but actually a bad practice.
|
| That's how AWS works internally. A team can easily have
| several hundred accounts: one for each region, and for each
| env.
|
| You absolutely need tools to manage them, and AWS is not
| great in this regard. IAM Identity Center is a good first
| step, but its usability sucks compared to the AWS internal
| tool (called "Isengard").
|
| > You're going to have to expose your DB to the internet
| instead of having everything inside a single VPC.
|
| There are several ways to NOT do this. The easiest one is to
| use IPv6 with your own block (you can get it from ARIN for
| around $100). Then split it into "public" and "private"
| subnets, and install a network ACL prohibiting external
| connections into the private subnet.
| timendum wrote:
| I think Policy Details card should have a scrollbar, but it is
| set to "overflow: hidden".
| bscript wrote:
| Good point. Thanks
| egorfine wrote:
| Okay, so I have no idea what to do with that web. I copied one of
| the complicated policy JSONs from AWS, now where do I paste it?
| What's there to upload? In _zip_?
| bscript wrote:
| paste it to the IAM Policy JSON input or zip your json files
| and upload the zip.
| egorfine wrote:
| Ah, I can see you added JSON input. Tried it.
|
| It looks like the "The user is allowed to:" part is the most
| important one and should be on top. The graph visualization
| does not make any sense on my random JSON policy I have just
| pasted.
| bscript wrote:
| you can move the section to the top, just drag and drop.
| egorfine wrote:
| I have been discussing IAM with a couple of AWS engineers from
| that team a few years ago. I have tried to convince them to
| implement something actually sane non-corporate developers,
| because IAM is complicated way beyond a point of being usable. I
| have seen so many people just slam the root credentials into
| config in order to never touch IAM. And yes, me included, and
| yes, it's a shameful practice, don't do that. Take a day off, go
| on a hike, watch the sunset, meditate and embrace the inevitable:
| yes IAM is incredibly bad and there is no way around.
|
| (I was heavily using AWS since inception, way before IAM was
| invented).
|
| My speech fell on deaf ears, because IAM is clear as sky to its
| inventors and they fail to see what's the problem in it and
| corporate customers are happy to employ one or two people solely
| dedicated to learning and managing IAM.
|
| Anyways. There is no way around IAM. And just like with systemd
| you better embrace it and learn it and it turns not that
| terrible.
| JackSlateur wrote:
| I find IAM to be a great product. I cannot imagine how we could
| make it different, without removing some of its capabilities:
| after all, this is nothing but a list of <who, what, on which>
| permissions
| MrBuddyCasino wrote:
| > _I cannot imagine how we could make it different_
|
| This seems almost bait.
| egorfine wrote:
| Problem is, once you dive deep in the rabbit hole, you will
| inevitably build another IAM.
|
| The art here is knowing when to stop building, not what to
| build.
| cqqxo4zV46cp wrote:
| This is a great way to avoid voicing constructive criticism
| about IAM that doesn't end up being "hard-code it for my
| use case at the expensive of making it difficult for a
| significant portion of other customers".
| nprateem wrote:
| Well, for a start, you could have a recorder that actually
| shows all the relevant permissions for a particular API call
| so users can work out what they should set permissions on
| (including interactions with SCPs and anything else that
| could affect a decision).
| rad_gruchalski wrote:
| You can easily get the first part of via the sdk
| https://cloudonaut.io/record-aws-api-calls-to-improve-iam-
| po....
| Aeolun wrote:
| You can actually set this up in your account. It'll record
| all the permission your roles actually use (over a
| customizable period of time), so you can remove all others
| egorfine wrote:
| I tend to agree with you that the idea of a list of "who,
| what, which" is straightforward and probably is the right way
| of doing things. I agree that permissions is inherently a
| hard problem.
|
| I disagree that IAM specifically is a great product. It's
| great if you learn it, but learning permissions system never
| adds anything to the bottom line. It's an evergrowing
| technical debt at best. People interested in learning
| permissions system are typically people interested in
| developing one. Users are never happy with permissions
| systems because more often than not it's a nuisance.
|
| In my view IAM is an incredibly overengineered list of who,
| what, which, suitable for corporate granularity but then too
| complex to be used by a startup or a project.
| JackSlateur wrote:
| Yes
|
| You are diving into another topic: "fine-grained
| permissions"
|
| In my opinion, fine-grained permissions is a very good idea
| for application-attached role: your lambda can only do
| "this", your ec2 instance can only do "that". For humans,
| they are a mistake and shall be avoided.
| egorfine wrote:
| I'd love for fine-grained permissions to be optional. Not
| an insurmountable barrier to the actual service.
|
| Like let me start the development first. I'll get to
| security later. I came here for object storage, don't
| force me to learn an incredibly complex auxiliary
| service.
| lijok wrote:
| But they are, that's kind of the whole point. You start
| with {"actions": ["s3: _" ], "resources": ["_"]} and
| graduate from there when ready.
| egorfine wrote:
| This could be a perfect 101 on IAM which I would strongly
| prefer never attending.
| lijok wrote:
| How else do you expect to manage permissions? Is there a
| better dsl design you have in mind?
| egorfine wrote:
| What is _better_? I am pretty sure IAM is the best there
| is, no questions about that.
|
| Better for small teams? Sure: a login/password system
| with maybe optional restrictions on services and maybe
| "readonly" access and maybe with disabled aws console.
|
| Basically, something that was in AWS before the IAM
| madness came in.
| JackSlateur wrote:
| But you can do that with IAM, and quite easily too
|
| Create IAM user with access/secret keys are easy
|
| Assign the built-in ReadOnly policy, easy too, or any
| other built-in "generic" policy
| danielheath wrote:
| If my account has only got one thing in it, I don't
| expect to manage permissions at all.
|
| "Everything has root" is fine when you are starting a new
| thing - what's needed is tooling to start there and grow
| into fine grained permissions when you add a second
| thing.
| xenophonf wrote:
| > _Like let me start the development first. I 'll get to
| security later._
|
| And that's why the world is full of crappy, insecure
| software. Security is ever an afterthought.
| egorfine wrote:
| Wholeheartedly agree with you. Not only it's an
| afterthought, it's a sinkhole for resources with zero
| apparent ROI. It's basically lives in backlog rent-free.
| icedchai wrote:
| They basically are optional. You can use wildcards in the
| action. (Nobody will go back and tighten them up though.)
| inopinatus wrote:
| The true purpose of IAM is for AWS control-plane and data-
| plane elements to interact autonomously with resources that
| are in your account without violating the dialectic around
| security "of the cloud" vs "in the cloud".
|
| And this is also why you need a PhD to fully comprehend it
| cqqxo4zV46cp wrote:
| No. You're in denial about the importance of authorisation,
| don't want to give it the time it _deserves_ , and are
| shooting the messenger in placing the blame on IAM to the
| degree that you are. People see AAA as a pain in the ass
| because it's not the problem they thought they'd need to
| solve. That doesn't mean that it's important, or that the
| complexity is avoidable.
|
| For the record, I've never been in a development team of
| more than 4 people, and my teams have always been
| responsible for their own ops. No 'corporate dev' here.
| egorfine wrote:
| > People see AAA as a pain in the ass because it's not
| the problem they thought they'd need to solve.
|
| True.
|
| > That doesn't mean that it's important,
|
| Not necessary true.
|
| > or that the complexity is avoidable.
|
| Untrue. There is no need for IAM for the vast majority of
| 4 people teams and there could be a simpler solution for
| those, like it was before IAM. And it can actually be
| built on top of IAM, just spare people from diving deep
| into it.
| Aeolun wrote:
| > suitable for corporate granularity but then too complex
| to be used by a startup or a project
|
| To some extend. It's perfectly possible to make a role that
| allows S3 access to any action on everything, but still
| restricts the service from operating on any of the other
| 400 AWS services (unlike root credentials)
| myaccountonhn wrote:
| I don't think the language is bad, but maybe improve the
| policy simulator, make it easier to understand what policies
| are require and also make it easier to find and reference
| different arns.
| whs wrote:
| I wish it is a list of <who, what, which>. Right now you
| can't even get a comprehensive list of people who can access
| this S3 object. Add assume roles, conditional access, cross
| account, per-service object level policy into the mix I don't
| think it's even actually possible for AWS to implement that.
|
| I found GCP's access control to be much simpler but more
| limited than AWS. They're adding complexity though with
| conditional access. In GCP the "who" in most case is an email
| (Google Account, Google Groups, service account)
| JackSlateur wrote:
| You are right : "much simpler but more limited"
|
| And because you can limit yourself, you can effectively
| simplify your way of consuming IAM
|
| "He who can do more can do less"
| tyingq wrote:
| The way it evolved makes it complicated. That you have normal
| policy, resource attached policy, SCP, Assumed roles, etc,
| etc.
|
| That spreads out the actual end resulting policy into a bunch
| of disparate corners that's hard to unravel.
|
| There's tools to see "can this specific user/role/service get
| to this thing". But because of the above, there's no one
| place to see "who can/cannot get to this thing".
| oneplane wrote:
| I'm not sure how that is complicated. There are different
| systems with different functions for different purposes,
| that will not go away unless you remove the systems or the
| purposes. And that's not useful.
| tyingq wrote:
| Okay yes, I figure out what I need to. But it seems clear
| that conflicting concepts got bolted on after the initial
| design. Which means it's more complicated than it needs
| to be.
| oneplane wrote:
| Which ones are bolted on? Besides the S3 ACLs (which are
| more like a precursor) and the weird conditional language
| it's all pretty consistent and obvious like any ACL.
|
| Things like principals, resources, trusts and control
| policies are all distinct systems with different goals
| and purposes. Maybe I'm missing some different AWS IAM
| policy that has that bolt-on flavour?
| tyingq wrote:
| You can't meld the rules together to get a cohesive view
| of, for example, "who can access this S3 bucket?".
| Because, for example, an SCP can override a bucket
| policy. And policies can be other places too.
|
| I can get "can this specific role/user access this
| specific bucket", just not the other direction.
|
| It's not because the language isn't consistent, it's
| because the language isn't backed by a single cohesive
| RBAC type setup.
| oneplane wrote:
| I'm not sure how that makes it a bolt-on or conflicting
| or complicated. It is indeed not a simple central
| spreadsheet of 'who can do X on Y', but that would not be
| feasible at AWS scale.
|
| Microsoft tries that with Entra and it's a pretty
| miserable experience. Google has CEL for the conditionals
| which is neat, but it gets rather close to software
| engineering rather than IAM configuration at that point.
| The somewhat hierarchical nature they use is also not as
| great as it seems on first glance.
| tyingq wrote:
| Yeah I'm not saying I can't use it. I'm just trying to
| explain why people might look at it and feel like it's
| not unified.
| Joker_vD wrote:
| > There are different systems with different functions
| for different purposes,
|
| Which are interconnected, right? If yes, then that's what
| the word "complicated" means: made of multiple, non-
| trivially interacting parts.
| oneplane wrote:
| You can choose to interconnect them but that is neither
| required nor default. It depends on what you want to
| build.
|
| You can have a simple policy on a resource that just
| allows something, or you can make a complicated bi-
| directional set of policies that refer to specific
| principals, resources and actions to constrain it more.
| That will never go away if that is what you need to
| build. And it is still optional because if you don't want
| to build that, then you just end up with your single,
| not-inter-connected policy.
| JackSlateur wrote:
| Imagine, you drop IAM and revive the good old user/password
| system.
|
| You have no way to see "who can/cannot get to this thing".
| Yet who could argue that user/password are "complicated" ?
|
| NB: using IAM access/secret key has indeed the same issue
| tyingq wrote:
| I'm not arguing for user/password.
| randomtoast wrote:
| AWS is good at building abstractions on top of their already
| existing features, e.g. AWS App Runner. Maybe there could be
| an abstraction on top of IAM that does not allow for all the
| fine-grained permissions settings and options that IAM has,
| but has much simpler predefined roles which are very well
| suited for a small startup.
| nerdjon wrote:
| For a lot of situations they already have this. They have
| managed (AWS Created and Managed) policies that if you want
| a basic level of security you can use.
|
| A lot of services will create policies for you, for example
| you can go to RDS and click setup connection to lambda, or
| ec2 and it will create the policy.
|
| A lot of things will give you the policy to copy and paste.
|
| Another UI to further abstract IAM would likely just
| complicate things, and then make it harder later if/when
| you need to leave that abstraction.
| icedchai wrote:
| The main problem is it's a huge time suck. When writing IAC
| like Terraform, you'll probably spend more time configuring
| IAM roles and permissions than you do the actual
| infrastructure. Also, in my experience, nobody reviewing your
| code will check if it's correct, least privilege, etc. And
| when you get it wrong (too restrictive), the error messages
| can be difficult to diagnose, depending on the service. So
| most people will err on the side of more permissions than
| needed.
| presspot wrote:
| I have hard this from many developers. Are there any good
| solutions or best practices I should look into?
| turtlebits wrote:
| Don't use Terraform? If you want to create individual
| resources one by one, go for it. Use something like CDK
| which abstracts a lot of the boilerplate away.
| icedchai wrote:
| I wound up with a job at a TF-heavy company. I personally
| despise Terraform. The language is anemic and there's too
| much copy-paste code.
| sgarland wrote:
| ...and compiles into CloudFormation, which is of the
| devil.
|
| I also have issues with infrastructure being declared
| imperatively. I've seen countless bugs and incidents
| caused by CDK surprises.
|
| You get precisely what you ask for with a declarative
| language.
| dopylitty wrote:
| It's a little more complicated than that. I've run into many
| instances where a particular Action involves many different
| Resources.
|
| If you're trying to do fine grained permissions you have to
| know every resource that might end up in the request context
| and then have an entry in a Resource section of a policy for
| that Resource type. For instance just creating an EC2
| (RunInstances) might involve Subnet, Security Group, EBS,
| image, volume, snapshot, and a few other resource types.
|
| This gets even more complicated when you're using Condition
| operators because the conditions are checked against every
| resource in the request context but each resource type has
| different valid conditions (eg some resources have tags and
| some don't) so you have to split up the policy into numerous
| statements specific to each resource type.
|
| All of that would be fine if there was any way to actually
| reliably get the context of a request so you can see exactly
| what was denied. Sometimes you can get the context via the
| encoded authorization message in a failed API call but this
| is usually truncated in CloudTrail or if you're using IaC
| tools like Cloudformation.
|
| They've done a lot in the past few years to explain why a
| particular call was denied but none of it beats seeing the
| context and seeing exactly which part of the policy did or
| didn't apply.
| wetpaste wrote:
| I think it gets hard when an emergent chain of complex trust
| relationships need to be built and understood. Things like
| IAM identity center, workload identity, IRSA on EKS, service
| principals vs roles for accessing other services from a
| service, resource policies vs principle-level policies and
| when to use each. Not necessarily intuitive all the time. I
| don't think it's THAT hard and I understand why some of these
| things were built this way, but it's a huge complicated
| ecosystem of services and I understand why it can get
| confusing to some. Gotta be disciplined about it.
| danielheath wrote:
| "Record mode", where for 24h all permissions are
| automatically granted on first use, would be an obvious
| improvement.
|
| The ability to measure what permissions you need and record
| them automatically would improve the onboarding experience
| immeasurably.
| lijok wrote:
| Cedar, the new language by AWS that's currently used by
| Verified Access, is looking good; https://www.cedarpolicy.com
| egorfine wrote:
| Their mere description on that page makes me shiver.
| rirze wrote:
| this is application side, correct?
| nerdjon wrote:
| I disagree. IAM does what it's supposed too when you need to
| run an organization with very fine gained controls.
|
| People being able to see and interact with certain services but
| not everything related to those services. Same with services
| since it's the same system.
|
| To me the problem isn't IAM itself but the nested API calls.
| Which also itself isn't a problem but we need a better UI to
| diagnose when something goes wrong.
|
| Cloudtrail isn't really suitable for this task. A "simple" UI
| of looking at a role and seeing a "failed calls" would go a
| long way.
| captrb wrote:
| There is a pretty simple way to query cloudtrail logs with
| Athena and its a huge improvement over the normal UI.
| nerdjon wrote:
| I probably should have been more clear on that, it is very
| possible with Cloudtrail and Athena and I find myself doing
| that pretty regularly.
|
| But there are also times that it is inconsistent at best
| especially when trying to look at some nested permission
| problem. More than a few times I have had to get on with
| AWS support because the actual error just was not in
| Cloudtrail anywhere. Or it is related to some service that
| doesnt log to Cloudtrail like s3 access.
|
| Which kinda more my point was, it isnt IAM itself that is
| the problem.
| schmidtleonard wrote:
| When "run a SQL query against an implicit file database" is
| a huge improvement for anything but the edgiest of cases
| (and I believe you that it is), that's a scathing
| indictment of the normal UI.
|
| What I don't understand is how the AWS log inspection tools
| are still as bad as they are. Even if it's just to prepare
| public-facing material, AWS clearly dogfoods them a little
| bit, so surely there would be glory and accolades to be won
| by implementing search that was half-assed (instead of
| quarter-assed)? Or is the AWS culture so broken that it net
| punishes core improvements? Come to think of it, that would
| explain a lot.
| jjice wrote:
| > 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.
| Aperocky wrote:
| Not a good sign...
| egorfine wrote:
| > 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.
| SOLAR_FIELDS wrote:
| 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
| Lutger wrote:
| 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.
| egorfine wrote:
| 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.
| js2 wrote:
| IAM is conceptually straightforward, but it's combinatorial
| difficult with all the different ways that AWS services
| interact with it. Support for IAM is also inconsistent across
| services. I'll give a recent example.
|
| I have EC2 Mac instances in an autoscaling group that are
| running untrusted code. I've "sandboxed" that code by running
| it as its own user and blocking that user from reaching the
| IMDS endpoint with a packet filter on the instance so that the
| untrusted code, in theory, cannot get instance policy
| credentials. Nonetheless, I'd like to limit the blast radius
| should the code somehow escape that sandbox. So I want the
| instance policy as restricted as possible.
|
| One of the things the instances need to do is set tags on
| themselves. For this, you can use an IAM condition on the ec2
| CreateTags action to say "this instance can call CreateTags,
| but the instance ID has to be the instance itself". This
| prevents an instance from setting tags on a different instance
| in the same autoscaling group.
|
| The instances also need to make a few autoscaling API calls, to
| complete lifecycle actions (CompleteLifecycleAction), and to
| enable and disable scaling protection (SetInstanceProtection).
| Here again, I'd like each instance to only be able to make
| these calls against itself. Unfortunately, there is no
| condition you can use with the autoscaling API to similarly
| limit the calls as you can with the ec2 API. The same condition
| that works with the ec2 API doesn't do anything with the
| autoscaling API.
|
| Not helping matters, the documentation is very spread about.
| Just in the use case I describe above, you need to read at
| least all of these:
|
| https://docs.aws.amazon.com/service-authorization/latest/ref...
|
| https://docs.aws.amazon.com/service-authorization/latest/ref...
|
| https://docs.aws.amazon.com/autoscaling/ec2/userguide/ec2-au...
|
| https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/iam-poli...
|
| https://docs.aws.amazon.com/autoscaling/ec2/userguide/contro...
| rirze wrote:
| In my experience, it's _fine_. I just wish it supported more
| condition keys across all services. Nothing sucks more than to
| write a policy with a explicit condition only to bash your head
| trying to figure out why and then finally realize that
| restricting for a specific tag for a specific resource+action
| is not supported.
| Aeolun wrote:
| I feel like IAM is not actually that complicated? Most services
| have permissions that are in direct correspondence with the API
| calls you want to make. Of course a few of them decided to do
| mad shit (looking at you API Gateway), and a few others require
| you to have nearly all permissions to do some of their most
| common API calls (S3 needs like 15 permissions to set all
| possible properies on an S3 object).
|
| It'd be nice if AWS could fix the madness and standardize on
| one List/Update/Create/Delete call per resource, since most
| services are already like that.
| Fire-Dragon-DoL wrote:
| Don't they have a table that states api call -> IAM
| permissions necessary?
|
| That would go a long way into solving the problem
| ak217 wrote:
| I'm not sure how IAM is any more difficult or harder to
| comprehend than any alternative. I've been using AWS since 2010
| and frankly IAM has never been an issue. Can you give some
| examples?
|
| In any case, IAM and its essential features are not some
| optional thing; it's actually the prerequisite for AWS existing
| in its current form. IAM is the most universal AWS service -
| every other AWS service must use it. It's a loosely coupled
| symbolic policy computation engine for federated identity and
| service permissions. The "federated" part is doing A LOT of
| heavy lifting here: without federation, it's impossible to
| decouple teams and achieve the organizational velocity that AWS
| has.
|
| Other cloud providers have ended up re-inventing AWS IAM,
| sometimes poorly. Although I have to give GCP credit for
| recently greatly improving their IAM console and permissions
| error usability.
| bfLives wrote:
| I think IAM would be a lot easier to interact with from a dev
| perspective if the error messages were more clear. I suspect
| that they are sometimes intentionally vague (or misleading) as
| a kind of security-through-obscurity. For example, S3 returns
| "file does not exist" errors when the real problem is that the
| caller doesn't have permission to access the bucket/prefix.
| Dowwie wrote:
| Is this a claude artifact?
| nerdjon wrote:
| Is there somewhere that outlines what is done with the uploads or
| is this all client side?
|
| I am reluctant to just upload an IAM Policy when that could
| include bucket names, databases, account names, etc. Things that
| could expose more information than I would like (both security
| and product related)
| bscript wrote:
| Client side only, you can check the github repo
| nerdjon wrote:
| Ahh thank you, I did not realize this was open source. I
| might recommend putting a link to the github repo at the top
| or something, unless I am just looking right past it I don't
| see that anywhere (the most I see is the github script to
| copy)
| bscript wrote:
| Will add the link to the website ;)
| ckozlowski wrote:
| Very cool.
|
| What are you using to rate severity in the security scan? Is
| there a full list of checks being performed?
|
| I recommend having both resources in your documentation. If
| you're referencing another document, link to it. That way there's
| some context to the results as to why a policy author should
| change it. Just something to add to the improvement list.
|
| Looks good overall! Thanks for sharing!
| koromak wrote:
| The best part of any new stack: Spending 4 days repeatedly
| destroying and creating it while you figure out a single god damn
| policy to add to the project at a time
| Aeolun wrote:
| Still better than just giving it all permissions to be done
| with it? At least it made me feel a little bit happy when I did
| this the first time.
| rafaelturk wrote:
| This like this is what made us leave the cloud and go back to our
| own private cloud.
| JustAnotherJeff wrote:
| You just made me want to stop lurking and register to say Thank
| You. I have a bunch of users that keep producing blatantly wrong
| IAM policies, I hope such visualisation will help putting some
| sense in what they write.
|
| Very good and straightforward - thanks a lot for providing the
| GitHub repo as well as I would never tell them to paste policies
| on a random website.
| tobilg wrote:
| I publish a daily updated AWS IAM dataset at
| https://github.com/tobilg/aws-iam-data as well as historized
| managed IAM policies at https://github.com/tobilg/aws-iam-
| managed-policies
|
| There's also https://www.awsiamdata.com/ which analyzes the AWS
| IAM data and also contains a changelog. Maybe this helps some
| people.
|
| You can also query the data from your browser:
| https://tobilg.com/chat-with-a-duck#heading-explore-aws-iam-...
| redeux wrote:
| Thanks for sharing this! Very useful data. The contrast on your
| dashboard at https://www.awsiamdata.com/ makes it almost
| impossible to read. You may want to take a look at that.
| tobilg wrote:
| Thanks for the feedback, are you using dark mode eventually?
| Aeolun wrote:
| It's night here and dark mode is on. Some things get
| darkified, but especially the text stays white and is
| displayed on bars that are nearly white.
| redeux wrote:
| Yes, I use dark mode as my standard theme.
| otteromkram wrote:
| This is interesting. Is it just a reference package for npm? As
| in, you can't set/update policies with it or do other IAM ops
| with it, correct?
| tobilg wrote:
| Exactly, it's "just" extracting the AWS IAM data from the
| publicly available documentation, stores it in multiple
| formats and publishes a NPM package containing the data with
| some wrappers/accessors, so that people can theoretically
| leverage it to build their own tools.
| playingalong wrote:
| You might consider adding git-scraping label to your repo.
| glzone1 wrote:
| Isn't there a way to basically give your project root in a
| separate account, then use cloudtrail to figure out what policies
| it actually needs? I've not been able to get that going myself
| but it seems like a more efficient approach potentially.
| turtlebits wrote:
| You can use Access advisor to see which service your IAM
| role/user has accessed and when. You can then prune permissions
| which haven't been recently used.
___________________________________________________________________
(page generated 2024-07-10 23:02 UTC)