Not the parent, but IMO it is an awkward way of thinking of permissions in an automated environment. It fits a human model much better, where you have a long lived entity which is self contained and expected to be trustworthy. Alice should have access to all finance data in this bucket because she works in finance, or Bob should be able to access these EC2 instances because he admins them.
It causes weird and overly broad privileges though usually, because you need to give permission to do any possible thing the job or user of the credentials COULD need to do, all the time.
This happens because any action to limit the scope usually causes more human friction than it is worth.
Ideally, when it is requested they do something, they get handed a token for the scope they are doing it in, which only gives them access to do the specific things they will need to do on the specific thing they need to do it, and only for the time they plausibly will need to do it for. This is a huge hassle for humans, and adds a lot of time and friction. For machines, it can be as simple as signing and passing along some simple data structures.
So for example, Alice would get a token allowing access to Q4 ‘20 only if that was plausibly correct and necessary, and then only for how long it took to do whatever she was doing. Bob would only get a token to access the specific EC2 instance that needs him to log into it because of a failure of the management tools that otherwise would fix things - and only after telling the token issuing tool/authority that, where it can be logged.
It makes a huge difference in limiting the scope compromises, catching security breeches and security bugs early on, identifying the true scope and accessibility of data, etc.
Also, since no commonly issued token should probably ever provide access to get everything - where the IAM model pretty much requires that a job that gets any random one thing, has to be able to get ALL things, then you also end up with the potential for runtime performance optimizations, since you can prune in advance the set of possible values to search/return.
You can model this with a combination of explicit conditions and principal/resource tags. You also can apply a specific custom policy with every role assumption that can be both time bound and more restrictive than the role policies themselves. All IAM stuff is also very heavily logged.
But overall I’m not sure constantly reaching out to IAM to retrieve scoped permissions for every single action makes much sense. Aside from the obvious latency issues the master set of credentials needs to have permissions to be able to request these scoped time-bound keys, and so them being leaked is just as bad as they can be used to just re-request access to “Q2 data”. Ok, so we need some logic to say “Alice should only be able to request these keys once a day” or some such, and these arbitrary requirements are much more complex to implement and a lot more fragile.
So it only makes sense if you’re expecting it to be materially more common for a service to somehow leak these time-bound single access keys but not leak any other credentials. Which isn’t an assumption that would hold up I think.
> It causes weird and overly broad privileges though usually, because you need to give permission to do any possible thing the job or user of the credentials COULD need to do, all the time.
Not really, unless you mean it needs permission to assume all the roles it could need in order to have the permissions it requires.
That is exactly what I mean. A web server that makes database requests needs permission to do any query a web request would need to be able to trigger - not just permission for the specific query that makes sense for the specific request it is serving at the time.
It’s the difference between ‘can query the database’ and ‘can retrieve user Clarice’s profile information because she just made a request
To the profile edit page’
Yes, I understand, but the point I'm making is that it does support 'roles', 'assuming' them for a period of time, then dropping those privileges again, or 'assuming' a different one, etc.
The 'because' isn't there, but I'm not really sure what that would look like, at least in a meaningful (not trivially spoofable) way.
But no one is creating a role
For read, modify, write for every distinct user bit of data no? Or at least I hope not and I doubt the system would function if they tried.
But don't you just move the problem to the token-granting authority?
Don't get me wrong, I do see the hypothetical benefit, I'm just having trouble envisaging a practical solution. Is there something else not on AWS (or third-party for it) that works as you'd like IAM to?
I don’t think you understand my comment? (And the top level comment?)
Your token grantor is just taking in whatever request state you have (session, permissions granted, whatever), and stuffing them into the token that gets passed around. Then the various back ends and client calls also do that, and where there is a permissions check (or conversion) necessary, say on a backend API call to access something, it checks it the callers token has the right permission.
I don’t want IAM to work that way. I don’t want to use IAM for this? It’s the wrong tool.
There are a ton of various signed token frameworks, all with various trade offs. JWT (ugh), Gaia Mint (internal Google), etc.
It tends to work best where there are multiple layers of services, as you have an abstraction layer you can do checking/audits, etc. at.
> a backend API call to access something, it checks it the callers token has the right permission.
Fine, but then that backend handler has permission itself to do whatever it is, regardless of whether or not the token does, since as you said, it COULD need it to service that request?
> I don’t want IAM to work that way. I don’t want to use IAM for this? It’s the wrong tool.
Yes.. I.. agree, I'm confused now why we're even talking about IAM, it's solving a slightly similar problem at a different level; isn't particularly useful here.
Well the use case wasn't clear to me 'up there', I thought you were arguing against IAM in general, or for cases where others do use it.
Essentially I suppose I disagree that it's only good for human users with long-lived roles, but I'm not saying it's the right tool for per-request granular authn, and I'd be surprised to learn that anyone is saying or (trying to be) using it like that. IAM's not even for end human users, (as in of your application) nevermind breaking further down into different types of request from them or on their behalf.
I wasn’t referring to end users? I was referring to admins, employees of the company, etc, which is what IAM is a good fit for.
Using that as the sole way to
Scope process/machine access though IS a weird fit in an automated environment for the reasons I laid out. You either come up with a broad scope that covers everything the job/process/machine could ever need to do or access (and then hope there is no exploit or bug that results in it accessing more), or build something like a token system that lets you get/scope access or permission in the context of the work it is doing on behalf of someone else. Which requires investment, but fits what should really be happening better. That is more of the ‘zero trust’ model, but certainly not all of it.
You answered your own question. "Very flexible" is a plus for Amazon because they can cover everybody's use-cases with a single concept. "Very flexible" is a minus for end users because they only need to take care of their own use-case.
So you can say it's a "natural" complication, and you'd be right, but that says nothing about usability, which is where "issues" tends to come in.
The only limitation is that you don't have all the IAM access rules that you get with AWS.
Oh wait, that's exactly why I love it.