Skip to main content

Terminology

An overview of the terminology used in Otterize OSS documentation. If you think a term is missing here, please let us know.

Basics​

Service​

An Otterize service is the logical "atom" of service-to-service authentication and authorization. It can be a client or a server or both. Services are connected through client intents: one service intends to call another service. Learn how service identity resolution happens.

CLI​

The Otterize CLI is a command-line utility used to control and interact with the Otterize network mapper, manipulate local Intents files, and (coming soon!) interact with Otterize Cloud.

Intent (or client intent)​

Otterize intents are a way to declare that one service intends to call another service. Otterize uses them to apply authorization rules to enable the calls to go through, and block any unintended calls. An intent refers to a client declaring a particular call to a server; all a given client's intents to the servers it intends to call are collected in a single client intents file. Learn more about intents.

Integrations​

Otterize Cloud supports two types of integrations: Kubernetes integrations and generic integrations. Kubernetes integrations connect a Kubernetes cluster to Otterize Cloud, allowing communication with the Otterize operators. Generic integrations connect external systems to Otterize Cloud, providing API/CLI access credentials. These integrations are named based on their usage and must have unique names within an organization.

Identity​

PKI​

PKI stands for public key infrastructure, and refers to the infrastructure used to provision X.509 credentials. A common use case for PKI is to support mTLS.

mTLS​

mTLS stands for mutual TLS, and is a form of TLS where both the client and server mutually authenticate to each other. In other words, mTLS is mutual TLS.

In regular TLS, only the server is authenticated. For example, when you connect to google.com, a nd your browser authenticates google.com using its certificate, you're using TLS; but google.com does not authenticate you, as the client, with a certificate, so the communication isn't using mTLS, just TLS.

SPIRE​

An open-source implementation of the SPIFFE specification. It's used for workload attestation and credential management. Read more about SPIRE in the official documentation.

Credentials operator​

The Otterize credentials operator automatically resolves pods to dev-friendly service names, registers them with a SPIRE server or with the Otterize Cloud-managed credentials service, and provisions credentials as Kubernetes Secrets.

Enforcement​

Network policies​

Kubernetes network policies can be used to control network access between pods in a Kubernetes cluster. To do so they require the installation of a Kubernetes CNI network plugin that supports network policy enforcement. One commonly supported CNI is Calico. Read more about network policies in the official documentation.

Kafka ACLs​

ACLs stand for Access Control Lists, a built-in mechanism in Kafka (and other systems) for authorizing access to Kafka resources such as topics. Read more about Kafka ACLs in the official documentation.

Kubernetes​

Custom resource​

A Kubernetes custom resource refers to a resource that is not present in the base distribution of Kubernetes (such as Deployment or Pod), but comes with an installed operator. The Otterize ClientIntents are one such resource. Read more about Kubernetes custom resources here.

CNI (Container Network Interface)​

CNI is a CNCF project that provides libraries for implementing plugins for configuring network interfaces in Linux containers, and is used by Kubernetes to provide pods running in a cluster with network connectivity. Examples of CNI plugins are Calico, Cilium, the AWS VPC CNI plugin. Read more about Kubernetes CNI plugins here.

Services​

Services represent the nodes in the access graph. They can be client services, server services, or both, and they are associated with specific namespaces within a Kubernetes cluster. Otterize Cloud infers services from reported intents and provides additional information for Kafka services and certificates. Service names must be unique within a namespace, but not necessarily across the entire cluster or multiple clusters.

Namespaces and Environments​

Namespaces are used to group related services within a Kubernetes cluster and can be mapped to different environments (e.g., dev, staging, production). Intents can be cross-namespace and cross-environment, and Otterize Cloud associates namespaces with their respective environments. Environment names must be unique within an organization.

Clusters​

A Kubernetes cluster connected to Otterize Cloud is represented by a cluster object in the cloud. This object contains information about the cluster's intents, services, credentials, and configuration. Multiple clusters and namespaces can belong to a single environment, or environments can span multiple clusters, depending on the organization's needs. Cluster names must be unique within an organization.