Replacing Keycloak with Ory in k3s.

[IngwiePhoenix]

Hello there!

While I was digging into the Go ecosystem of modules, libraries and general cool projects, I came across Ory and immediately wanted to replace Keycloak with it. It is not a bad software, by all means, but:

PS Z:\Work\Homelab> kubectl top pod -A --sort-by memory
NAMESPACE           NAME                                                              CPU(cores)   MEMORY(bytes)
keycloak            keycloak-app-5748968578-gjz2h                                     2m           1422Mi

This speaks for itself. The only service following it is Netdata, which I intend to replace with Influx+Grafana.

The reason I want to switch to Ory is mainly Oathkeeper as it might finally solve my problem of securing "insecure" frontends (meaning those that lack any and all authorization, like the Zalando Postgres Cluster UI) using Traefik's ForwardAuth middleware. And, since Oathkeeper is part of the Ory suite of tools - Hydra and Kratos - I might as well commit completely and install all three.

What I seek to do:

• Use Kratos to manage a few local users,
• integrate Discord Oauth2 as a social login and use the guilds to determine groups to allow people on certain servers to access some of my hosted stuff,
• Use a ForwardAuth Traefik Middleware that I can reference from basically wherever with the enabled cross-namespace support,
• bind apps that do support OIDC directly to the setup to avoid having to "start over" each and every time.

For example: LocalAI supports "logging in" by being passed a header containing the user's E-Mail address. Meanwhile, Headlamp and Kubectl support OIDC directly for logging in and the middleware can be used for anything that straight up doesn't have any of this whilst excluding it on API endpoints that authenticate/authorize otherwise.

So far, so good; I know what I want and I have tried a few systems before (Authentik, Logto, Keycloak, oauth2-proxy, ...) and now I would like to try Ory.

Using k3s' built-in HelmController I can install virtually any chart directly through a manifest; and using the Zalando Postgres Operator, I can provision a user plus database and spawn a secret with the credentials in the target namespace which I can then immediately reference; I don't even need to see the password once.

I have so far looked into the Kratos and Hydra chart values to see what exactly I need and there are a few questions I ran into:

• Both of them designate a dsn. Now, I will have to take the (...).env[].name=DSN route for all of them to properly define the credentials using the secret created by the operator. But; do they need or should they have separate databases or is it enough to use but a single one?
• Hydra specifies an issuer and alike; I suppose that is the reference to Kratos. What URL do I use here exactly? After all, I want to use both local users and social-login users in the end. Both live in the same namespace for simplicity (ory) and Oathkeeper will join them. Though I am not sure if that is the right approach - there are a lot of components in both Hydra and Kratos - and I haven't done a deep read into Oathkeeper just yet.
• Where is the documentation for Kratos' identitySchemas? For now, I copied and saved the default, but it relies extremely on the E-Mail address and does not mention a username whatsoever. I want to use username or email plus password from local users, whilst "remote" users would have their username and email provided by the respective IdP.

Would appreciate some pointers in the right direction!

The reason I want to go with the self-hosted route is simple: Experience. And, well, because I have four ARM nodes and a RISC-V board here and want to put some work on them. :) The cluster runs mainly at home, but is actually exposed through a VPS which are all joined into a Headscale network - and this is primarily why I need this. While I am at home, I may opt to skip the middleware when there is no need to use it (i.e. $ip in 192.168.2.0/24) but require it from anything that comes from the outside - at least, selectively. Some services might still need the middleware still.

Thank you very much and kind regards,
Ingwie

PS.: I did not know which discussion to put this into, so when I visited the forum and saw the links, I rolled a dice... Hope I am right here ^^;

[vinckr]

Hello @IngwiePhoenix
Thanks for the detailed write up!
How has it been going so far?

As far as I can tell you probably don't need Ory Hydra for your use case - just using Ory Kratos and Oathkeeper would suffice I think.

You can learn more about the identity schemas here, there are also some examples: https://www.ory.sh/docs/kratos/manage-identities/identity-schema

[IngwiePhoenix]

I haven't been able to make much progress - too many open questions to really get anywhere, really. Just knowing where what goes in terms of database (shared, separated) would help a lot.

[vinckr]

You only need one database for Ory Kratos. If you decide to also use Hydra for something else, I would recommend to get it a dedicated db.