Otterize Cloud

Otterize Cloud provides a cloud-based control plane for deploying and managing intents-based access control (IBAC).

It currently supports IBAC within Kubernetes clusters, configuring access between pods and access to Kafka nodes using network policies and Kafka ACLs. Soon, Otterize Cloud will also support IBAC across clusters and non-Kubernetes services and resources (e.g. standalone and managed Kafka, RDS, etc.). This page is focused on the current capabilities of Otterize Cloud.

What it does

Otterize Cloud attaches to Otterize OSS operators (the intents operator, network mapper, and credentials operator) running in your Kubernetes clusters. While Otterize OSS does the heavy lifting — mapping pod-to-pod traffic, responding to intents files applied with kubectl and configuring network policies, Kafka ACLs, and Istio authorization policies — Otterize Cloud adds:

• Visibility: visualize the network map of any connected cluster.
• Confidence: run Otterize OSS in shadow mode, i.e. without enforcement, and see what would happen when you turn on enforcement.
• Operationalization:
  • Map namespaces to environments to see everything in the language of development cycle.
  • Use the (optional) Otterize Cloud identity service instead of operating SPIRE yourself (the default for standalone Otterize OSS).

The access graph

Otterize Cloud collects information from Otterize OSS, including the declared intents of clients to call servers ("discovered intents"), the implied intents of clients actually calling servers ("discovered intents"), certificate information, and various configurations. All of this is presented in a unified, filtered view called the access graph: a knowledge graph of which services call each other, are they blocked or would they be blocked if enforcement were turned on, are they protected, and how are they configured.

The access graph continuously reflects the state of your cluster, as reported by the Otterize OSS operators. Any changes made in the cluster appear in real time in Otterize Cloud.

tip

Otterize Cloud reads information from your cluster via Otterize OSS (when the latter is deployed with Otterize Cloud credentials) but Otterize Cloud does not write anything to your cluster: any modifications to your cluster only occur because of changes you make locally within your cluster.

For example, to change between shadow mode (no enforcement) and active enforcement mode, you change the Otterize intents operator configuration locally in your cluster, and redeploy it.

Filters

The access graph may be viewed for one cluster at a time. Within a cluster, you may filter by environment and by namespace.

The access graph shows all the services discovered in the selected cluster that meet the filter criteria. Services are discovered in one of two ways:

• Via the network mapper, which collects pod-to-pod connections (attempted and successful) and builds a network map of "discovered intents".
• Via the intents operator, which reports intents declared by (client) services to call (server) services, applied via kubectl.

Note: currently, services that have neither discovered nor declared intents attached to them at all will not appear in the access graph. This will be addressed soon.

Since discovered intents history is kept indefinitely, the access graph will eventually contain services that are no longer relevant. To filter out old discovered intents and the services that only appear because of them, use the "Since:" filter.

Understanding the access graph

When viewing the access graph for a cluster, the cluster's state is displayed at the top, to help you better understand the access graph.

You can easily tell whether whether all operators are connected or not.

For example, if either the network mapper or the intents operator is not connected, the access graph will not be able to compare the discovered intents with the explicitly declared intents and show what calls are or would be blocked.

You can tell whether the operators are in active or shadow mode.

• If active, they are managing network policies and Kafka ACLs to enforce access controls (and authorize intended access).

• In shadow mode, you can build confidence in your IBAC rollout by seeing what would happen before you turn on enforcement.

You can tell Otterize Cloud what you'd like to see and what's your cluster's non-Otterize configuration.

• If you've set up a global default deny network policy that only allows pod-to-pod access if an explicit pod-to-pod network policy allows it, check this box. The access graph will know that services are always protected unless those explicit policies are in place, and will show blocking information accordingly. Note that the access graph assumes that Otterize is managing any (ingress) network policies beyond this global default deny.

• If you've set up a global default deny Istio authorization policy that only allows pod-to-pod HTTP access if an explicit Istio pod-to-pod authorization policy allows it, check this box. The access graph will know that services are always protected unless those explicit policies are in place, and will show blocking information accordingly. Note that the access graph assumes that Otterize is managing any Istio authorization policies beyond this global default deny.

• If you're only interested in some access controls, turn off the "Use in access graph"" toggles for those you're not interested in. The access graph will not take those into account when calculating service and intents states, and will not show alerts or recommendations related to them.

The access graph combines all the information about the Kubernetes cluster and the services and intents in it to show you insights about service to service access.

Here is the meaning of the various arrows connecting the services — the edges of the graph that connect its nodes:

A green arrow indicates a connection allowed by policies

A yellow arrow indicates a connection that will be blocked when enforcement is enabled

A red arrow indicates a connection that will be blocked

Namespaces and environments

In a Kubernetes cluster, all services are contained within namespaces. Namespaces are used to group services that are similar in some way, and to separate them from other groups of services.

When intents are reported to Otterize Cloud, they include information about which namespaces their services are in. If the client and server are in different namespaces, the intent is called a cross-namespace intent. In any case, Otterize Cloud contains representations of all the namespaces reported to it by their association with intents, as well as which services they contain.

Because different namespaces may be mapped to different environments, intents may also be cross-environment.

In Kubernetes, namespace names must be unique within a cluster.

Otterize Cloud adds the concept of environments. These have the same meaning usually used in software development: dev, staging, production, etc.

You can create and manage as many environments as you need in Otterize Cloud. Just make sure they are meaningful to you. To map them to your cluster, map each namespace to the appropriate environment. All services in a namespace in a cluster are in the same environment. In configuring the integration of the cluster with Otterize Cloud, you will define the default environment to which namespaces in that cluster are mapped. Namespaces will be assigned to that environment until you map them to a different environment. If in your situation a cluster is considered to all be within an environment, you won't have to do anything once you've defined the default environment for namespaces in that cluster.

Environment names must be unique within an organization.