简体   繁体   English

使用 nginx-ingress 和 keycloak 在 kubernetes 中进行身份验证的正确设计是什么

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

Goal目标

I want to use keycloak as oauth/oidc provider for my minikube cluster.我想使用 keycloak 作为我的 minikube 集群的 oauth/oidc 提供程序。

Problem问题

I am confused with the available documentation.我对可用的文档感到困惑。

According to this documentation ngnix-ingress can handle external authentication with annotations根据此文档,ngnix-ingress 可以使用注释处理外部身份验证

  • nginx.ingress.kubernetes.io/auth-method nginx.ingress.kubernetes.io/auth-method
  • nginx.ingress.kubernetes.io/auth-signin 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???是 OAUTH/BASIC/SAML 吗???

I have not found any variables to provide oauth CLIENTID for ingress for example.例如,我没有找到任何变量来为入口提供 oauth CLIENTID。

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我还发现了这个项目https://github.com/oauth2-proxy/oauth2-proxy这似乎是我需要的并提供以下设计

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

Questions:问题:

  1. Do I have to use oauth2-proxy to achieve keycloak oauth?我是否必须使用 oauth2-proxy 来实现 keycloak oauth?
  2. Am I right that ngnix-ingress does not have functionality for direct connection to keycloak?我说 ngnix-ingress 没有直接连接到 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? 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?是否有任何正确的方法/文档来构建用户 -> ngnix-ingress -> oauth2-proxy -> keycloak集成?

The nginx ingress controller documents provide an example of auth-url and auth-signin : nginx 入口 controller 文档提供了auth-urlauth-signin 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.通过为单个主机部署多个 Ingress 对象来启用此功能。 One Ingress object has no special annotations and handles authentication.一个 Ingress object 没有特殊的注解并处理身份验证。

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 401 s to the same endpoint.然后其他 Ingress 对象可以被注释,要求用户对第一个 Ingress 的端点进行身份验证,并且可以将401重定向到同一个端点。

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.所以这里的第一个入口指向/oauth2路径,然后在单独的入口 object 中定义,因为这个入口没有为自己配置身份验证。

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前面提到的第二个入口定义了同一域下的/oauth2路径并指向您的 ouauth2 代理部署,这也回答了您的一个问题

The second ingress objects defines the /oauth2 path under the same domain and points to the oauth2-proxy deployment:第二个 ingress 对象定义了同域下的/oauth2路径,并指向 oauth2-proxy 部署:

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? 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. auth-method注释指定要使用的 HTTP 方法,而auth-signin signin 指定错误页面的位置。 Please have a look at valid nginx controllers methods here .请在此处查看有效的 nginx 控制器方法。

Couple of points to know/consider:需要了解/考虑的几点:

  1. What is the main goal:主要目标是什么:

    -- authentication to kubernetes cluster using OIDC and keycloak? -- 使用 OIDC 和 keycloak 对 kubernetes集群进行身份验证?

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

    -- minikube openid authentication : -- minikube openid 认证

  2. Securing Applications and Services using keycloak使用 keycloak保护应用程序和服务

    Keycloak supports both OpenID Connect (an extension to OAuth 2.0) and SAML 2.0. Keycloak 支持 OpenID Connect(OAuth 2.0 的扩展)和 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.如果您愿意,您还可以选择使用 OpenID Connect 保护一些,使用 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. Keycloak 自带适用于选定平台的适配器,但也可以使用通用OpenID Connect 依赖方和 SAML 服务提供程序库。

    In most cases Keycloak recommends using OIDC.在大多数情况下,Keycloak 建议使用 OIDC。 For example, OIDC is also more suited for HTML5/JavaScript applications because it is easier to implement on the client side than SAML.例如,OIDC 也更适合 HTML5/JavaScript 应用程序,因为它比 SAML 更容易在客户端实现。

    Please also have look at the adding authentication to your Kubernetes Web applications with Keycloak document.另请查看使用 Keycloak 文档向您的 Kubernetes Web 应用程序添加身份验证

声明:本站的技术帖子网页,遵循CC BY-SA 4.0协议,如果您需要转载,请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM