Sunsetting Louketo Project

[abstractj]

Sunsetting Louketo Project

After careful consideration, we have decided to pull the plug on Louketo and start the EOL procedure. The plan is during the next 3 months to fix only critical bugs and security issues. Everyone interested in capabilities provided by Louketo Proxy should look at OAuth2 Proxy project which is providing a similar set of capabilities and has a healthy and active community.

A few months ago, the Keycloak team started Louketo — a joint effort to build a generic OAuth2 Proxy and possibly also begin an umbrella project for a set of OIDC related integration libraries. The initial set of goals has not worked out. Keycloak Gatekeeper and OAuth2 Proxy projects hoped to merge and join efforts but for various reasons, this has not worked out.

With Louketo and OAuth2 proxy providing similar features, OAuth Proxy being a more popular project with a bigger community we reached a conclusion there's no reason to put more effort into Louketo, when we can just contribute there.

What does it mean in practice?

FAQ

Will Louketo Proxy be no longer maintained? Will there be no new releases?

Critical bug fixes will be merged and micro releases provided for the next 3 months. It is up to community members to step up and take over maintaining and driving this project further if they wish to do so. Please contact the Keycloak developers on the dev mailing list or add your comments here.

Are there any alternatives I should use instead?

OAuth2 Proxy is very close in a set of capabilities to Louketo Proxy and we highly suggest you investigate it as a replacement.

How do I migrate to OAuth2 Proxy?

We’ll provide high-level guidance on how to migrate. Although unfortunately there is no comprehensive guide nor magical script. Some corner cases, specific configurations, and capabilities may not be fully covered or addressed in exactly the same way.

Why are you abandoning Louketo Proxy as a project?

Initial goals failed. Which were merging with OAuth2 Proxy and creating a wider set of OAuth2/OIDC integration libraries. Some individuals originally interested in collaboration took a step back. The end result is the Louketo project duplicating efforts and capabilities of other much more popular projects - OAuth2 Proxy. As we believe in OpenSource we just don’t want to follow NIH syndrome :)

I would like to keep maintaining Louketo - what should I do?

Please comment on this GitHub issue so others can join the discussion. We’ll take it from there :)

What happens if nobody will step up to maintain Louketo?

After 3 months Louketo repository will be archived and made read-only.

[ramshazar]

@abstractj does that mean that both Keycloak Gatekeeper and Louketo Proxy will not be maintained anymore?

[abstractj]

@ramshazar that's correct. That's explained in the FAQ.

[leopku]

Took long time to migrate to OAuth2-Proxy but still failed with checking all things step by step according to documents again and again.

My personal conclusion, for now louketo-proxy is simple and powerful. More important, it working well as expected. I'll stay louketo-proxy for long time.

[hakoerber]

Hey, is it planned to add a notice to the README? Currently it still states the following:

This repository is a work in progress

This is quite confusing for someone stumbling upon this repository. I propose a note at the top, something akin to this:

NOTE: This project has entered the EOL procedure and will only receive fixes for critical bugs and security issues. Take a look at OAuth2 Proxy project for similar functionality. More info here.

If you want, I can open a pull request.

[Damientinker]

Hey, Sorry to hear the project is EOL'ed. But understandable if the goals have not been fulfilled. Maybe someone will want to maintain it. The more Options the better

In that vein, here are some other projects ( hope that’s ok, it’s a tiny bit off topic ! ). None of these are a 1-1 replacement to Gatekeeper, so don’t expect to just plug and play. And both off these will likely require more adaption of existing tooling & infrastructure then switching to oauth2proxy. There are likely many others

There is the Pomerium Project:
Github:
https://github.com/pomerium/pomerium
Docs:
https://www.pomerium.io/docs/

Or the Ory.sh (Oathkeeper)
Github:
https://github.com/ory/oathkeeper
Docs:
https://www.ory.sh/oathkeeper/docs/reference/configuration

[nneul]

Would like to see suggested examples for how to adapt one specific element that louketo provides that does not seem to be available in oauth2-proxy - --headers=Authorization=Bearer XXXXXX

i.e. being able to add a static header to upstream request. In particular, for the very basic use case of "I want to simply expose my k8s dashboard"

I'm not seeing any way to support that function with oauth2-proxy.

[abstractj]

@nneul please ask on the oauth2-proxy mailing list, it's the best place to understand the details of oauth2-proxy.

[fadao23]

Hello @abstractj, where is the

We’ll provide high-level guidance on how to migrate.

Thanks.

[abstractj]

@fadao23 are you looking for something specific? What kind of guidance you need?

[fadao23]

@fadao23 are you looking for something specific? What kind of guidance you need?

Louketo/Gatekeeper works with "resources" restrictions.

Acutally I do not find in the Oauth2-proxy documentation something similar, we just can restrict access by "groups".

Do you know how reproduce the "resources" restriction provide by louketo in Oauth2-proxy ?

Thanks

[p53]

i will miss forward-signing feature of louketo, will see if something like that will find in other proxies

[p53]

ok to all, these are my findings, when roughly checking for my requirements for proxy:

