Skip to main content

Visual tutorial: Kubernetes cluster mapping

To support intent-based access control (IBAC), Otterize OSS starts by providing a network map of a Kubernetes cluster, using the Otterize network mapper running in the cluster. Otterize Cloud then optionally extends this capability with an enhanced visual access graph based on the same information.

When the Otterize OSS intents operator is deployed in the cluster, and connected the Otterize Cloud, the access graph is enriched with access control information, and helps guide the rollout of IBAC in the cluster.

In this tutorial, we will:

  • Deploy a demo set of services based on the Google microservices demo, (a simple e-commerce application) into a Kubernetes cluster.
  • Create an Otterize Cloud account, and install Otterize OSS (including its network mapper) in the cluster, connected to your Cloud account.
  • Visualize the cluster network map in Otterize Cloud.

Prerequisites​

Prepare a cluster

Before you start, you'll need a Kubernetes cluster.

While you won't need network policies in this tutorial, you'll use them in the next tutorial, so you may just want to install them now. Otherwise, feel free to skip that aspect.

Below are instructions for setting up a Kubernetes cluster with network policies. If you don't have a cluster already, we recommend starting out with a Minikube cluster.

If you don't have the Minikube CLI, first install it.

Then start your Minikube cluster with Calico, in order to enforce network policies.

minikube start --cpus=4 --memory 8192 --disk-size 32g --cni=calico

The increased CPU, memory and disk resource allocations are required to be able to deploy the ecommerce app used in the visual tutorials successfully.

Deploy the demo set of services​

To deploy these into your cluster:

kubectl create namespace otterize-ecom-demo
kubectl apply -n otterize-ecom-demo -f https://docs.otterize.com/code-examples/shadow-mode/ecom-demo.yaml
Optional: check that the demo was deployed...

To see all the pods in the demo:

kubectl get pods -n otterize-ecom-demo

The pods should all be ready and running:

NAME                                     READY   STATUS    RESTARTS      AGE
adservice-65494cbb9d-5lrv6               1/1     Running   0             115s
cartservice-6d84fc45bb-hdtwn             1/1     Running   0             115s
checkoutservice-5599486df-dvj9n          1/1     Running   3 (79s ago)   115s
currencyservice-6d64686d74-lxb7x         1/1     Running   0             115s
emailservice-7c6cbfbbd7-xjxlt            1/1     Running   0             115s
frontend-f9448d7d4-6dmnr                 1/1     Running   0             115s
kafka-0                                  1/1     Running   2 (83s ago)   115s
loadgenerator-7f6987f59-bchgm            1/1     Running   0             114s
orderservice-7ffdbf6df-wzzfd             1/1     Running   0             115s
otterize-ecom-demo-zookeeper-0           1/1     Running   0             115s
paymentservice-86855d78db-zjjfn          1/1     Running   0             115s
productcatalogservice-5944c7f666-2rjc6   1/1     Running   0             115s
recommendationservice-6c8d848498-zm2rm   1/1     Running   0             114s
redis-cart-6b79c5b497-xpms2              1/1     Running   0             115s
shippingservice-85694cb9bd-v54xp         1/1     Running   0             114s
Optional: Browse the demo

To get the externally-accessible URL where your demo front end is available, run:

kubectl get service -n otterize-ecom-demo frontend-external | awk '{print $4}'

The result should be similar to (if running on AWS EKS):

a11843075fd254f8099a986467098647-1889474685.us-east-1.elb.amazonaws.com

Go ahead and browse to the URL above to "shop" and get a feel for the demo's behavior. (The URL might take some time to populate across DNS servers. Note that we are accessing an HTTP and not an HTTPS website.)

Create an Otterize Cloud account​

If you don't already have an account, browse to https://app.otterize.com to set one up.

If someone in your team has already created an org in Otterize Cloud, and invited you (using your email address), you may see an invitation to accept.

Otherwise, you'll create a new org, which you can later rename, and invite your teammates to join you there.

Install Otterize OSS​

