OPA (Open Policy Agent) VS Keycloak

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.

A popular Policy-as-Code tool for Terraform is OPA, everyone's favorite versatile open-source policy engine that enforces security and compliance policies across your cloud-native stack, making it easier to manage and maintain consistent policy enforcement in complex, multi-service environments.

One common approach is to use an external Infinispan with a database persistence to store sessions outside of Keycloak, at least until version 26 makes the user session persistence feature (introduced in Keycloak version 25) a permanent part of Keycloak, moving beyond its previous preview status.

In today's interconnected digital landscape, companies often collaborate to provide seamless services to their users. In this post, we’ll explore a scenario involving two hypothetical companies: MyDoctor and MyHealth. We’ll demonstrate how MyHealth users can log in to MyDoctor using their MyHealth credentials, and how MyDoctor's backend can securely call MyHealth's APIs on behalf of the user. To achieve this, we’ll leverage OAuth 2 Token Exchange (RFC8693) with Spring Security and Keycloak.

Does not have LTS support so major version upgrades may be necessary when security patches are released. However, major version upgrades may cause breaking changes (which I have encountered a few times).

export KC_VERSION=24.0.4 curl -LO https://github.com/keycloak/keycloak/releases/download/"${KC_VERSION}"/keycloak-"${KC_VERSION}".zip

Keycloak is an open-source project created by RedHat for Single Sign-On. It provides an Identity and Access Management (IAM) solution designed to secure application services. Additionally, it enables users to authenticate through various identity providers and use fine-grained permissions for regulating access to Software as a Service (SaaS) applications.

In this article we'll be using Keycloak to quickly secure a Angular application with user management and single sign on (SSO) using the open source IAMs Keycloak for Authentication and Authorization. We will demonstrate the integration by securing a page for logged-in users. This quickly provides a jump-off point to more complex integrations.

Keycloak is definitely not small but you might find that you can ignore enough of the functionality to pretend that it is.

https://github.com/keycloak/keycloak

I also thought the assignment appeared when developers were refactoring the code, which might have been even more complicated before. In the end, I found that the function was originally created this way (commit).

GitHub: Keycloak GitHub Repository