• pomerium is not able to do bearer token validation
• oathkeeper does not implement forwarding of token - probably in rework it will be there
• oauth2-proxy seems to be mess to me, quite confusing docs of options and also looking at code doesn't make me very persuaded - i configured it for both auth_code flow and validating bearer token but it was a little bit pain
• all these does not support forward signing

[p53]

Would like to see suggested examples for how to adapt one specific element that louketo provides that does not seem to be available in oauth2-proxy - --headers=Authorization=Bearer XXXXXX

i.e. being able to add a static header to upstream request. In particular, for the very basic use case of "I want to simply expose my k8s dashboard"

I'm not seeing any way to support that function with oauth2-proxy.

this might be option --pass-authorization-header=true

[p53]

@fadao23 are you looking for something specific? What kind of guidance you need?

Louketo/Gatekeeper works with "resources" restrictions.

Acutally I do not find in the Oauth2-proxy documentation something similar, we just can restrict access by "groups".

Do you know how reproduce the "resources" restriction provide by louketo in Oauth2-proxy ?

Thanks

for keycloak provider there is - --keycloak-group, but you are not able to set specific paths for different groups etc...

[nneul]

I'd be fine with oauth2 proxy other than that it seems to have a glaring missing capability, and that is just adding a static header.

i.e. the --headers=... option for louketo - which I use to send a fixed/static bearer token to upstream.

I could use oauth2 proxy in conjunction with other stuff to get that accomplished, but that's just extra steps.

[malys]

I agree with @p53 .I have tested alternatives of louketo proxy (pomerium,oathkeeper,oauth2-proxy). I'm not convinced by none of them (missing features, documentation not clear or not updated, chaotic parameters,...)Currently, I'm not ready to use them in production. Knowing Keycloak, Louketo integration was efficient and full featured. For me, Louketo is more accomplished than known alternatives (Are there other candidates to replace louketo?)
@abstractj @stianst Because of difficulties to find a valid successor, EOL in november would be too soon? Could you reconsider your decision?

PS: It could be interesting to change Readme to add EOL informations.

[SeWieland]

For me it seems that the auth approach between the projects is quite different.
oauth2_proxy is more intended to be a global SSO solution for all services in a cluster at once (one proxy as ingress / right behind the ingress), whereas gatekeeper/louketo serves as sidecar container proxy directly in the pod, providing you with SSO and potentially very fine-grained access control to specific services.
Using oauth2_proxy as a sidecar container is possible, however without all the benefits and I had some issues with session inconsistencies as well using it that way... 🤔

[stianst]

Afraid we really don't have capacity to maintain Louketo/Gatekeeper at this point. It was intended that folks from OAuth 2 proxy (and another group) was going to help out with Louketo, hence the move from Keycloak Gatekeeper to a new project. However, they pulled out after we had moved the repo, leaving us in a fairly uncomfortable situation.

Personally, I do think Louketo/Gatekeeper has a better experience and is simpler to use than other options, but we just don't have the team around it to maintain it I'm afraid.

I would love to see a group of people take ownership of Louketo/Gatekeeper and make something really nice out of it, but we haven't had anyone step up to do that (at least not that I'm aware of).

[ackerleytng]

I'm considering stepping up to keep louketo going!

I used gatekeeper because it was almost paired with keycloak back then, and I assumed that gatekeeper would just have the best integration with keycloak.

I'll take a quick look at oauth2-proxy to make sure that louketo/gatekeeper at least fills a niche that oauth2-proxy isn't intended for.

From #683 (comment), it seems that the alternatives are just missing features in the near term. Does anyone know if there's a specific niche that louketo fills?

I did feel that louketo provided a better experience. @stianst, do you see the experience as louketo's defining feature?

Is anyone else interested in maintaining louketo too?

[dnini96]

I'm considering stepping up to keep louketo going!

That would be really awesome!

I'll take a quick look at oauth2-proxy to make sure that louketo/gatekeeper at least fills a niche that oauth2-proxy isn't intended for.

From #683 (comment), it seems that the alternatives are just missing features in the near term. Does anyone know if there's a specific niche that louketo fills?

What I miss in other solutions is:

