2025 OPA Community Survey

59 responses were grouped and summarized as follows

• Work/Colleagues (18 responses): Discovered through workplace connections, whether introduced by "architects" or "consultants," learning from coworkers, or joining teams where OPA was already in use.
• Kubernetes/Cloud Native Ecosystem (15 responses): Found via the cloud native community through KubeCon events, CNCF resources, Gatekeeper, or while researching "PodSecurityPolicy being deprecated by Kubernetes."
• Research/Web Search (12 responses): Discovered independently while searching for authorization and policy solutions, from "browsing for available policy frameworks" to finding "a way to replace our home-developed authorization microservice."
• Product Integrations (6 responses): Encountered through existing tools and documentation, including "Trino integration," "Envoy ext_authz examples," and "HashiCorp's website."

39 responses were summarized and grouped, we still see that generative models still struggle with the Rego syntax.

• Failures/Limitations (15 responses): LLMs struggle with Rego's unique syntax, often "hallucinating" features, generating "python-like code," or producing outdated v0 syntax like "the old name { ... } syntax without the if" despite recent language updates.
• Mixed/Moderate Success (7 responses): AI can be helpful for specific tasks like "debugging operations," "drafting the rego rules," or "convert some pretty nasty v0 rego to v1," though manual edits are typically still required.
• Haven't Tried/N/A (12 responses): Many respondents haven't explored AI tooling yet, with some noting they "prefer understanding what I'm doing first" or simply haven't needed to update policies since GenAI became widely available.

32 responses were summarized as follows, showing interest across a broad range integration options.

• Data & State Management (7 responses): Users want better solutions for handling external data, from "on demand data ingestion" for high-volume volatile data to "a good shared cache for OPAs in same kubernetes namespace" and the ability to "load a baseline dataset from a bundle file and amend that via rest api."
• Standards & Protocol Support (6 responses): Requests for broader protocol and API support, including "OpenID AuthZEN API support," "OPA running as gRPC," and more "first-party" integrations like "AuthZen and Rebac out-of-the-box."
• Enterprise & Operational Features (6 responses): Need for production-ready capabilities such as "full stack OTEL integration with Grafana," "disk buffering for decision logs," "s3 export of logs," and "a builtin control plane."
• Documentation & Tooling (4 responses): Gaps in guidance and developer experience, from "better documentation on OPA side car components" to "proper CLI installation for Linux machines" and package management where "a OPA lib can depend on remote OPA policy."

28 responses were summarized showing a broad range of experiences.

• Successful Implementations (8 responses): Teams have found success using OPA for diverse use cases, from "fine-grained Kubernetes security policy" with Gatekeeper to "auth across multiple Trino instances" and "decoupling permissions from our legacy monolith system," with one team seeing dramatic improvements where "10000 policies causing a JWT token request timeout" dropped to "around 200ms" with OPA.
• Learning Curve Challenges (5 responses): Adoption friction centers on Rego's declarative nature, where "teams have a hard time learning Rego" and "error handling is weird" — particularly the concept that "if some value is undefined the top rule is also undefined."
• Architectural & Integration Hurdles (5 responses): Organizations struggle with complex integration patterns, from "how to handle 'global' or enterprise policies at the gateway level and 'local' policies at the application level" to converting "arbitrary rules to SQL for filter requests" and wanting "better GraphQL support."
• Organizational & Trust Concerns (3 responses): Business adoption faces resistance, with "strong pushback on OPA and externalized authz in general" and a need for "supporting tooling" like control planes and management apps to ease introduction.

34 responses tell a pretty strong story about not having time to contribute to OPA, among other reasons.

• Time Constraints (13 responses): The most common barrier is simply bandwidth, with many citing "only so much time in the day," competing "priorities at work," and "other tasks with higher priorities."
• Skills & Knowledge Gaps (7 responses): Many feel underprepared, whether "not familiar with go," still on the "learning curve," or feeling "not that advanced user yet" to know what they could contribute.
• Unclear Entry Points (3 responses): Some want to contribute but lack direction, "not sure what other contributions are welcome or needed" or actively "looking for my first issue to contribute to now" and needing "good first issues."
• Company Policies & Restrictions (2 responses): Organizational barriers prevent some from participating, including "company policy on open-source contribution" and workplaces "not known for open-source contributions."

5 responses

• Time-Based & Contextual Access (1 response): Users want dynamic authorization, such as granting "time based access to support engineers to 'unblock' users in emergency situations where the risk of being down outweighs the security violations."
• Resource Segmentation (1 response): Teams need finer controls "to restrict certain use cases to segregated nodes."

4 responses were summarized

• Stability & Upgrades (2 responses): Users prioritize reliable version management, whether valuing "smooth upgrades" or needing to "get up to speed with the latest versions" before evaluating new features.

8 responses were summarized

• Reliability & Standardization (3 responses): Users appreciate that Gatekeeper simply works — "it works," "it just works," and it's become "the de-facto standard versus alternatives like Kyverno."
• Functionality & Integration (3 responses): Teams value the capabilities it provides, from "advanced admission control" and "policy guardrails/enforcement" to easy "integration into our current build process."

9 responses were summarized

• Complexity & Usability (3 responses): Users find Gatekeeper "overcomplicated for simple use cases," with the "constraints + constraint templates" structure feeling like "a bit too much cruft" for simple tasks like enforcing a label, and "not always easy to debug policy failures."
• Architecture Limitations (3 responses): Technical gaps frustrate users, particularly the "lack of shared lib support and hierarchical policy support" and "no simple way to embed rego policy at scale into the constraint template" while maintaining separate files for unit tests.

7 responses were summarized

• Documentation & Guidance Gaps (2 responses): Users struggle with "lack of documentation" and want clearer guidance on patterns like "leveraging SPIRE/SPIFFE identities for microservice authentication" — noting "there might be room for clearly documenting that as a good option."
• Development & Data Challenges (2 responses): Practical hurdles include "local development without kubernetes" requiring nginx workarounds, and "getting external data into it," leading teams to build custom bundle servers.
• Release & Policy Management (2 responses): Operational concerns include being "always behind the main OPA releases by few days" and difficulties "evaluating multiple policies."

5 responses

• Insufficient Documentation (2 responses): Users find gaps in the current docs, noting they do "not provide details on the interfaces" and lack clarity on "the mapping between a request and a policy" or "how to evaluate multiple policies against a single request."

3 responses were summarized

• Use Case Guidance (1 response): Users want documentation for complex scenarios, particularly "global and local policies" in "a multi-tenant (namespaced) cluster where there are enterprise level policies at the gateway and local policies at tenants."

19 responses

• Strong Appreciation (7 responses): Users are enthusiastic about Regal, calling it "best tool ever" that "augments Rego learning," with many finding it "the best source of documentation for idiomatic Rego" and valuing how it "defines some common guidelines for how Rego code should look."
• Feature Requests (4 responses): Users want expanded capabilities, particularly "find references" and "LSP rename" for improved workflow, more "auto fixable rules," and wish "the examples on the OPA website were using rego that has zero violations from regal."
• Usability Challenges (4 responses): Some encounter friction, including Regal not reloading properly in VS Code requiring full restarts, difficulty with the debugger in Zed, rules that are "hard to understand from documentation," and confusion "when migrating code pre v1."