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

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


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 objectsfor a single host. One Ingress object has no special annotations andhandles authentication.

Other Ingress objects can then be annotated in such a way that requirethe user to authenticate against the first Ingress's endpoint, and canredirect 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/v1beta1kind: Ingressmetadata:  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: MYNAMESPACEspec:  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/v1beta1kind: Ingressmetadata:  name: oauth2-proxy  namespace: MYNAMESPACE  annotations:    cert-manager.io/cluster-issuer: designate-clusterissuer-prod    kubernetes.io/ingress.class: nginxspec:  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 andnginx.ingress.kubernetes.io/auth-signin are doing?

The auth-method annotation specifies the HTTP method to use whileauth-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.