Moving forward with ORY Oathkeeper

[aeneasr]

As ORY Oathkeeper adoption picks up, we've made a couple of observations:

• Most use cases involve an existing API Gateway (e.g. Envoy) that should talk to ORY Oathkeeper instead of running ORY Oathkeeper as a reverse proxy.
• Most use cases don't need (don't want) a database in the background for storing and managing rules.
• Deployment complexity is not negligible because of two services running.
• Configuration complexity is high.

Thus, we think a refactoring of the ORY Oathkeeper vision is up next. There are some goals:

First, we believe that Access Rules are something static. They should be updated when the application changes and they should be reviewed by an at least 4 eye principle. One of the best ways to achieve that is by allowing ORY Oathkeeper to read (and watch) rules from the filesystem. This would allow workflows that run on top of Git and a CI/CD pipeline.

Second, we want to make ORY Oathkeeper as lightweight as possible. Therefore, we will remove the SQL dependency and replace it with the following retrieval strategies:

• Watching access rules from the file system
• Watching access rules from a remote url http//my-rules.com/rules.json
• Watching access rules from k8s CRDs

This would completely eliminate the need for oathkeeper serve api and reduce deployment complexity significantly. Instead, there will be one command oathkeeper serve that runs two ports:

• 4455: The reverse proxy
• 4456: A port that exposes metrics (Prometheus), tracing, health check endpoints, the judge API, and the JWKS Webfinger URL (./well-known/jwks.json)

Third, we want to support 3rd party credential stores like Vault, AWS/GCP/Azure KMS for signing tokens and Headers, Cookies, ...

Fourth, what's known as "credentials issuers" will in the future be called "transformers" as they transform the incoming request.

Fifth, we want to support configuration reloading without downtimes. This follows development in ORY Hydra and ORY Hive.

Please let us know what you think about this!

[kminehart]

I like all of this. Especially refactoring away the SQL storage.

This would make it really easy to have a Terraform provider to define Oathkeeper rules (yay gitops)

[wesleyfantinel]

Looking forward for this.

I'am planing to implement Oathkeeper in one Kubernetes cluster running with Hydra, but the fact that it needs a SQL storage for the rules, makes harder to fit into our gitops and CI/CD flows. Configuring the access rules from file system or k8s CRDs would solve this drawback.

Plus, working with Ambassador (which is on top of Envoy) looks like to achieve the authentication process of upcoming requests, we only need a service (https://www.getambassador.io/user-guide/auth-tutorial/#authentication), nothing to do with an reverse proxy.

Anyway, appreciate your efforts. We'll do my best to help.

[piotrmsc]

I like it too! Sounds like a really nice plan!
Would be nice also to integrate it "natively" with istio mesh. Perhaps via mixer adapter - basically to get rid of an additional reverse proxy and make use of envoy and istio functionality.

[aeneasr]

What would be required for it to work natively with istio? We/I haven't used Istio really so far so it would be really cool if you could share some insights!

[piotrmsc]

First thought is mixer adapter and its authorization template, however, this has a small drawback because it's a compiled in adapter. So mixer would have to be compiled and would be nice if in the end, it was part of istio official builtin adapters :)

More info about adapters here

[aeneasr]

I haven't worked with istio/envoy/mixer extensively, but I think that I heard that they support an adapter that works with HTTP APIs, which would most likely be compatible with Oathkeeper's Judge API. If not, happy to figure out a way to make it work natively with Istio!