In this video, Dean walks through Hubble Enterprise Role Based Access Control (RBAC), which enables the delegation of network observability between platform and application teams. Introduction In this video, we're going to cover the Hubble Enterprise role-based access control feature that provides role-based access control not only for the Hubble CLI, whether we're speaking to Hubble Relay or Timescape, but also for the Hubble UI as well. In my demo environment, I've already set up my OIDC provider, so when I go to my Hubble UI web address you can see straight away that it's asking me to sign in with my OpenID Connect details. So let's do that now. We're going to log in as admin at example dot com. Once I've logged in, I can see all of the parameters that I have access to, all that data as well. If I click through flows, because I'm the administrator, I can see all of the namespaces as well. One of the things that you will notice when this is set up is that in the bottom-left-hand corner you can also see the username being added. Configure Hubble RBAC If we move into my Visual Studio Code editor, let's have a look at some of the configurations that make this possible. From a Hubble Enterprise point of view, we're setting up in those Helm values the RBAC configurations. We're ensuring that it's enabled, and we're setting up where that OIDC is configured. In my environment, I'm using Dex today, and I've actually configured this using self-signed certificates just to make my life easier, so we've also had to provide where they are for the trust chain as well. The other meaningful configuration that we have is the policy settings. This sets up the user access to that API. When we create this Hubble Enterprise, we read that policy information from a ConfigMap. That ConfigMap can either be created as part of your Hubble Enterprise installation, or you have the ability to provide it out of band, but if you do that then the Hubble Enterprise pods will sit in an initialization status until that ConfigMap is available. One of the other specific callouts for setting up RBAC is that you will need to enable TLS between your Hubble components as well. From a policy point of view, going back into that configuration, we set up the bindings themselves. We set up role names, and we set up how they apply. With my Dex configuration, you can see that we're applying this to the email addresses that users send in, and then the role specification defines the name of the role, what the rules are, what actions are available on the data itself, and what kinds of object types are available. We can see here that my admin role has access to absolutely everything. For a demo user, we've got access to pull the data using get for a particular namespace. Configure RBAC access So actually what I'm going to do in my environment is look at this new values YAML file that I've set up in my Helm install. I've actually created a new user in my Dex environment called tenant-jobs-dev, and we're going to specify a new binding for that email address. Inside of that role, you can see that we're going to give access to flow data in the context of the namespace values. If I wanted, I could even give it additional namespace access as well, just by creating an additional value there. So let's upgrade my environment. Now that's gone through, let's have a look at where it actually creates that configuration. We create a ConfigMap in the same namespace where Hubble Enterprise is installed. The data inside that ConfigMap is the Hubble RBAC policy YAML, and in this case I was taking that from the Helm install values file. Hubble RBAC observability Let's go back to my UI now. I'm going to give this a quick refresh, and I'm now going to log in with my tenant-jobs-dev account. I've logged in. I can still see Hubble as the overall platform, but if I click on flows, we can see I've only got access to a single namespace. We can see the same information that we expect to see, but only for the part of the system that this user is allowed to access. What actually happens if we move back into the CLI? The UI is not the only way to consume this data. The first thing I'm going to do is log into the environment. Because I'm using that self-signed certificate, I also have to tell it where the CA is so it can trust it, and provide where my issuer is to log in as well. I'm now going to log back in as that tenant user, and we can see now that I'm authorized. The first thing I'm going to do is set where my Hubble server is with an export command. I'm port-forwarding to the Hubble Relay at the moment, but because we rely on TLS to enable the RBAC feature, I also need to set it to speak to the Relay server over TLS as well. The first thing I've got here is because we already know from the UI that I don't actually have access to any namespace other than the tenant-jobs namespace, I'm going to try and pull data from a different namespace. For the Hubble observe command, I'm filtering on the kube-system namespace, and we can see here that permission is denied because I don't have access to it. Let's run another command in the tenant-jobs namespace, and as you can see I get data back because I do have access to that. Very quickly, what we're actually going to do here is log out, log back in again, and authenticate as that administrative user again. We're authorized again, and let's just make sure we can access that kube-system namespace again, which we can. So just to round off the end of this demo, I've shown you how we access and set it up at the Hubble Enterprise component level, which is where most policies live. From a Hubble UI point of view, we set up our OAuth configuration so we can set the allowed domains, where our issuer is from, where to redirect back to, and also the provider CA details because I'm using self-signed certs in my environment. If I go to my Hubble Timescape values, because Hubble can be deployed standalone outside of the cluster where Hubble Enterprise is running, you also have a full RBAC policy mode for Timescape as well. Conclusion As you can see from these Helm values, the configuration looks very similar to Hubble Enterprise: setting that same ConfigMap, setting bindings, and setting the roles in place. And that wraps up our very short demo on the Hubble Enterprise role-based access control page. Thank you very much.