Feature Description
OPA Bunder Service see Epic: rossoctl/rossoctl#1789
Proposed Solution
OPA Bundle Service
The OPA Bundle Service implements a standard OPA service for distributing OPA bundles. The bundles are distributed based on client id (SPIFFE). The service generates a dedicated bundle for each agent and each tool. Per‑agent and per-tool bundles enforce strict isolation: each agent receives only the policies relevant to its own identity, reducing blast radius and preventing agents from inferring or accessing rules intended for others.
Each bundle is tied to the component’s SPIFFE identity, enabling Security Engineers and SREs to define four separate Rego files per agent or tool:
- Inbound request policy
- Inbound response policy
- Outbound request policy
- Outbound response policy
Inbound policies evaluate what is allowed to reach the agent or tool, while outbound policies evaluate what the agent or tool itself is allowed to call or return.
This design is:
- IdP-agnostic — Works with any identity provider (Keycloak, Entra ID, Okta, custom IdPs). Policies reference identity claims, not a specific token system.
- Runtime context — Decisions are made at request time with full context.
- Kubernetes-native — Policies are managed as CRs with schema validation, RBAC, and GitOps workflows — aligned with Kubernetes access-control practices.
- Expressive — Rego supports RBAC, ABAC, relationship-based rules, content inspection, and combinational logic in a single policy language.
- No vendor lock-in — OPA is CNCF-graduated. Switching or adding identity providers requires no policy rewrites.
Want to contribute?
Additional Context
No response
Feature Description
OPA Bunder Service see Epic: rossoctl/rossoctl#1789
Proposed Solution
OPA Bundle Service
The OPA Bundle Service implements a standard OPA service for distributing OPA bundles. The bundles are distributed based on client id (SPIFFE). The service generates a dedicated bundle for each agent and each tool. Per‑agent and per-tool bundles enforce strict isolation: each agent receives only the policies relevant to its own identity, reducing blast radius and preventing agents from inferring or accessing rules intended for others.
Each bundle is tied to the component’s SPIFFE identity, enabling Security Engineers and SREs to define four separate Rego files per agent or tool:
Inbound policies evaluate what is allowed to reach the agent or tool, while outbound policies evaluate what the agent or tool itself is allowed to call or return.
This design is:
Want to contribute?
Additional Context
No response