Introduction
Otterize is a organization that provides open-source CLI tool and a cloud-managed platform for managing kubernetes policies in a client-centric manner. In a nutshell, instead of mapping network policies depending on the CNI that you’re utilizing either Cilium, Calico, or Flannel this will alter the normal syntax you can put Intent-based for the workloads of access control. How does this help me? Well in a number of ways this simplifies what is typically a nuanced of crafting YAML manifests depending on how your managing your network policies from a open-source perspective. This also makes mTLS for workloads relatively seamless in implementation.
Otterize Installation
For this blog post, I’m leveraging killercoda.com playground for simplicity to get up and running on your browser if you’re following along the following is installed.
Requirements
- Kubernetes Cluster 1.28 (3 nodes)
- Otterize installed/CLI
- Cloud Account with Otterize (Free)
Navigate to app.oterrize.com and select Connect Cluster this will have inputs you can put into the wizard and outputs should look like the image below ensure you have the toggle Enforcement mode: active.
Once you run this in the UI/Otterize Cloud system you should see that it states connected and loading your network map.
If we run a kubectl get pods -n otterize-system this should populate our workloads that are running for this connection along with the status should reflect running before the visual will show up.
If we reference back to our UI/Browser we can see we can have a separate environment centralized along with multiple namespaces showing the number of services.
Navigating back to the Access Graph this will visually look like the following with multiple visuals from our cluster along with if the server or client is represented as unprotected/would be blocked.
Similarly if we want to drill down to the context a pop-up will populate for visual viewing along with the client intention pre-populated with YAML.
Navigate back to our command line we can use this YAML to create the intents stating we want our service otterize-istio-watcher to call the service otterize-network-mapper what makes this unique is this is simple to understand to the administrator/ops team to know what services talks to what.
Our visual now changes as this is updated on the cluster and quickly responds to the visual showing protected now from this application of this manifest.
Additionally I’ve deployed a workload from the documentation to represent the Istio HTTP-level access mappings shown below are from installing istio-base from helm along with a demo.
Let’s say you encounter a moment where you want this visually from the CLI you can generate that with the following command with otterize CLI.
otterize network-mapper visualize -n <namespace> <filename>.png
If we open this graphically if your on windows you should have your WSL on computers section along with navigating to the directory should be familiar or if I was using my IDE you can visualize from that area as well depending on the IDE.
Using this we will store this in a YAML manifest and apply to our cluster to further visualize this process further if you’d like. I’m going to run the Istio Authorization Policies demo further by deploying resources and watch the changes in the UI.
If we open a new terminal after our resources are running we can tail the responses.
kubectl logs -f --tail 1 -n otterize-tutorial-istio deploy/client
If we tail the other workload our response shows forbidden due to our intentions enforcement.
kubectl logs -f --tail 1 -n otterize-tutorial-istio deploy/other-client
Notice this will reflect the age of our authorizationpolicies that is applied to our namespace otterize-tutorial-istio.
If we inspect our pod other-client we can see what the intents.yaml file applied a label that tells the service what is allowed/not-allowed from this label.
Summary
Otterize Seamless offers an intuitive and user-friendly approach to network policies, enabling teams to effortlessly create service connections. This tool is particularly beneficial for Kubernetes administrators and security teams, providing a quick start guide to demonstrate its capabilities. Currently, it supports major platforms like Amazon Elastic Kubernetes Services, Azure Kubernetes Service, and Google Kubernetes Engine, with the only requirement being the Calico CNI. Otterize’s commitment to innovation is evident as they expand to include other certificate services like SPIRE supported and otterize-cloud can also issue certificates.