Comparing centralized and distributed deployment patterns
You can deploy OPA in a centralized or distributed deployment pattern, and the ideal method for a multi-tenant application depends on the use case. For examples of these patterns, see the Using a centralized PDP with PEPs on APIs and Using a distributed PDP and PEPs on APIs sections earlier in this guide. Because OPA can be deployed as a daemon in an operating system or container, it can be implemented in multiple ways to support a multi-tenant application.
In a centralized deployment pattern, OPA is deployed as a container or daemon with its RESTful API available to other services in the application. When a service requires a decision from OPA, the central OPA RESTful API is called to produce this decision. This approach is simple to deploy and maintain, because there is only a single deployment of OPA. The downside of this approach is that it doesn't provide any mechanism to maintain the separation of tenant data. Because there is only a single deployment of OPA, all tenant data that's used in an OPA decision, including any external data that's referenced by OPA, must be available to OPA. You can maintain tenant data isolation with this approach, but it must be enforced by OPA's policy and document structure or access to external data. A centralized deployment pattern also requires a higher latency, because each authorization decision must make a RESTful API call to another service.
In a distributed deployment pattern, OPA is deployed as a container or daemon alongside the multi-tenant application's services. It could be deployed as a sidecar container or as a daemon that runs locally on the operating system. To retrieve a decision from OPA, the service makes a RESTful API call to the local OPA deployment. (Because OPA can be deployed as a Go package, you can use Go natively to retrieve a decision instead of using a RESTful API call.) Unlike the centralized deployment pattern, the distributed pattern requires a much more robust effort to deploy, maintain, and update because it is present across multiple areas of the application. A benefit of the distributed deployment pattern is the ability to maintain the isolation of tenant data, particularly for applications that use a siloed SaaS model. Tenant-specific data can be isolated in OPA deployments that are specific to that tenant, because OPA in a distributed model is deployed alongside the tenant. Additionally, a distributed deployment pattern has much lower latency than a centralized deployment pattern, because each authorization decision can be made locally.
When you choose an OPA deployment pattern in your multi-tenant application, make sure to evaluate the criteria that are most critical for your application. If your multi-tenant application is sensitive to latency, a distributed deployment pattern offers better performance at the expense of more complex deployment and maintenance. Although you can manage some of this complexity through DevOps and automation, it still requires additional effort when compared with a centralized deployment pattern.
If your multi-tenant application uses a siloed SaaS model, you can use a distributed OPA deployment pattern to mimic the siloed approach to tenant data isolation. This is because when OPA runs alongside each tenant-specific application service, you can customize each OPA deployment to only contain data that's associated with that tenant. Siloing OPA data in a centralized OPA deployment pattern isn't possible. If you use either a centralized deployment pattern or a distributed pattern in conjunction with a pooled SaaS model, tenant data isolation must be maintained in the OPA document model.