1. fine-grained access control/authorization(let user with role X only use POST on path Y, whitelist url x,y,z etc.)
2. ease-of-use. Setting it up is like 5 minutes work.
3. support for roles (there's an issue for that in OAuth2-Proxy)
4. proper documentation

Some solutions provide No. 4 , but the rest are core features that only Louketo provides.

I did feel that louketo provided a better experience. @stianst, do you see the experience as louketo's defining feature?

Is anyone else interested in maintaining louketo too?

I would love to do that, but as an Ops guy with not much experience coding, (I have only (badly) written my fair share of bash/Python scripts and some OO Java/C# in college.) don't think I am capable of doing that. I can however step up and let others know that there certainly is interest to keep Louketo alive. We were just looking to implement it in the company I work for. It would be a real PITA to have to stop that, as there are no alternatives.

Was really sad when I read Louketo reaching EOL, as I really like it. I sincerely hope others jump in on your initiative.

Thank you in advance anyway. :)

[p53]

@ackerleytng for me main problem of oauth2 was that it supports many things but it is not clear from docu which options belong to which type of provider+i wrote issue about forward signing and client credentials grants and they wrote there that oauth2 wasn't intended for not-user authentication, so probably this is main difference louketo is more service to service oriented and simpler because it doesnt support all those vendor oauth2 modifications. maybe i would join with few commits too, i am really interested in that client credentials pull request which is already there

[p53]

oauth2-proxy/oauth2-proxy#810 (comment)

[ackerleytng]

Okay! When I used gatekeeper, I used it because it was simple to understand and use. Thanks for all the suggestions!!

Louketo/gatekeeper seems to have found a niche in software with a few services, that need authentication and authorization, and also a forward signing proxy.

Louketo is like the little all-in-one executable that gets software off the ground and guides you to set up the correct auth settings. (Let me know if you have a nicer sound bite for the future landing page)

I'll get in touch with the current maintainers to see if there are any licensing constraints if I want to step up.

For the next few months I think we should first try and reverse the announcement on sunsetting! I've seen some articles mark louketo as EOL. I'll also start off by reviewing and improving docs, which was a key feature people like.

[GerkinDev]

Hey @ackerleytng , have you a fork somewhere I can see ? I would be glad to try to find some time to contribute, and make some suggestions.

[ackerleytng]

I don't have a fork now. I'm new to being a maintainer and would like to learn.

@stianst how do you currently maintain louketo? Who gets to merge to the louketo project?

[stianst]

@ackerleytng As it stands Louketo is EOL on 21st November and we will only merge security related issues, or critical regressions. We will only do another release of Louketo if it is absolutely needed.

We would welcome others to take ownership and continue the maintenance of Louketo. We'd have to define a group of maintainers that sign-up to owning the project, and have a conversation about how the transfer could be done.

@abstractj FIY

[statik]

@ackerleytng there is also a fork here https://github.com/oneconcern/keycloak-gatekeeper.

[ackerleytng]

Cool! Maybe they would be willing to maintain louketo instead!

[malys]

@ackerleytng Hi, Any news about the possibility to maintain louketo with a new team ?
The EOL is coming and I would like to know if louketo is really dead to migrate to oauth-proxy.

[malys]

@statik Have you contacted @fredbi from oneconcern to exchange and to know his position about louketo maintenance?

[ackerleytng]

I was waiting for @abstractj and @stianst to define the group of maintainers and discuss the transfer. Let me also reach out to someone from oneconcern.

[statik]

@malys I have not. I have a project https://github.com/kindlyops/havengrc that was using keycloak gatekeeper before it was briefly renamed to louketo. My plan is to simply work on porting HavenGRC to https://github.com/oauth2-proxy/oauth2-proxy and work with the existing oauth2-proxy community to make any fixes or enhancements that I need.

[fredbi]

@ackerleytng there is also a fork here https://github.com/oneconcern/keycloak-gatekeeper.

I am the current maintainer of that fork. I am not actively adding features but keep currently focused on my main use case.
PRs to this fork from other contributors are welcome.

I've tried hard in the past to keep in line with the gatekeeper's master before eventually deciding to fork away and step back from the original repo.

[malys]

Thanks @ackerleytng @statik @fredbi. I'm pessimist about louketo future. With a heavy heart, I will to switch to oauth2-proxy v7.
Thanks to louketo community.

[fredbi]

@malys @ackerleytng @statik we could just fork this and set new targets, besides just maintaining backward compatibility with Gatekeeper (sorry I could never get used to the short-lived "louketo" name :) ).

It would take but a couple of volunteers joining forces to make something out of this codebase.

What I'd like is:

1. Keep keycloak as a reference implementation, but not constrain users with keycloak
2. Split away from the Keycloak governance structure, mailing lists, jira and similar impediments
3. Set clearer targets about the use cases we want to cover
4. Set up for modern cloud-based infrastructure, with baked helm chart, and possibly, integration with extensible service meshes (e.g. Traefik)

In short, if, say, 5 such volunteers declare here their will to dedicate some of their time to this project and agree with my 4 bullet points above, I'd be happy to continue working on this next year.

[p53]

@fredbi i would give some help, from what i've seen there are some quite old dependencies there, so it would need update

[ackerleytng]

@fredbi I'm with you on that. :)

[fredbi]

@ackerleytng @p53 @malys @statik @GerkinDev

After an offline discussion with @ackerleytng, we have decided to continue maintaining this piece of software.

I think that we can skip the repo transfer and just start with a fork.

https://github.com/go-gatekeeper/oauth-gatekeeper

[I can still change the name if you have a better proposal - I just didn't like the sound of Louketo] :)

The first immediate action would be to collect available documentation and setup CI etc.

I have a lot of updates to contribute back from my fork, especially re-obsolete dependencies. I guess most early contributors just did the same....

I'd like this to be part of the keycloak contributed eco-system and remain interoperable with keycloak out-of-the-box.

@stianst @abstractj feel free to chime in, should you have any piece of advice or gotchas we should avoid.

[statik]

@fredbi sounds great! I will try to help

[ackerleytng]

Do join us on discord at https://discord.gg/Eq4rnkeMmP! @statik especially you!