Otterize: Pioneering a New Standard in Service-to-Service Authorization
Share
Software has become an indispensable part of our lives, transforming the way we live, work, learn, and play. While some software is designed for humans to engage with it, most software services actually interact with each other via APIs, exchanging data or requesting services without direct user intervention.
In the past decade, the API ecosystem has flourished as cloud-based services have become essential for both people and businesses. APIs serve as the vital link that connect applications and data sources to each other, allowing for efficiency gains nearly everywhere that software is used. At the same time, the exponential growth of data from the digital economy has led to the development of data-driven applications in ecommerce, health and fitness, financial services, and business productivity. All of this further drives the need for APIs to communicate and share information with each other.
In many modern software applications, such as a fitness tracker or food delivery app, APIs are being used to enable a user-facing service. In other words, these APIs can be described as “user-to-service”. However, in the complex and sprawling API ecosystem that underpins much of the architecture of modern software, many API’s are communicating with each other and sharing data to a service that does not get surfaced to an end-user. These APIs can be thought of as “service-to-service”.
In a service-to-service architecture, each service exposes an API that describes the set of operations or data it can provide to other services. The requesting service can access the API of the provider to make requests, and the provider will respond with the requested data or service.
Ensuring that data transfers are secure and confined to the needs of the business in a service-to-service architecture like this is complicated. Developers need to build authorization processes, which determine whether a requesting service’s API has the necessary permissions to access a specific resource or perform a specific action. This can be complex and overwhelming for developer teams that need to decide between managing authorization configurations across different types of APIs, communication services, identity mechanisms, runtimes, and different public/private cloud infrastructure providers. Or, developers can simply scrap the whole idea of building authorization policies into service-to-service APIs, letting data run free as long as it’s within the confines of the organization’s network. However, modern organizations are often forced to figure out authorization, as they run their services across multiple networks, even within a single cloud provider, with the advent of managed infrastructure and multiple modes of deployment, such as Kubernetes and VMs. This trade-off between complexity and security or simplicity and risk is one that developers should not have to make.
With Otterize, they no longer have to.
Otterize allows developers to declaratively map appropriate permissions for every API, without needing to integrate different identity systems, orchestrate API communication platforms, or configure an API’s capabilities.
At the core of Otterize’s platform is an “access graph”, which has a contextual understanding of what data and which capabilities are being consumed by which clients. With the graph, developers can visually observe the interdependencies that their services have on each other. Otterize can then automatically generate intents based on observed traffic in the graph, or developers can declare their own client intents using Otterize’s Policy Designer. All of this allows developers to implement intent-based access control in a service-to-service architecture.
The Otterize Access Graph
The best part is that developers do not have to worry about deploying Otterize and seeing a break in API access from one of their services, as Otterize offers a shadow mode whereby developers can see in advance what will be allowed or blocked, before running it in enforcement mode.
Otterize is not just another policy engine – it is a complete reimagining of how services can securely access each other’s API’s with as little developer friction as possible. For developers, there is no need to configure permissions. Just write code.
We at Crew Capital are tremendously excited to be working with Otterize’s founders, Tomer Greenwald, Ori Shoshan, and Uri Sarid, as they revolutionize service-to-service access with IBAC. We’ve been investors in the company since day one, and are thrilled to be investing alongside our friends at Index Ventures, Dig Ventures, and other amazing firms and angels, in the company’s seed financing round.
To learn more about Otterize, check out their website, launch announcement, Github page, and the TechCrunch article on their fundraise.
Software has become an indispensable part of our lives, transforming the way we live, work, learn, and play. While some software is designed for humans to engage with it, most software services actually interact with each other via APIs, exchanging data or requesting services without direct user intervention.
In the past decade, the API ecosystem has flourished as cloud-based services have become essential for both people and businesses. APIs serve as the vital link that connect applications and data sources to each other, allowing for efficiency gains nearly everywhere that software is used. At the same time, the exponential growth of data from the digital economy has led to the development of data-driven applications in ecommerce, health and fitness, financial services, and business productivity. All of this further drives the need for APIs to communicate and share information with each other.
In many modern software applications, such as a fitness tracker or food delivery app, APIs are being used to enable a user-facing service. In other words, these APIs can be described as “user-to-service”. However, in the complex and sprawling API ecosystem that underpins much of the architecture of modern software, many API’s are communicating with each other and sharing data to a service that does not get surfaced to an end-user. These APIs can be thought of as “service-to-service”.
In a service-to-service architecture, each service exposes an API that describes the set of operations or data it can provide to other services. The requesting service can access the API of the provider to make requests, and the provider will respond with the requested data or service.
Ensuring that data transfers are secure and confined to the needs of the business in a service-to-service architecture like this is complicated. Developers need to build authorization processes, which determine whether a requesting service’s API has the necessary permissions to access a specific resource or perform a specific action. This can be complex and overwhelming for developer teams that need to decide between managing authorization configurations across different types of APIs, communication services, identity mechanisms, runtimes, and different public/private cloud infrastructure providers. Or, developers can simply scrap the whole idea of building authorization policies into service-to-service APIs, letting data run free as long as it’s within the confines of the organization’s network. However, modern organizations are often forced to figure out authorization, as they run their services across multiple networks, even within a single cloud provider, with the advent of managed infrastructure and multiple modes of deployment, such as Kubernetes and VMs. This trade-off between complexity and security or simplicity and risk is one that developers should not have to make.
With Otterize, they no longer have to.
Otterize allows developers to declaratively map appropriate permissions for every API, without needing to integrate different identity systems, orchestrate API communication platforms, or configure an API’s capabilities.
At the core of Otterize’s platform is an “access graph”, which has a contextual understanding of what data and which capabilities are being consumed by which clients. With the graph, developers can visually observe the interdependencies that their services have on each other. Otterize can then automatically generate intents based on observed traffic in the graph, or developers can declare their own client intents using Otterize’s Policy Designer. All of this allows developers to implement intent-based access control in a service-to-service architecture.
The Otterize Access Graph
The best part is that developers do not have to worry about deploying Otterize and seeing a break in API access from one of their services, as Otterize offers a shadow mode whereby developers can see in advance what will be allowed or blocked, before running it in enforcement mode.
Otterize is not just another policy engine – it is a complete reimagining of how services can securely access each other’s API’s with as little developer friction as possible. For developers, there is no need to configure permissions. Just write code.
We at Crew Capital are tremendously excited to be working with Otterize’s founders, Tomer Greenwald, Ori Shoshan, and Uri Sarid, as they revolutionize service-to-service access with IBAC. We’ve been investors in the company since day one, and are thrilled to be investing alongside our friends at Index Ventures, Dig Ventures, and other amazing firms and angels, in the company’s seed financing round.
To learn more about Otterize, check out their website, launch announcement, Github page, and the TechCrunch article on their fundraise.