Working with RBAC "ON"

1

I’d like my mesh as secure as possible, and I have a couple of questions (based on the stance taken by the bookinfo examples)

  1. Access to the front-end service (productpage) is allowed from any user. However this isn’t “direct” internet traffic - I changed the rule to allow from “cluster.local/ns/istio-system/sa/istio-ingressgateway-service-account” and it still worked, and was presumably more secure.

  2. I then changed RBAC from ‘ON_WITH_INCLUSION’ to ‘ON’. This denied access, which I assumed was enforcement of traffic hitting the ingress gw from the internet. I added a Role for service istio-ingressgateway.istio-system.svc.cluster.local and a Binding to users “*” and that fixed it.

I guess my question is: why is this not the default stance? Why is RBAC ‘ON’ documented nowhere (unless I’ve missed it?). Even if all-namespace RBAC is a bit annoying, step 1 seems like an obvious thing to do?

2

I take that the example you went through is here https://istio.io/docs/tasks/security/authz-http/.

If RBAC is ON, it will enforce in every service and namespace in the mesh. RBAC ON WITH INCLUSION only enforces on specified services and namespaces. We document RBAC mode here https://istio.io/docs/reference/config/authorization/istio.rbac.v1alpha1/#RbacConfig-Mode

3

why is this not the default stance?

The bookinfo example is a tutorial for explaining the RBAC functionality in the simplest way and is optimized for easy to follow/understand but not for production security or best practices.

Why is RBAC ‘ON’ documented nowhere (unless I’ve missed it?).

You can find some documentation from link Phillip mentioned, you can also take a look at here: https://istio.io/docs/concepts/security/#enabling-authorization

Even if all-namespace RBAC is a bit annoying, step 1 seems like an obvious thing to do?

We’re working to improve the user experience of the Istio security policy (mTLS, JWT, RBAC) and I’ll soon share out a design doc about this topic to the community.

One of the improvements is to revamp the documentation (others are like better monitoring/metric/tooling/testing/etc), including adding best-practice and example policies for use case for reference. Hope this would improve the issues you mentioned so far, thank you!

1 Like
4

Thanks for your detailed reply! Yes I think some more comprehensive docs would go a long way - some description of the ideal setup and how to achieve it, and YAMLs to implement that for Bookinfo (even if they’re not used on the golden path through the tutorial). For example, RBAC ‘ON’ is documented insofar as we’re told it exists, but there’s zero help to get your mesh working again after you enable it; I had to know quite a lot about Istio and reason about it from first principles.

Thanks for your replies, I now know I’m not going mad!

5

Thank you for your feedback @mt165. We’ll take this into consideration next time we’re updating our doc. You can also contribute to our doc site at https://github.com/istio/istio.io :slight_smile: