0:00 Introduction

0:00 Hello, and welcome back to the Rawkode Academy. I'm your host, David Flanagan. Today, I want to introduce you to a relatively recent open source project that is going to change the way you handle your Kubernetes networking policies and more. That project is called Otterize. It's got a complete evolution on the way that we configure networking access within our clusters using something called iBack, intent based access control. And we're gonna dive into what that means in just a moment. Now like I said, Otterize is different. It isn't a service mesh. It doesn't change your pods, inject in proxies

0:40 How Otterize Works (Not a Service Mesh)

0:46 and sidecars to order to control your traffic. Instead, it integrates with Kubernetes, Kafka, Istio, configuring the tools that you're already using in your cluster, but providing a better DX to allow you to do that as a dev team. To understand more, let's dive in to what iBack actually means. So here we have the Otterize website. You can find us at authorize.com, and the page we're looking at right now is the iBack page slash iBack. Now intent based access control is a declarative way that allows you to define which services are allowed to call other services within your

1:24 Explaining Intent Based Access Control (iBack) in Detail

1:33 cluster. Traditionally, the way that this would be handled or at least what I've seen from working with many organizations is that the developers don't focus at all on security or policy. Especially in a micro service environment where teams are responsible for one or more services, they really only flow together enough YAML for a deployment and a service within the cluster. All of the security and policy happens from some sort of SRE, DevOps, or platform team, or if your organization is lucky enough to have one, a security team. Now this means that we have a violation

2:03 The Problem with Traditional Security Policy Management

2:12 of the law of demeanor. The law of demeanor really just means that we don't want leaky extractions. We don't really want our security platform DevOps teams to have to understand the entirety of a microservice architecture to be able to put together these security policies because inevitably, they're gonna get it wrong or it's just gonna be a lot harder than it should be. And if we're gonna provide a declarative way to define all of this access, why not allow the developers to do it? Picture this, you're working on a service. You write the code that makes a network

2:45 iBack and the Concept of Intent Files

2:48 call. It wants to speak to Kafka, consume a topic, publish to a topic, or perhaps even make a gRPC or HTTP request to another service. You wrote the code. You know what the intent is. You intend for your service to communicate or speak to another service. So why not log those intents inside of your repository right next to your service? And that's what iMac wants to change. Using something called the intense file, which is really just a Kubernetes resource, a custom resource. You can see that my service, using this example here, the checkout service, calls these other services.

3:34 Now where this extends beyond what we're familiar with with traditional Kubernetes networking policies is that there's some l seven awareness baked into what Otterize can do. So you can see here that we define the HTTP requests are allowed on this path with these methods. Taking us even further to something you can't do with network policies in Kubernetes is here we have a Kafka intent which allows us to produce messages, write messages on a topic called orders. This is very fine grained ACL that needs to be configured on the Kafka broker itself, and Otterize can make that happen.

3:37 L7 Awareness and Kafka Intents

4:16 So that's enough chat. Let's get hands on. In this demo, we're going to install Otterize. I'm going to show you how to add enough intents for Otterize to create Kubernetes network and policies for you. Otterize allows you to ease in to use an Otterize, and we'll take a look at how we can run Otterize in shadow mode and enforcement mode Before finally taking a look at Otterize Cloud, which will allow us to visualize and build a map topology of all of the services and their access permissions within our cluster. Let's dive right in. Okay. So let's install

4:54 Install IBAC

4:55 Otterize into our cluster. Here, we have the Otterize organization on GitHub with a repository called HelmChart, which, you guessed it, has their HelmChart. Right now, we are gonna focus on Otterize Kubernetes. This will actually install all the other charts into your cluster, given your complete authorized deployment. Just to cover what these other charts are, the intense operator is what takes your intense custom resource and creates policies and ACLs with other software running in your cluster. The network mapper just maps the services within your cluster to understand the way the traffic flows and allows you to generate a diagram to visualize

5:10 Key Otterize Components (Intents Operator, Network Mapper)

5:40 that. So the first thing we need to do is add the helm repository, like so. Next, we can install Otterize. Easiest thing I've done all day. Let's just get that two moments and done. Now, we can run, kubectl, authorize system, get pods. And we'll see each of those components spinning up. Let's crack on. Okay. So let's take a look at what's running inside of our cluster. Here we have the Weaveworks Sockshop demo. This is a sample store built with multiple microservices and a whole bunch of services that allow them to communicate with one another. We also have the front end exposed on

6:16 Introducing the Demo Application (Sockshop)

6:39 our load balancer service, meaning we can browse it. We can view products and view the cart. If we click login, we get a dialogue, and if we click register, we get a dialogue. If we open login again, we can type user and password, and login successful. So let's use an authorized intense file to make the communication between these services more explicit. Okay. So let's, first of all, log out. Then we'll jump back to Versus Code where we have an empty intense dot YAML. Gonna paste in an example resource that works for this demo. Here, we define an authorized client intense

7:07 Applying a Client Intent (Front-end to User)

7:34 with whatever name you wish. Of course, if it makes sense, bonus points. We then define a spec where we say that we want to specify the intents for the front end service. The front end service being the application that runs on our browser, the web app, which is likely going to call pretty much every service. But right now, we're only gonna make explicit that it calls the user service. So we can come to the CLI and apply our intents dot YAML. And what's going to happen now is that the intents operator is gonna detect the custom resource

8:09 Inspecting the Generated Kubernetes Network Policy

8:13 and create a network policy. We can describe that network policy, and we will see that it specifies a pod selector where the server is user SockShopE8BOA2. It then has an allow ingress from a pod selector where there is a label which allows access to user stock ShopEBBOA2 true. Now the intense operator behind the scenes is resolving the service names and our client intents and allocating the labels to facilitate the traffic. If we jump back to the web browser and hit refresh, saying we wish to log in, it works. Now, of course, all we've done is allow

8:58 Testing the Initial Policy (Login Works)

9:16 traffic. We haven't blocked any traffic. So let's head back over to our intents.yaml where we can add a protected service. Here, we're going to see that this user service is protected, which means all traffic that doesn't have an intent will be blocked. We can now come back over here and apply our updated intents dot YAML and run NetPol again. We'll now see that three seconds ago, a default deny user network policy, which does not allow any ingress, targets, user service. We can now come back over to the sock shop where we can ask it to log in.

10:04 Testing with Protected Service and Intent (Login Still Works)

10:14 Success. So let's make one more change. We're now going to update our front end intents and instead of the user service, we'll see that it's allowed to communicate with the order service. Our network policies will now be updated. We now have access to orders from Sock Shop and still are default to die on a user service. Meaning, we come back to log in for the third time. No success. That's because our browser is now unable to communicate with the user service To the point where we've crashed the Weaveworks sock shop demo. Let's come back and add another service

11:19 Restoring Intent and Access

11:23 for our front end to speak to the user service. We can add a kubectl apply and tense. Get net pull and try to log in again. Success. So let's protect one more service. We'll copy our protect service and paste. This time, we're going to protect the catalog service. Now no client intent specify that they call the service. Meaning, we will get a new default deny network policy for the catalog service. So let's come back here and refresh the sock shop. And as you can see, most of the services are working, including login and logout. However,

11:52 Protecting Another Service Without Intent (Catalog)

12:32 there are no products available on the homepage. And that's how intent files and protected services work with Otterize. This two phase approach to defining how your services communicate means that you can adopt Otterize step by step. You can add all of your client intents without ever breaking any traffic within your cluster. As you have comfort that your intents cover most of your traffic or all of your traffic ideally, you can begin to protect your services one by one. Now there is a better way to do this using Otterize Cloud. Let's take a look. Otterize Cloud is a

13:24 Use Authorized Cloud

13:26 SaaS product with a very generous free tier. This should satisfy most of you watching this video. The benefits of using the cloud and the Otterize provide visual understanding of your intents and the enforcement. So let's log in. The first thing we need to do is connect our cluster. We can give this a name like so, and we'll call this environment production. This gives you the helm commands that you need to run to connect to Otterize Cloud. I'm saying no to authorize already to be installed on my cluster because I did a helm delete prior to this step.

13:45 Connecting Your Cluster to Otterize Cloud

14:17 But if you do have it installed, it's fine. Authorize cloud is just a value add on. We also get to decide whether we wish to be in enforcement mode or shadow. We're going to leave enforcement mode off. This means we'll be using the protected service custom resource that you've seen a moment ago. Of course, if you wish to delete enforcement mode, the protected services will not be required. Let's copy the helm install command. Like so. We can now see that our network mapper, the intense operator, and the credentials operator will begin to say connected. Some may take longer than the rest.

15:13 If we pop over to the CLI, we can run get pods. When all of these are running, we will have a visual topology map of all the services running in our cluster. Let's come back in a moment. So here is the access graph. This shows us the services within our cluster and the communication patterns as well as whether the access would be allowed or denied. We can see the front end wants to speak to orders and user. User is protected, and the traffic is allowed. Whereas our front end, currently traffic is allowed, but that's because the service is unprotected.

16:04 Discovering Real-Time Communication with Network Mapper

16:04 Now this only shows the services that have client intents, but there is a network mapper feature of Otterize. So let's go browse around the website just to give it a little traffic to analyze and jump back to our access graph. And already, we can see services popping up within our cluster. So let's filter on our SOC shop namespace. And we can see now that our front end speaks to cars, user, orders, catalog, session DB. Our queue master speaks to rabbit and our catalog speaks to the database. The orders has its own database. The user has

16:59 a database and the cart has a database. We can now see all the traffic scanned by Otterize. So we can see at the moment our front end is not allowed to speak to catalog because we protected the service without an intent. And now our catalog currently can speak to its database, however, is because it's an unprotected service. So let's change that. Let's add that our front end speaks to the catalog and also allow our catalog speak to the catalog DB, like so. Now the catalog is the only service that speaks to the catalog DB, so we're gonna protect that too.

17:28 Updating Intents Based on Discovered Traffic

18:09 Like so. Now, we do a cube control apply, intense. And if we come back to our access graph, in real time, it's going to reload and show us the changes through our intents and our protected services. We can now see that our front end speaks to the catalog and just protect it, and the catalog speaks to the catalog DB, and it's also protected. The ideal situation. But what about the rest of our services? So here we are in the command line again. And you'll be pleased to know that Otterize have a CLI. The CLI allows you to work with the network mapper

18:53 Using the Otterize CLI for Network Map Export

19:09 where you can list all the services and the communication. You can even visualize setting an output path like so. We can now open our PNG and get a visualization of everything without Otterize Cloud. But I think we can all agree the cloud's a bit nicer. So let's run network map export, which dumps out all of the YAML that you need to map your intents and overwrite our intents dot YAML. We can now apply this directly to our cluster, and we can ignore the intents that already exist. Let's come back to our access graph, which will reload in real time.

19:45 Applying Full Discovered Intents YAML

20:21 Now all the warrants disappear, and we can protect the services that we wish to protect. And that is pretty cool. So I hope you have enjoyed what you've seen. Otterize is pretty sweet. It's an open source project that allows your developers to write client intents next to the code itself. Services could be protected or enforced by default. You can use the network mapper to scan your cluster as it is right now and export a huge amount of YAML into your repository. You can visualize it with the CLI or who can to authorize cloud for that nicer experience.

20:32 Conclusion and Next Steps

21:07 So go check it out. Until next time, have a great day.