Hi, I have a very high-level basic question: what’s the difference between RBAC and (whitelist/blacklist) policy?
Both are service->service access control mechanisms.
I believe RBAC is enforced by the Envoys (based on IDs from the mTLS SVIDs), whereas Policy is a Mixer thing (requiring “policy” to be on, which causes every request to be checked with Mixer, yes?).
Apart from the difference in config format, what’s the deal here? Is Envoy-based RBAC newer and preferred? Or are the two somehow complimentary?
Hi Matt, I have the same question when I looked at it few months back. I have been recommending folks to use RBAC as it doesn’t require mixer policy checker to be enabled or mixer policy to be installed.
RBAC was added to Istio using Mixter a long time ago, but now all the RBAC related features are enforced on service Envoy sidecar only (as you can see the RBAC concept section and RBAC tasks on Istio.io do not mention Mixer). I’m not sure the story with Mixer here (whether we’re still supporting it or will deprecate soon). @YangminZhu can help answer more since he’s been working on RBAC for a long time.
There’re some feature overlapping between the RBAC and mixer whitelist/blacklist policy, It’s recommended to use the RBAC policy if it supports your access control needs as it has much better performance and there is no concern for single-point failure in the data plane.
In the long term, The mixer architecture is changing to also enforce its policy in envoy. When this is done, the RBAC policy and the whitelist/blacklist may be just converged to a single policy for a better user experience.
So I’m hearing that they’re different DSLs for policy, with the mixer/policy version being potentially more powerful? These APIs might merge soon. The implementation of “RBAC” is preferred but this concern will go away when the mixer -> envoy WASM migration happens.