Organizations using YugabyteDB Anywhere (YBA) with enterprise identity providers such as Keycloak sometimes want to go beyond standard role mapping and make authorization decisions using an external policy engine such as Open Policy Agent (OPA).
A common question is whether YBA can authenticate a user through Keycloak and then call OPA before creating the user session or allowing a particular YBA operation. This came up when a customer was evaluating how OPA could fit into their YBA authorization architecture.
The short answer is: YBA does not provide a native OPA or external Policy Decision Point (PDP) authorization hook.
YBA’s documented model is to use OIDC for authentication and YBA’s own Role-Based Access Control (RBAC) for authorization. YBA can map groups supplied by an OIDC provider to built-in or custom YBA roles, and those roles determine what the user can do through the UI or REST API.
The support material behind this tip reached the same conclusion: authorization remains inside YBA after OIDC authentication, with no native outbound OPA/PDP authorization hook for session creation or individual API requests.
Keycloak/OIDC can authenticate the user and provide identity and group information. YBA then maps that information to its own RBAC roles and performs authorization internally. OPA is not inserted into that authorization path by YBA.
How YBA OIDC Authorization Works
At a high level, the normal flow looks like this:
YBA supports mapping OIDC groups to built-in and custom roles. Users who belong to mapped groups receive the corresponding YBA permissions, while YBA’s RBAC system ultimately controls access to YBA resources and operations.
For many environments, this is all that is required.
But what if an organization needs OPA to make more dynamic policy decisions?
When possible, encode the required access policy in OIDC groups or claims, map those groups to built-in or custom YBA roles, and rely on YBA RBAC to enforce permissions for subsequent UI and API operations. This is YBA’s native authorization model.
If additional OPA-based policy evaluation is required, OPA can be placed in external layers around YBA. The architectures below are not native or documented YBA-to-OPA authorization integrations, and YBA continues to use its own RBAC model for application-level authorization.
Option 1: Put OPA in Front of YBA
For per-request policy enforcement, one approach is to place a reverse proxy or API gateway in front of YBA and integrate that layer with OPA.
For example:
Envoy provides an ext_authz filter specifically for delegating authorization decisions to an external HTTP or gRPC authorization service. OPA provides an Envoy integration that can evaluate the request context and return an authorization decision. If authorization is denied, Envoy can reject the request before it reaches YBA.
This allows policy decisions to consider information such as the authenticated identity, JWT claims, HTTP method, requested endpoint, or other request context.
For example, an organization could enforce a policy conceptually similar to:
Passing the external policy layer does not bypass YBA. YBA still relies on the authenticated OIDC identity and enforces its native RBAC permissions.
A reverse proxy with OPA does not replace YBA RBAC. Think of it as an additional authorization layer in front of YBA. A request may need to satisfy both the external OPA policy and YBA’s internal RBAC permissions.
Option 2: Make the Authorization Decision Before YBA
Another architecture is to perform additional policy evaluation at the identity-provider layer.
Conceptually:
Instead of having YBA consult OPA, the identity layer determines which groups or entitlements should be included in the authenticated user’s token.
YBA can then use its normal OIDC group mapping to map those groups to YBA roles. YBA’s documentation explicitly supports OIDC group-to-role mapping, including custom YBA roles.
Any Keycloak-to-OPA integration required to produce those dynamic claims would be external to YBA and should therefore be treated as part of the organization’s identity architecture rather than as a YBA feature.
Option 3: Use OPA Gatekeeper for OpenShift/Kubernetes Governance
OPA Gatekeeper solves a different problem.
If the requirement is to control the Kubernetes resources that can be created or modified in the OpenShift cluster, Gatekeeper can enforce policy through Kubernetes admission controls. Gatekeeper evaluates Kubernetes resources during admission and can enforce policies against objects being created, updated, or deleted.
The architecture looks more like:
This can help enforce policies around Kubernetes resources, namespaces, storage, security settings, and other cluster-level configuration.
It does not, however, provide user-level authorization for individual YBA UI or REST API operations.
OPA Gatekeeper protects the Kubernetes/OpenShift control plane. It does not insert OPA into YBA’s application-level authorization path. Use a gateway or identity-layer approach when the policy needs to govern individual YBA requests.
Which Approach Should You Use?
A Security Consideration
When placing an external authorization proxy in front of YBA, the architecture should prevent clients from simply bypassing the proxy and connecting directly to YBA.
In other words:
Network policies, OpenShift routes, firewall rules, or similar controls can be used so that the policy-enforcement point is actually part of the required request path.
The same principle applies to JWT information used for authorization: the policy layer should make decisions based on verified identity information rather than blindly trusting user-supplied headers.
Final Takeaway
YugabyteDB Anywhere already provides a strong authorization model through OIDC group mapping and native YBA RBAC, including support for custom roles.
When an organization requires OPA, the important question is where the policy needs to be enforced.
For YBA UI or REST API requests, an external authorization gateway such as Envoy can evaluate OPA policy before allowing traffic to reach YBA. For dynamic role assignment, policy can be incorporated into the identity-provider workflow before YBA receives the OIDC token. For OpenShift resource governance, OPA Gatekeeper can enforce policy at the Kubernetes API layer.
But none of these approaches changes YBA’s internal authorization architecture: YBA itself continues to enforce access using its native RBAC model.
References
Have Fun!
My wife and I scrubbed the house from top to bottom getting it ready to sell… including the oven and stovetop.
Now she’s making me cook outside on an electric skillet. 😂
Glad we picked this thing up a while ago for camping! Grilled cheese on the patio it is!