 Hey everyone, this is Jim Beguaria from Nirmata, and I'm here with Adrian Ludwin from Google, and we're going to talk about namespaces as a service using HNC and Kivirno. So in Kubernetes, namespaces are a fundamental building block for segmentation isolation, and a number of other Kubernetes resources, such as roles or role bindings, secrets, quotas, all of these also build on top of namespaces. And Kubernetes is used within an organization, and every organization of course is looking to deliver value faster to their customers, to increase efficiencies, multi-tenancy very quickly becomes important as a way of achieving some of these goals. So there are two common ways that multi-tenancies typically delivered within organizations, either using clusters as a service where entire clusters are created for application or per team, or using namespaces as a service where a shared cluster is used, and different teams, different apps can leverage namespaces. So each model has different pros and cons. Namespaces as a service is slightly less flexible, because you cannot have cluster-wide resources per tenant, but there's a lot of value in utilizing namespaces as a service for agility, for increased efficiencies. So today what we're going to see is how HNC or a hierarchical namespace controller and Kivirno work together to deliver namespaces as a service for organizations. So I'm going to talk a little bit about HNC itself. So as the name implies, what we're doing is we're taking existing Kubernetes namespaces and making them hierarchical. Now why would you want to do this? Namespaces, as Jim said, are fundamental to a lot of different areas, but they are also cluster-level resources, and by default are completely independent from each other. This does not make them very useful within any kind of level of tenancy, because you need cluster-level permissions to modify them, and it's hard to apply policies across a set of namespaces. So with hierarchical namespaces, you can arrange them into a hierarchy with an arbitrary depth, and you can modify that hierarchy over time with enough permissions. What this allows you to do is it allows you to propagate policies from parents to children, and also it lets you do some neat things with applying policies, such as network policy across a group of related namespaces as well. And there's a bunch of other talks online that you can find about this. Another thing it lets you do is self-service namespace creation. So typically, you need cluster-level permissions to create a namespace, but with HNCU, you can create a small object called an anchor in the parents, which we'll demonstrate later, and HNC will create the subnamespace for you, and then automatically propagate all of the configured policies as well. So why would you use this? Well, it's great for really fine-grained namespaces. If you just gave every tenent one namespace and said, well, okay, here's your playground, you can do everything in there. That can work, but it doesn't allow you to differentiate between different security policies that might be applied to different workloads that are run by that one tenent. And so with HNC, you can write composable multi-namespace policies where you need, and also apply workload-specific policies where those are required as well. And also it's useful for self-service namespaces anytime where you wouldn't want to file a ticket for a cluster-level operation. This can be very useful in dev clusters or in clusters that use for things like batch operations. Now HNC on its own can't really provide namespaces as a service, because if you create a new top-level namespace, it's completely empty, there's nothing in there. And when you create a subnamespace, it only propagates objects from the parent. So for example, you can't put a quota in a shell that wasn't defined in a parent. But with Coverno, you can use its generation and mutation capabilities, which can execute actions when you create a new namespace or subnamespace. And the two of these together can give you a big piece of the namespace as a service picture. So very briefly, Coverno is a policy engine designed for Kubernetes, where policies are just modeled as Kubernetes resources itself. There's no new language to learn, so you can use familiar YAML syntax, very similar to customizes overlay patterns, which you can use to define your policies itself. And with Coverno policies, you can validate configurations, you can also mutate existing configurations and generate new resources as required based on different triggers. So what we'll take a quick look at in a demo is Coverno managing the top-level namespaces and then HNC working to create the subnamespaces and propagating resources within that hierarchy itself. So let me switch to my console. And what I have here is HNC and Coverno are already installed. And if I look at the HNC setup, I'm going to use the HNS command line plugin and describe the configuration. I already have it set up to propagate different resources like network policies, role bindings, and roles. So the first thing I'm going to do, and just before they're kind of explained the setup I have, I've created a couple of custom roles. These roles can only create namespaces and they can only operate based on Coverno policies. They'll get fine-grained permissions to only operate on their particular namespaces itself. So I'll go ahead and create, try to create a namespace called test. As a user, one of the namespace admin users, Nancy, and Coverno is going to block that and say that the namespace needs to have a label which designates what kind of resource quota it requires. So to go ahead and create this, I'm going to now use a YAML I already have with the necessary label. And in fact, what I should do is I'm going to create this as the right user. So I'll delete that namespace which I created as an admin, and we'll go ahead and create it again as the user, Nancy. So let's try that again. OK, so now that the namespace is created as the user, if we go ahead and describe the namespace, what we should see is that the properties for that namespace, so we create a test. So it already has the resource quotas, it has the limit range configured, and it should also have, if we do, a get for the network policy on that namespace as that user, we should see that we're allowed to see that there's a default deny network policy, and as that user, we have visibility into it. Now, just as a quick test, if I try this as the other user, I'm not allowed access to it. So now let's go ahead and create a subnamespace using hnc. So I'll use the hns plugin, and for that user, I'm going to create another namespace called test2undertest, and we'll also do this as the namespace admin user, Nancy. And so this creates the subnamespace, and just to see how that's set up, if we look at that as Nancy, we should be able to see the tree, and we should also, again, just to verify if we try it as the other user, we're not able to see that. And if I do describe on this, on test2, which is the other namespace, I also see that the right resources are propagated. So this is just a really quick demo, which shows how the two tools, again, can work together to solve some of the main problems for namespaces as a service. So just to summarize, multi-tenancy is essential for most organizations for community success, and namespaces as a service is a handy way of providing multi-tenancy for a large segment of applications, and hnc and Qverno can work together to automate some of the key concerns for namespaces as a service. So please reach out if you have more questions. We are on the multi-tenancy Slack channel, on the Qvernity Slack, and I also have some, we have links here for the repos for hnc as well as Qverno. And if you want to learn about hnc, you can go check out some past talks that we've given at QCon over the past year or so. Thanks a lot.