If no Kubernetes clusters are connected to your account, click the "connect your cluster" button to:

  1. Create a Cloud cluster object, specifying its name and the name of an environment to which all namespaces in that cluster will belong, by default.
  2. Connect it with your actual Kubernetes cluster, by clicking on the "Connection guide →" link and running the Helm commands shown there.
More details, if you're curious

Connecting your cluster simply entails installing Otterize OSS via Helm, using credentials from your account so Otterize OSS can report information needed to visualize the cluster.

The credentials will already be inlined into the Helm command shown in the Cloud UI, so you just need to copy that line and run it from your shell. If you don't give it the Cloud credentials, Otterize OSS will run fully standalone in your cluster — you just won't have the visualization in Otterize Cloud.

The Helm command shown in the Cloud UI also includes flags to turn off enforcement: Otterize OSS will be running in "shadow mode," meaning that it will not create network policies to restrict pod-to-pod traffic, or create Kafka ACLs to control access to Kafka topics. Instead, it will report to Otterize Cloud what would happen if enforcement were to be enabled, guiding you to implement IBAC without blocking intended access.

Visualize the cluster via the access graph​

In the Otterize Cloud UI, your cluster should now show all 3 Otterize OSS operators — the intents operator, network mapper, and credentials operator — as connected, with a green status.

And when you go back to the access graph (and select your cluster from the dropdown, if needed), you should see the following map for the demo running in your cluster:

Access graph

Each service is shown as a node in the access graph, while the thick lines (edges) connecting the services show access between them, as detected by the network mapper.

The network map of the cluster​

If only the network mapper were connected to the Cloud, the services would be shown without the lock icons, and the thick connecting lines would be shown in blue, because we would have no more information about what access is or would be blocked once enforcement were turned on.

The network mapper gives insights on which services are trying to, or actually are, calling other services, which already provides useful insights. We call these "discovered intents": the intent of the client service to call the server service is discovered by the attempt to call the server service, not by an explicit declaration.

Access graph - network mapper

Understanding access and building confidence​

The network mapper only shows information about discovered intents, not about access that is, or would be, allowed or blocked.

Because the intents operator is also connected, we get additional information, namely on access controls — in this case, only pod-to-pod access, because we have not put in any Kafka-specific access configurations.

Protection status​

The services all show "unlocked" icons , meaning they are not protected (via network policies): that makes sense, because the intents operator is in shadow mode, so it does not protect (via managing network policies).

We also (as a default) told Otterize Cloud that there is a global default-deny network policy in place, so again, services show as unprotected.

Blocking status​

Note that the locks themselves are green, indicating that you could now turn on enforcement without blocking any clients.

Similarly, all the thick connecting lines between the services are green: none of these client calls would be blocked if enforcement were turned on. If one were red, that would tell you it would be blocked, as you might have guessed.

But why would these clients not be blocked if enforcement were on — doesn't that mean the services they call would not be protected? Yes, and the access graph lets you know that too.

Note the red notifications on the services. Click on a service, e.g. the payment service:

Access graph - clicked service

  • You can see the service isn't protected now, and it's ready to turn on enforcement without blocking any clients.
  • You can also see it won't be protected even after enabling enforcement — and what you need to do:
    • If you explicitly create and apply intents from the clients, they will be guaranteed access, but also the server will be protected from any undeclared access.
  • So why do you need to declare intents to protect services as well as to enable clients?
    • It's the way network policies work. A service must have at least one network policy applied to it in order to be protected. That can either be a global default-deny network policy, or an Otterize-managed network policy created once a client has declared and applied an intent.

Which intents are missing? What happens when we apply them? All that will be covered in the next tutorial.

In short, the access graph will provide insights about the current access to services, and will guide you to roll out IBAC responsibly and confidently, showing which intents need to be declared to both ensure access and protect servers.

What's next​

Teardown​

To remove the deployed demo run:

kubectl delete -n otterize-ecom-demo -f https://docs.otterize.com/code-examples/shadow-mode/all.yaml
kubectl delete -n otterize-ecom-demo -f https://docs.otterize.com/code-examples/shadow-mode/ecom-demo.yaml
kubectl delete namespace otterize-ecom-demo