rhatdan
General Comments - Simo
I do not have specific changes to the document, but more of an overall set of questions/comments, hopefully it is ok to discuss them here.
So we are discussing about RBAC here, and Roles and Permissions are more or less explained, however I see some lack of discussion about how they are actually enforced on resources.
For example the document separate permissions into "global" or "per image/container" permissions. Now the global ones are clear in intent and it is obvious (on a light read) what they apply to. However the per-container permissions do not define how User X with Role Y is related to the specific containers A,B and C.
Usually there are grouping mechanisms that allow to apply roles to subjects. It is particularly important (IMO) in this case as it seem that Roles are all powerful and apply to all containers, which is why the document then go around thinking about costraints because it is clear that global roles make little sense. Yet a constraint (which is very worringly similar to a DENY rule in a ACI-speak) would not be necessary if instead Roles are assigned to specific groups of resources instead.
If you think about resource groups you can also basically drop the developer versus operator role which is somewhat anachronistic in a "devops" world.
So if you have "developer containers" and "operation containers" (if something like that makes sense) then you only need a set of progressively more powerful admin roles and no distinction between developer or operation. A developer could be the docker admin for developer containers and can't touch in any way the operations container unless it has a role for those too, which could be "basic operator".
Put in another perspective you could be an advanced operator for the "backend containers" group where you are a lead devops, while you'd be a basic operator for the "fronted containers" group which is operated/developed by a different group and you only are given status access to check if your backend modifications caused trouble, and so you can restart a frontend once you rollback your backend change or similar.
This is just an example, but makes for a much more powerful model than a global role type + constraints.
The cost is that of defining different groups of resources and then have users belong to a role tied to those resources and not just global.
