search

vmware-archive / kube-prod-runtime

A standard infrastructure environment for Kubernetes
Apache License 2.0
761 stars 134 forks source link

Research a potential alternative for oauth2_proxy #229

Closed falfaro closed 5 years ago

falfaro commented 5 years ago

As of the 30th of August 2018 the oauth2_proxy project in GitHub has been officially declared as dead and the repository switched to read-only. This is as per https://github.com/bitly/oauth2_proxy/issues/628.

There are several alternatives:

  1. Some people are switching to https://github.com/buzzfeed/sso/blob/master/docs/quickstart.md
  2. Switching to other forks of oauth2_proxy like https://github.com/cisco-sso/oauth2_proxy
  3. Switching to https://github.com/containous/traefik
  4. Switching to Ambassador: https://www.getambassador.io/
  5. Keeping oauth2_proxy as it is

The goal of this issue is to investigate these options, see their pros and cons, and come up with a decision.

Non-goals: the actual implementation of the change

ridruejo-zz commented 5 years ago

We may want to take a look at oathkeeper, hydra, etc. : https://github.com/ory

aeneasr commented 5 years ago

Let me know if I can help (author here)

jjo commented 5 years ago

Some ~requirements and ideas after our meeting (Bitnami SRE), pasting from internal g/doc _SRE: BKPR is deprecating Oauth2proxy :

  1. Configuring or removing Oauth2 authentication to a BKPR service should be easy:
    • Should not require too much jsonnet code, using flags or even annotations/labels would be great
    • Services externally exposed requiring OAuth2 auth should have an easy way to skip auth if the request happens intra-cluster (common use case for this is prometheus and/or elasticsearch) by either:
      • Using NAME.NAMESPACE.svc.cluster.local urls (current case)
      • Potentially leveraging https via Ingress, for setups requiring e.g. prometheus to be reached only from Ingress namespace (i.e. via NetworkPolicies)
  2. Should be able and easy to use different OAuth2 providers, potentially different from the cloud where it’s running (e.g.. for Bitnami: using Google OAuth provider for every cluster, including AWS/kops)
  3. Currently BKPR provided oauth2_proxy requires one instance per protected ingress, something to consider would be switching to an implementation like https://github.com/buzzfeed/sso which uses a single auth frontend:
    • Would put authn protection as an Ingress stack feature in addition to encryption automation (as done already by cert-manager), obviously already pre-setup for Logging and Monitoring provided stacks.
    • Product-wise this would ease users wanting to protect their own service by leveraging BKPR provided SSO/OAuth2 setup
anguslees commented 5 years ago

Fwiw:

https://twitter.com/JoelASpeed/status/1084778031279980546 Last year, @Bitly archived their OAuth2_Proxy project. @pusher decided to keep the community alive and have taken on the project from here on out. After some migration work, we are now ready to start accepting issues and PRs. Spread the word! https://github.com/pusher/oauth2_proxy

It seems they (currently) have a 3.0.0 release which is identical to the bitly v2.2, except with changed references to repos, etc. There are a few commits to master since then, including some improvements to OIDC token refresh.

arapulido commented 5 years ago

I will close this one now, as we moved to pusher's version a while ago