Access control done right

• You’re doing security wrong. Well, maybe not all of it, but probably access control. Despite your efforts, e.g. to get the right PKI and ACLs set up, authentication and authorization mechanisms can be a constant struggle. Perhaps you’re even thinking: if I’m doing things right, why does it have to be so hard?
  
  You may have the latest infrastructure and tooling, maybe you can even deploy your entire production environment on a K8s cluster with a single CLI command. However, getting the right credentials and configuring the necessary authorization logic for your code to make a secure HTTPcall to another service or producing events to a Kafka topic can take a long time and multiple interactions over Slack, email, or support tickets. It's not that you don't know how to write the code for it, but setting up trust between services can be challenging.
  
  Wait, why is it actually that complicated? All we’re making here are secure calls from one service to another. But there’s a whole lot of figuring out before we can make those calls. Let’s look closer from the platform engineer’s perspective:
  
  

• Where does the client get its identity?

• Is the identity encoded in mTLS, JWT, or credentials?

• What is the enforcement point for the server?

• Does it support the client’s type of credentials?

• How do we configure its policies?

• Who should be allowed to configure its policies?

And, again from the platform engineer’s perspective: how should this happen for every type of service and infrastructure my devs need?

What if there were a new approach to make all of this friction go away?

Rethink authorization

Let's rethink authorization and determine what we truly want to accomplish. Developers are working on their applications, with the intention of calling other services. What if we take those intentions directly and use them to configure everything else?

We call this inversion of control intent-based access control – IBAC. Otterize is a platform to realize IBAC. With IBAC, developers can securely access services by just declaring, alongside their code, the intended calls they plan to make. Otterize will then automatically configure existing access controls to allow those calls and block any unintended ones.

It's as simple as that. Let's move away from the painful practice of manually configuring access controls on servers. Eliminate the friction that is inherent in the process of requiring each developer to be an expert in authentication protocols and in configuring server-side rules on different enforcement points. Instead, let's let automation do the heavy lifting to accomplish what developers intend, with IBAC.

So what is an intents file?

Similar to how Kubernetes YAML manifests describe the desired state for an application, IBAC uses YAML intent files to declare what services your code intends to access.

Otterize uses these intents to configure existing access controls to grant only the access that is needed. This eliminates the need to manually configure access controls, generate certificates, deploy tokens, or open access tickets.

Decouple authorization from enforcement

Otterize allows developers to decouple authorization from enforcement and to separate authorization logic from authorization capabilities. With Otterize, developers only need to consider the services they intend their code to call. That's it. Otterize takes these intents and configures existing enforcement mechanisms. Even if, for example, you want to switch from network policies to a service mesh next week, the developer's perspective remains the same. The intents remain the same, and Otterize configures the new infrastructure for you.

How does this trickery work?

When authorizing an API call, whether synchronous (HTTP, gRPC, GraphQL) or asynchronous (Kafka, RabbitMQ), two main realms need to be accounted for: authentication and authorization. Otterize, as a neutral platform, integrates with all players in these realms and orchestrates them to match your needs.

Don’t I have enough enforcement points?

Yes, you probably do. With today's infrastructure, there are plenty of enforcement points available. For example, when running on Kubernetes, you can use CNIs to enforce network policies and service meshes to enforce HTTP authorization. There are Kafka's built-in ACL capabilities, RDS’ IAM policies, and many more infrastructures offering built-in enforcement. So you’re likely already well-covered.

And what about identities?

You logically have service identities from Kubernetes, IAM, and your CI/CD pipeline, but generating credentials is still a tedious process, and bridging identities from one platform to another can be challenging. Otterize addresses this challenge by managing credentials generation and bridging identities between different IAM platforms.

What do I mean by bridging identities? Let’s consider a simple use case of a Kubernetes workload authenticating to Kafka. We need to bridge a Kubernetes identity for a workload (pod) over mTLS to a Kafka principal in order to define a single ACL. That's some complex identity bridging right there.

Bringing it all together

If we have existing enforcement points, identities, workloads, and teams operating them, what's missing? It's a single platform to orchestrate this intricate play of software, human intents, and infrastructure to get and maintain secure access easily.

That's where Otterize comes in. It's a single platform for engineering teams to manage secure access from the developer's perspective with intents-based access control (IBAC), using your existing infrastructure.

Platform engineers can embed the Otterize open-source solution in their development pipeline and then optionally plug-in insights from the Otterize Cloud via its API. This offers developers a fundamentally easier, self-serve way to call other services and infrastructure securely, focusing on what their code needs to call and not on how to make those calls securely. This approach inherently reduces the friction developers have with managing permissions, deploying credentials, and coordinating between teams when working on getting secure access.

What now?

If you have reached this point in the blog post and have access to a Kubernetes cluster, I recommend giving Otterize a try! You can map existing traffic to intents and use these intents to manage network policies and Kafka ACLs, deploy mTLS certificates, and operate in “shadow mode” to understand the state of your clusters and how changes you make will affect them. You can use these features to enhance your security posture, facilitate more secure communication, and implement zero trust. Additionally, with upcoming support for Istio, RDS, and other infrastructures and access controls, you will have even more coverage to automate secure access. To get started, visit Otterize's documentation.

What’s next?

Integrations are a core focus of Otterize. We are continuously adding more support for common protocols, enforcement points, credential generation mechanisms, and platforms to fit all types of infrastructure. In addition, we are integrating into existing development workflows with automated pull requests for changes detected in environments, integrations with CI/CD (e.g. GitHub Actions), workflow automation (e.g. JIRA), Slack alerts, and operationalization capabilities to ensure complete coverage from intent to enforcement.

Otterize's mission is to build solutions that remove friction from authorization and secure access for developers, platform engineers, and DevOps engineers. We achieve this by prioritizing ease of access and seamless integration into existing development processes and application lifecycles. Our objective is to provide the simplest and most convenient way for developers to obtain secure access for their code. And when authorization and secure access are simplified, they become the default for accessing resources.