Production: where very few users have access, tight control, etc.
Dynamic: where anyone can set up and tear down their own environment.
I put X in Production, and Y in Dynamic. I give everyone - devs, product managers, customer support, anyone at all that I want to access to the “Dynamic” environment, and put our internal app in the Catalog. Anyone can spin up a stack from the catalog of any version they want in Dynamic, and have their own environment until they tear it down.
But I don’t want someone messing with hosts in the environment, or tearing down someone else’s stack.
Have user permissions and access control gotten to this level, or not quite yet? And if not, is there a better way to do it?
I had thought about environment-per-user, but then I have the problem of sharing hosts, and they still can mess up those hosts.
You can give someone “Restricted” access to an environment, which would prevent them from messing with the hosts, but anyone in an environment would be able to tear down someone els’s stacks.
Thanks @denise. I know that it has slowly been improving, from “full access” to read-only users, now restricted users.
If I had the time, I would look at the code myself and submit a PR, but that is not what my client pays me for. Besides, still got open PR on RancherOS.
Think of the use case. This would be the first fully self-service. Admins can control costs by setting up and limiting the number of underlying servers in the environment (which is the real cost driver), while allowing anyone authorized to run as many stacks as they want from the catalog, even seeding data, without them negatively impacting anyone else.
I have a client right now who would love that. I was hoping to show them Rancher for it. I can still do it with the API, but lots of extra work to build it for them.
@deitch Yes, we intend to get more detailed RBAC at one point.
Also, here is a specific RBAC use case that someone else had filed.
If you have a specific use case, feel free to open a new issue and I can link it to our general RBAC issue.
Also, now that v0.5.0 is out, we’ll definitely look into the PR you made for RancherOS! There was a lot of refactoring that occurred for v0.5.0, so we weren’t able to add it into that release. I’ll try to see when the team would be able to look at it.
Yeah, it is similar. But I am talking about resource-based access control, which is a level above role based access control (and unfortunately both use the same acronym RBAC).
Right now, Rancher has coarse-grained RBAC: A user can be admin, or read-only, or stacks-only (“restricted”). Those are roles. But a stacks-only role still means I can set up one stack and tear-down another.
Resource-based not only has a more restricted role: I can set up stacks but not tear down other stacks, but I am also granted access control based on the resource. Since I launched stack C, I am the owner of stack C, and so I can tear it down. But stack B was set up by Denise so I cannot touch it (maybe not even see it).
Resource-based is where roles are applied based on the specific resource.
As for RancherOS v0.5.0, definitely. Make the comments on the PR there, and we can get the UEFI boot working, and then ros install.
