FAQ

What's the difference between authorization and authentication?

Authorization means to allow a client (in our case, another service) of a server to perform certain operations on that server (specifically, through that server's API). Often, the server will want to allow one client to perform certain operations that another client cannot perform. To know whether a client ca perform the operation the client requests, the server must first know which client is making the request.

Authentication means verifying who a client is, i.e. determining its identity. Usually the client presents some credentials at the time it makes the request; when the server verifies them, i.e. authenticates the client, it now knows the identity of the client, and can see whether that specific client is authorized to perform the requested operation.

In some cases, authorization is implied through authentication: any client the server definitively recognizes, i.e. authenticates, is allowed to perform any requested operation.

There are many variations on authorization and authentication. For example, when Otterize is used with Kubernetes network policies, the Otterize intents operator first establishes pod identity using a certain algorithm. To authorize pod-to-pod access, it then creates labels and configures network policies in the Kubernetes cluster such that only client pods that are authorized to access the server pod are allowed network access to those servers. At runtime, the authorized client pods can simply send requests to the server pods, and unless other enforcement mechanisms are in place, no authentication is needed. (Effectively, the labels which Otterize configured Kubernetes to put on the pod serve as a kind of authentication for the network policies.)

What is IBAC?

IBAC is short for intent-based access control, which is a new paradigm for configuring service-to-service access control based on the client service declaring what server calls (or operations) it intends to make.

For more information, see the IBAC documentation page.

What's behind the name "Otterize"?

That's easy: it's "authorize" in a Hebrew accent 😉

Where does Otterize fit in my infrastructure?

Otterize does not provide yet another layer in your infrastructure, at least not in your runtime infrastructure. Instead, Otterize primarily configures your existing infrastructure's access controls -- its enforcement points -- according to client intents that have been applied in a particular context -- say, a Kubernetes namespace, or an environment (when using Otterize Cloud). With Otterize Cloud, you can also set rules on how to process intents before they're used to configure access controls, or even to set access controls directly.

Otterize also provides an optional server SDK (coming soon) that you can embed in your code as an inline access control. It provides a layer of authentication and authorization that can be standalone or can be used in addition to other access controls such as network policies, API gateways, or proxies.

Is Otterize open source?

Otterize provides a standalone, completely open-source solution called Otterize OSS for intent-based access control within a Kubernetes cluster. More information is available at otterize.com/open-source and on GitHub.

Otterize also provides a cloud-based, SaaS offering called Otterize Cloud that is not open source, with both free and paid tiers. More information is available at otterize.com/product

In general, all Otterize components that run on the user side ("on prem") are open sourced. These include the Kubernetes operators and the network mapper that are part of Otterize OSS, as well as the Otterize CLI, the Otterize SDK (coming soon), and components to integrate with your infrastructure, e.g. for integrating with Kafka outside of Kubernetes.

Can I start with one use-case and expand to other use-cases as I grow?

Sure, in fact we recommend that you roll out IBAC gradually, to grow your and your organization's confidence in this approach. Change, even when positive, is not always easy to manage. Tools such as the network mapper let you bootstrap intents files to make adoption by teams that own specific services much easier. Read the various tutorials for network policies, Kafka, network mapping. to see how to roll out IBAC gradually for various use cases.

How is Otterize different from a service mesh?

Otterize's approach is to configure and use your existing infrastructure as much as possible, rather than replacing existing components, and help you achieve zero-trust through effective use of authentication and authorization across heterogeneous infrastructures and tech stacks. The drivers for authentication and authorization are client intents: metadata that's used to configure enforcement points.

In contrast, service meshes aim to solve a whole slew of problems and tasks related to microservices, such as request routing and load balancing, circuit breaking, retries, rate limiting, blue/green deployment, service discovery, observability and metrics, as well as authentication and authorization. Otterize does not aim to do all of these things — only authentication and authorization. And even there, it does not aim to replace enforcement points for authN/authZ — it just configures them based on client intents and any overriding rules. So if a service mesh is used to enforce access, Otterize would configure it based on client intents (and any override rules) — as we do with our support for Istio.

Unlike Otterize, service meshes generally aim to be the a one-stop-shop for all your needs, replacing many of the technologies you currently use. For many, this actually turns out to be friction, especially if you just want to apply authorization, and don't wish to change various technologies that are already working for you.

In summary, Otterize is not a replacement for a service mesh: a service mesh does many things Otterize doesn't, and vice versa. If you use a service mesh in a Kubernetes cluster, but also have other services that live outside a service mesh, Otterize aims to help you achieve effective zero-trust between those services when they communicate, without demanding that you replace the tech stack for one or the other, instead helping them coexist peacefully.

Can I control which intents are being approved and which are not?

Usually, when client intents files go through code review along with the client code, they accurately reflect the calls the client will be making, so it would make sense to enable access controls so those calls can go through. Depending on the access control mechanisms, once Otterize configures secure access to a server based on a client's declared intent, all unintended calls are then blocked — for example, configuring the first Kubernetes network policy on a service blocks access from pods not having a network policy on that service, and configuring a Kafka ACL on a topic blocks access to that topics from clients not having an ACL on it. In that case, intents not only enable client access, they also increase server security.

But there may well be cases in which access should still require some other approval before it's granted. For example, intents might automatically turn into access only in certain environments, or only for certain services, while others require approval or some other check. For such cases, Otterize Cloud (coming soon) provides automation rules that intermediate between application of intents and granting of access. Even within Otterize OSS, platform teams can manage when access is granted by managing when kubectl apply executes within a CI/CD pipeline.

For more information on IBAC and security, see the security documentation.

Will you keep supporting the open source in parallel with the Otterize Cloud product?

Otterize OSS is as critical for us as Otterize Cloud. Our mission is to get IBAC — intent-based access control — adopted as broadly as possible. We can't do it alone, and that means we can't do it without being open-first: with a robust open-source offering, an openness to develop an open ecosystem around IBAC, and an open mind to learning from the community what works and when doesn't and therefore making changes and evolving. It's also the way we work within Otterize as a company, something we hope to publish soon as a blog post.

In short, our one metric as a company is adoption, and that will be driven by Otterize OSS as much as by Otterize Cloud.

Which means Otterize OSS will continue to be developed energetically along with Otterize Cloud. After all, Otterize OSS is the way Otterize implements IBAC within a Kubernetes cluster, and is also the way Otterize Cloud integrates with Kubernetes clusters. Otterize OSS will continue indefinitely to be a robust, productized, free and open source implementation of IBAC in a Kubernetes cluster, which never requires any commercial software.