docs/blog/2018-07-31-v0-9-release-4eb605bd0989.md
This post provides a quick overview of the work that has gone into OPA v0.9. As usual, the release is published on GitHub Releases and Docker Hub.
During this release cycle we worked with the upstream Ceph and Minio communities to introduce fine-grained access control into data lakes using OPA. Both Ceph and Minio support the standard S3 object storage APIs and are popular choices for deploying object storage services.
The integrations into Ceph and Minio allow administrators to express fine-grained attribute-based access control (ABAC) policies over requests to the object storage layer. Compared to Bucket Policies and Object ACLs, these integrations give administrators greater control over sensitive data stored in these services. Using OPA you can enforce policies over object and file access based on context such as:
We expect to see more adoption of OPA to control access to sensitive data as more and more organizations build out data lakes using object storage services like Ceph and Minio.
For more information on the integrations see the PRs:
OPA now includes a command-line tool that helps you understand the performance of your policies.
Given a policy query, the tool reports per-expression metrics including:
The need for profiler support became obvious after reviewing and optimizing several large policies. These policies relied on sophisticated search logic split across hundreds of lines of policy statements in multiple files. In many cases it was possible to improve performance significantly by simply tweaking how context was structured.
We hope that by providing a profiler, policy authors will be able to quickly identify the root cause of performance issues.
You can invoke the profiler on the command line via the opa eval subcommand. For example:
opa eval data.rbac.allow --data rbac.rego --format pretty --profile
By default, when profiling is enabled, OPA will output the top 10 most expensive expressions in the policy.
Example profiler output.
For more information on the profiler tool, see the new documentation page describing how to test your policies.
Finally, as of v0.9, OPA includes new APIs that allow callers to invoke Partial Evaluation via HTTP or in Go with the Rego package.
In the past, decisions returned by OPA were always definitive, e.g., callers would query for an "allow" or "deny" decision and the answer would always be "true" or "false". With partial evaluation exposed, OPA can return condition answers, e.g., "allow" is "true" if certain conditions are satisfied.
Later this week we will publish a blog post that describes how you can enforce data filtering policies in your storage layer with OPA by leveraging the new Compile API.