ladon VS OPA (Open Policy Agent)

4. OPA evaluates the policies written in Rego against the input and returns a decision (allow or deny) back to your service.

What's good solid alternatives in Kubernets? Saw CASBIN, paid services, but nothing close to OPA/Rego. Please correct me if I'm wrong.

I found it's hard to convince everyone around to use OPA/Rego and wrap into a managed service. The main objection - wrapping another DSL (domain-specific language) is hard.

However it was relatively simple to convince my team to use featured complete Go library Ladon https://github.com/ory/ladon

Ladon is inspired by AWS IAM Policies.

{

Perfect for bundling extensive resources like opa policies

External Authorization System Using Policy engines like SpiceDB, OpenFGA, ORY Keto, OpenPolicy Agent (OPA), let you put your ReBAC rules in an external system and reference them from your queries. The main benefit you get from the centralized relationships model is it makes it possible to manage authorization centrally. This means that development teams can create new applications and add new relationships without needing to update any application code.

Going multicloud and multi-cluster can make it harder to maintain continual oversight of your security posture. Different clouds and cluster distributions may have their own security defaults and policy engines, so you need a mechanism that permits you to centrally roll out new configurations and compliance controls. Standardizing on a well-supported policy model such as Open Policy Agent (OPA) will make it easier to apply consistent settings to all your environments.

Open Policy Agent is an open-source policy engine recently graduated by the Cloud Native Computing Foundation (CNCF). Developed by the community and maintained by Styra, the OPA project aims to offer a unified framework to define, manage, and enforce policies through policies-as-code (PaC) across the technology stack layers of cloud-native applications.

Open Policy Agent (OPA) helps us write policy as code using Rego, a declarative language designed specifically for this reason.

The open source projects Fastly uses and the foundations we partner with are vital to Fastly’s mission and success. Here's an unscientific list of projects and organizations supported by the Linux Foundation that we use and love include: The Linux Kernel, Kubernetes, containerd, eBPF, Falco, OpenAPI Initiative, ESLint, Express, Fastify, Lodash, Mocha, Node.js, Prometheus, Jenkins, OpenTelemetry, Envoy, etcd, Helm, osquery, Harbor, sigstore, cert-manager, Cilium, Fluentd, Keycloak, Open Policy Agent, Coalition for Content Provenance and Authority (C2PA), Flux, gRPC, Strimzi, Thanos, Linkerd, Let’s Encrypt, WebAssembly. And the list goes on!

OPA - https://www.openpolicyagent.org/

Bart: Our numerous podcast discussions with seasoned professionals show that GitOps has been a recurring theme in about 90% of our conversations. Almost every guest we've interviewed has emphasized its importance, often mentioning it as their primary tool alongside other essentials like cert manager, Kyverno, or OPA, depending on their preferences.

Yeah, I fully agree. The tooling for putting that much logic into the database is just not great. I've been decently happy with Sqitch[0] for DB change management, but even with that you don't really get a good basis for testing some of the logic you could otherwise test in isolation in app code.

I've also tried to rely heavily on the database handling security and authorization, but as soon as you start to do somewhat non-trivial attribute-/relationship-based authorization (as you would find in many products nowadays), it really isn't fun anymore, and you spend a lot of the time you saved on manually building backend routes on trying to fit you authz model into those basic primitives (and avoiding performance bottlenecks). Especially compares to other modern authz solutions like OPA[1] or oso[2] it really doesn't stack up.

[0]: https://github.com/sqitchers/sqitch

[1]: https://www.openpolicyagent.org

[2]: https://www.osohq.com

How can we handle this? Are there any mechanisms to prevent or at least to some extent safeguard this kind of issues without falling back to a manual workflow? There is. One huge advantage of sticking to (de-facto) standards like Terraform is that first we are probably not the first ones to come up with this question and second there is a huge ecosystem around Terraform that might help us with such challenges. And for this specific scenario the solution is the Open Policy Agent. Let us take a closer look how the solution could look like.