Self-service constraints when combined with ACLs
-
This is a follow up question to the one I posted on ACL inheritance for network objects.. Essentially, when building a self-service resource set, it isn't obvious whether the included resource set is supposed to override any ACLs, or work in tandem.
For example, if I grant "viewer" rights to the pool, why do I need to provide a set of read-only templates, read-only networks, and read-only SRs? It seems to me that the ACLs should take care of that, and the SS should cover anything I need to provide additional operator or admin rights [i.e. read/write SRs, etc.] (in fact, I don't even know what rights the SS resource set actually confers -- is it admin/operator/something else?)
I feel like I have a fundamental misunderstanding of ACLs and SS. Coming from vSphere, I am trying to emulate an inherited DAC permission model, but the XO ACLs seem too limited (I think having an explicit "deny" ACL would dramatically help here by allowing permission "hole-punching"), and the SS isn't dynamic enough.
Can someone help shed some light on how ACLs and SS work together, if at all?
-
-
You should have kept on thread, it's easier to track. Anyway, another ping to @pdonias
-
This is essentially why I said in the other thread that "Self Service and ACLs weren't designed to work together"
To keep it simple: Self Service will indeed allow some users to see and use some resources even though they don't have ACLs for them. Then, when they create VMs, it will automatically assign ACLs on the objects under the hood. That's why, even though it's not impossible, most of the time it's not recommended to use them together since you might override ACLs that Self Service assigns automatically.
We're actually starting to think of a redesign (or at least improvements) of those 2 features so feedback is very welcome about any use case that you might have that isn't covered by them at the moment. I already took note of the "dynamic" need for resource set objects.