What is proper design for authentication in kubernetes using nginx-ingress and keycloak

Question

Goal

I want to use keycloak as oauth/oidc provider for my minikube cluster.

Problem

I am confused with the available documentation.

According to this documentation ngnix-ingress can handle external authentication with annotations

• nginx.ingress.kubernetes.io/auth-method
• nginx.ingress.kubernetes.io/auth-signin

But it is not clear from the doc what kind of authentication is used here. Is it OAUTH/BASIC/ SAML ???

I have not found any variables to provide oauth CLIENTID for ingress for example.

Additional findings

I also have found this project https://github.com/oauth2-proxy/oauth2-proxy which seems to be what I need and provides following design

user -> ngnix-ingress -> oauth2-proxy -> keycloak

Questions:

1. Do I have to use oauth2-proxy to achieve keycloak oauth?
2. Am I right that ngnix-ingress does not have functionality for direct connection to keycloak?
3. Is there any clear documentation about what exactly nginx.ingress.kubernetes.io/auth-method and nginx.ingress.kubernetes.io/auth-signin are doing?
4. Is there any right way/documentation for building user -> ngnix-ingress -> oauth2-proxy -> keycloak integration?

Answer 1

The nginx ingress controller documents provide an example of auth-url and auth-signin:

...  
metadata:  
  name:  application  
  annotations:  
    nginx.ingress.kubernetes.io/auth-url: "https://$host/oauth2/auth"  
    nginx.ingress.kubernetes.io/auth-signin: "https://$host/oauth2/start?rd=$escaped_request_uri"  
  ...

Please be aware of that this functionality works only with two ingress objects:

This functionality is enabled by deploying multiple Ingress objects for a single host. One Ingress object has no special annotations and handles authentication.

Other Ingress objects can then be annotated in such a way that require the user to authenticate against the first Ingress's endpoint, and can redirect 401s to the same endpoint.

This document shows a good example how those two ingress objects are used in order to have this functionality.

So the first ingress here points to /oauth2 path which is then defined in separate ingress object since this one does not have auth configured for itself.

apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  annotations:
    kubernetes.io/ingress.class: nginx
    nginx.ingress.kubernetes.io/auth-url: "https://$host/oauth2/auth"
    nginx.ingress.kubernetes.io/auth-signin: "https://$host/oauth2/start?rd=$escaped_request_uri"
  name: external-auth-oauth2
  namespace: MYNAMESPACE
spec:
  rules:
  - host: foo.bar.com

The second ingress as mentioned earlier defines the /oauth2 path under the same domain and points to your ouauth2 proxy deployment which also answers one of your question that you

The second ingress objects defines the /oauth2 path under the same domain and points to the oauth2-proxy deployment:

apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
  name: oauth2-proxy
  namespace: MYNAMESPACE
  annotations:
    cert-manager.io/cluster-issuer: designate-clusterissuer-prod
    kubernetes.io/ingress.class: nginx
spec:
  rules:
  - host: foo.bar.com
    http:
      paths:
      - backend:
          serviceName: oauth2-proxy
          servicePort: 80
        path: /oauth2

Is there any clear documentation about what exactly nginx.ingress.kubernetes.io/auth-method and nginx.ingress.kubernetes.io/auth-signin are doing?

The auth-method annotation specifies the HTTP method to use while auth-signin specifies the location of the error page. Please have a look at valid nginx controllers methods here.

Couple of points to know/consider:

1. What is the main goal:

   -- authentication to kubernetes cluster using OIDC and keycloak?

   -- using dex: https://dexidp.io/docs/kubernetes/

   -- minikube openid authentication:

2. Securing Applications and Services using keycloak

   Keycloak supports both OpenID Connect (an extension to OAuth 2.0) and SAML 2.0. When securing clients and services the first thing you need to decide is which of the two you are going to use. If you want you can also choose to secure some with OpenID Connect and others with SAML.

   To secure clients and services you are also going to need an adapter or library for the protocol you’ve selected. Keycloak comes with its own adapters for selected platforms, but it is also possible to use generic OpenID Connect Relying Party and SAML Service Provider libraries.

   In most cases Keycloak recommends using OIDC. For example, OIDC is also more suited for HTML5/JavaScript applications because it is easier to implement on the client side than SAML.

   Please also have look at the adding authentication to your Kubernetes Web applications with Keycloak document.