Hacker News Reader

Comment by Aperocky | Hacker News Reader

Some internal perspective - IAM has maybe thousands of options but fundamentally it is "what does this role have access to doing (action + resource)" + "who has access to this role". That is really it from a 10k foot level.

IAM is great because it applies internally just like it does externally. The internal AWS team don't get more access than you do, and if we get access to do certain thing on your account to perform specific service that's because you have a service principle in your IAM trust relationship that allowed us access, that you can see, and audit. For instance, lambdas have lambda role because you don't want lambda service just reading your S3 buckets because "we're AWS we automatically get access", you can absolutely see and control access, even if it is internal to AWS.

View on HN

> but fundamentally it is "what does this role have access to doing (action + resource)" + "who has access to this role". That is really it from a 10k foot level.

Hahahaha. No, fundamentally it is one input into a huge mess that you cannot actually see or audit from a 10k foot level.

AWS has produced a long, rambling and imprecise description of (some of?) what’s actually going on. You can read it here:

https://docs.aws.amazon.com/IAM/latest/UserGuide/access_poli...

Some of what they’re describing doesn’t even live within the IAM umbrella as far as I can tell. I’m not convinced that a concise, formal and unambiguous specification exists anywhere, even within AWSes own development teams.

I’ve asked LLMs to write AWS “policy”. They get the grammar mostly right. They cannot explain what the effects are in a manner that they will stand by after they search the web for documentation. Since I have never found good documentation despite looking, I can’t personally do any better than the LLMs. I’d love to be pointed at real documentation or specs.

They are just some slight variation of the fundamental idea. For example resource policy and org SCP are just the same check on a different level (e.g. more of who has access to what). They are attached to Organization and individual resource respectively (vs Account) so they need to exist in a separate place. And then in use they are ALL checked before an access is granted.

I don't work for IAM but I worked for several other teams over the years and IAM is actually one of the least confusing services. But I am definitely biased and have more than average amount of experience on this particular subject. I still think the general idea is more sane than Azure Account for example. I do think this reflect on the philosophical level where whether cloud are building blocks or are they consulting projects. I personally think IAM is done right in that regard.

> And then in use they are ALL checked before an access is granted.

I know they’re all checked. What don’t know is how the results of those checks are combined to get the final result. As far as I can tell, the result is not something like OR or AND — it seems like it’s something exceedingly complex and that the output of the policy part may be more complex than just a Boolean value.

Maybe the underlying implementation is fantastic (and my distinct impression is that AWS takes this stuff far more seriously than Azure), but that doesn’t mean that the docs are easy to find or that the system actually makes sense in anything other than an agglomeration-of-backwards-compatible-layers sense.

The output is Allow or Deny. To be Allowed, you need an policy that includes an Allow statement. If you don't have one, then the result is implicit Deny by default. Also, any explicit Deny wins over all Allows. Disclosure: I work on AWS IAM.

> that's because you have a service principle in your IAM trust relationship that allowed us access

That’s why it’s so complicated!!!

I don’t understand how I should evaluate trust for your internal EBS org versus your internal ALB org.

I kinda just expect it to be all “AWS” trust.

And it’s all garbage anyway. There’s no way I can prevent the hypothetically untrustworthy EBS team from surreptitiously adding charges to my account if they want to. Right? This would maybe make some sense if I could top level turn off/on services, but that isn’t how it works.

—

I have no doubt this makes some sense from someone inside the machine, but from the outside it’s not helpful nor useful.

3 things to untangle here.

1. It's about trust and auditability, while you may not want or need it, there are a lot of customer that are either interested or legally obligated to know who have accessed certain data.

2. It's about dogfooding - how would you trust an identity and access system when the company does not even use it internally?

3. In general, there are quick buttons and template to do it if you don't want to worry about it, in the LLM age, this gets easier. Personally I prefer this because I intensely dislike "magic". This allow you to control, to the maximum degree possible, what is actually going on, despite not owning any of the physical aspect of the data center.

1. It's about imposing worst-case complexity on the 99% of people who will never benefit. 2. Some of that complexity only arises because of the dogfooding 3. No it doesn't get easier, because you still need to understand what those things actually do to know if they're right for your use case, and besides if you're driving everything from terraform then having a "quick button" is precisely useless.

We had an AWS rep try to sell us on an AI tool to help with predicting the IAM permissions that our infrastructure code needs. My response was, essentially, "why have you built a deterministic system so complicated that it needs an AI to configure correctly?" I have not had an answer.

That's all fine and good, but I still don't know how much trust the EBS team versus the ALB team.

And I don't think you do either.

You don't need to trust EBS or ALB team. You just have a contract that says whether ELB/ALB get access to your data/resources or not.

Also the access are not "team", it's software. The control plane would have access to resource if you granted the service principle and then it would go ahead to do what was already written as service logic for those resource. The engineers do not gain access to your resource now - all prod service principles are access gated and we can only see certain non-PII logs as required by operational events. We don't run the service manually.

>I kinda just expect it to be all “AWS” trust.

This would be very unwise from security standpoint. Internal access to customer stuff is granular and made hard for internal staff to gain, to minimize chances of screw up intentional or not.

I agree. Adding a service principal always raises an eyebrow for me, just a blanket "hey we're aws trust me bro" is a little bonkers.

How does this work in Azure and Google Cloud?

One thing i would like to see in IAM would be sonething like verb actions, currently, if you want to give least privilage, you have to trial and error your api call until you get it right. Since aws have a very good api definition on all consumers (rest, aws-cli, boto uses same strucyure), i think it would be doable.

I mean something like actions: s3:cp Resource: bucketarn/key

Most of the time, actions are self explanatory and good enough, but i recently gave a developer permission to scale an asg, and it required a lot of unguessable actions, if i were to give "actions: scale" (forgot the correct cli parameter for it), it would make more clean env

Reply on news.ycombinator.com