4 ms·

What specifically do you have issues with when it comes to IAM? It’s a complicated tool for sure, but it comes from the natural complication of dealing with a

What specifically do you have issues with when it comes to IAM? It’s a complicated tool for sure, but it comes from the natural complication of dealing with auth in a very flexible way.

killingtime74 5y ago
Probably learning curve
rhizome 5y ago
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.
lazide 5y ago
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.
- OJFord 5y ago
  > 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.
  - lazide 5y ago
    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’ Does that make sense?
    - OJFord 5y ago
      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.
      - lazide 5y ago
        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. Tokens can do that.
        OJFord 5y ago
        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?

What specifically do you have issues with when it comes to IAM? It’s a complicated tool for sure, but it comes from the natural complication of dealing with auth in a very flexible way.

killingtime74 5y ago

Probably learning curve

rhizome 5y ago

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.

lazide 5y ago

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.

OJFord 5y ago
> 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.
- lazide 5y ago
  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’ Does that make sense?
  - OJFord 5y ago
    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.
    - lazide 5y ago
      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. Tokens can do that.
      - OJFord 5y ago
        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?