Otterize: Intent-Based Access Control for Kubernetes and Cloud
AMSTERDAM — As services become more and more distributed, organizations need to control not only who can access them from the outside but how internal services can communicate with each other. Whether it’s protecting sensitive data silos or how the shopping cart service communicates with the customer log-in service, each use case requires different authentication, authorization, and configuration.
Lately, the burden of choice of who can do what sits on the shoulders of the platform engineering team.
“Developers increasingly have a choice of great technologies to address their needs, and so they are adding more and more technologies. But then you get this cacophony of multiple technologies, multiple stacks and multiple services communicating with each other that aren’t normalized in any way,” Otterize CEO and co-founder Tomer Greenwald told The New Stack.
“So you can have four or five teams within the same department working on different stacks, they can use Go and Python and Java, and they may use Kafka, but some use hosted Kafka, some use MSK [managed via Amazon], and some use Confluent Cloud because that’s what’s easy for them. But then there’s a burden that we saw that’s increasing in the platform teams of managing everything.”
Otterize looks at intent-based access control (IBAC) as the solution to ease platform pain. Otterize OSS is an open source secure connectivity management tool built for use within Kubernetes clusters, that is launching today at KubeCon+CloudNativeCon Europe its Otterize Cloud add-on for platform engineering teams. Otterize — sweetly named after the way “authorize” is pronounced with a Hebrew accent, with a cute animal mascot to boot — virtualizes enforcement point management across Kubernetes clusters and now the cloud.
What Is Intent-based Access Control (IBAC)?
The team at Otterize, a recently funded startup based in Tel Aviv and San Francisco, describes intent-based access control or IBAC as a modern, declarative approach to granting access automatically, responsibly, and scalably.
“What we’ve built here is a solution to allow platform engineers and developers to manage secure access for their platforms and systems without having to think about authentication and authorization and everything related to the processes that they have to take to get that secure access,” said Greenwald.
Otterize is unique, he says, as an un-opinionated authentication and authorization solution.
“Otterize doesn’t talk about how to configure stuff or how do you want to secure things. Do you want to use mTLS [mutual transport layer security] or JWTs [JSON web tokens]? Do you want to use Kubernetes network policies or Istio service mesh policies or Kafka ACLs?” Greenwald continued. Instead, developers describe their functional needs in a declarative way. “Let’s say I’m a developer working on the checkout service, and I want to make a secure call to the order service. I simply tell Otterize ‘I want to get access to the order service’. And if I want to connect to a Kafka broker, I simply tell Otterize, ‘I want to connect to the Kafka broker’,” he explained.
Otterize follows a conversational, declarative pattern, with a simple YAML file — which is called an “intents file” within the tool — expressing the needs from the client’s perspective. It doesn’t ask about the identification or security needs, but asks the developers about their functional needs. From there, the intents are committed, reviewed and approved just like source code. Otterize plugs into the CI/CD pipeline to then manage and configure the access controls according to those intents.
“We don’t require you to install a new enforcement point or deploy a new service mesh or use some custom SDK as new enforcement points,” Greenwald said. “We actually believe that most teams have the right enforcement points available already, and all we need to do is connect to them and configure them: configure their service mesh, configure their API gateways, or Kafka brokers, to enforce intended-access-only. The hard problem in most cases isn’t how to control access but rather what access should be granted or not.”
Otterize acts as a virtualization of enforcement points, taking away the need for developers to install and configure anything for authorized enforcement — or ping platform teams asking them to do it for them.
“We allow intended access. We block unintended access. But, most of all, we do it without having to get every developer to understand every type of enforcement point and every type of authentication mechanism,” he said.
This version of Otterize is already released as an open source solution that can be installed on a single Kubernetes cluster, manage network policies, and manage authentication authorization for Kafka using mTLS and Kafka’s built-in access control lists (ACLs).
The information of which client service has access to which servers always lives with the client source code, maintaining consistency as the code evolves, and always keeping least-privilege access to servers.
For KubeCon, Otterize is also releasing its first service mesh integration with Istio, as well as a Kafka visibility capability to show which clients access which topics, as well as what client is consuming and should not. This improves Otterize’s capabilities to operate in “shadow mode,” showing what would happen if enforcement were turned on, before anything has a chance to break.
The team intends to apply for the Cloud Native Computing Foundation sandbox soon.
Otterize Cloud for Platform Engineering Teams
As Greenwald referenced at the beginning of this piece, developers have a freedom of choice, but that freedom is making the job of platform teams much harder. With that in mind, also today at KubeCon, Otterize announces its new Otterize Cloud, which extends the open source in-cluster enforcement with a global view and insights in the cloud.
This cloud offering allows platform teams more visibility and insights — this would be blocked, this is not protected, etc. — to let them preview what changes will be made, and how that will affect telemetries and alerts. Otterize Cloud allows teams to connect multiple open source installations on different clusters and then puts them behind a single pane of glass.
As Otterize Cloud evolves, Greenwald said, it will support more complex layouts where one Kubernetes calls to another. Previously, this would have required a lot of extra knowledge and configuration by developers or their platform teams, which again Otterize would now abstract away, providing a unified view of the “access plane” of all a company’s services.
This cloud offering allows platform teams more visibility in how changes will be made, and how that will affect telemetries and alerts. The cloud allows teams to connect multiple open source installations on different clusters and then puts them behind a single pane of glass.
This enables simpler transitions, he continued, between different best-of-breed technical alternatives — like transitioning from a hosted to a cloud-managed Kafka, or moving from network policies to Istio, or vice versa. Otterize doesn’t limit choice, it just muffles that cacophony platform teams have to continuously contend with, no longer having to create custom platforms to fit all the different developer demands. Instead, Otterize is normalizing identities, permissions and authentication across an organization.
This single view, visually presented in Otterize Cloud as the “access graph,” also allows platform teams to map out how different services will interact with each other, perhaps using shadow mode to preview the effects of enforcement before activating enforcement. “The access graph allows you to visualize and understand what’s going on when you’re using the different enforcement methods and how they’re going to affect your traffic,” Greenwald said.
This includes whether discovered intents — what calls services are actually making — match declared intents. In particular, it flags if there are services that would now be blocked because no one declared the calls as intended. This allows for mistakes to be caught before they are released.
Check back often this week for all things KubeCon+CloudNativeCon Europe 2023. The New Stack will be your eyes and ears on the ground in Amsterdam!
