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

Question

目标

我想使用 keycloak 作为我的 minikube 集群的 oauth/oidc 提供程序。

问题

我对可用的文档感到困惑。

根据此文档， ngnix-ingress 可以使用注释处理外部身份验证

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

但从文档中并不清楚这里使用哪种身份验证。是 OAUTH/BASIC/SAML 吗？？？

例如，我没有找到任何变量来为入口提供 oauth CLIENTID。

其他发现

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

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

问题：

1. 我必须使用 oauth2-proxy 来实现 keycloak oauth 吗？
2. 我说的对吗 ngnix-ingress 没有直接连接到 keycloak 的功能？
3. 有没有关于 nginx.ingress.kubernetes.io/auth-method 和 nginx.ingress.kubernetes.io/auth-signin 到底在做什么的明确文档？
4. 是否有任何正确的方法/文档来构建user -> ngnix-ingress -> oauth2-proxy -> keycloak集成？

Answer 1

nginx 入口控制器文档提供了和的示例：auth-urlauth-signin

\n

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

\n

请注意，此功能仅适用于两个入口对象：

\n

\n

此功能是通过为单个主机部署多个 Ingress 对象来启用的。一个 Ingress 对象没有特殊注释并\n处理身份验证。

\n

然后可以通过要求用户针对第一个 Ingress 端点进行身份验证的方式来注释其他 Ingress 对象，并且可以将其重定向 401到同一端点。

\n

\n

本文档展示了如何使用这两个入口对象来实现此功能的一个很好的示例。

\n

因此，这里的第一个入口指向/oauth2随后在单独的入口对象中定义的路径，因为该入口对象没有为其自身配置身份验证。

\n

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

\n

前面提到的第二个入口定义了/oauth2同一域下的路径，并指向您的 ouauth2 代理部署，这也回答了您的问题之一

\n

第二个入口对象定义了 同一域下的/oauth2 路径，并指向 oauth2-proxy 部署：

\n

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

\n

\n

是否有任何明确的文档说明 nginx.ingress.kubernetes.io/auth-method 和\nnginx.ingress.kubernetes.io/auth-signin 到底在做什么？

\n

\n

该auth-method注释指定要使用的 HTTP 方法，而\nauth-signin指定错误页面的位置。请在此处查看有效的 nginx 控制器方法。

\n

需要了解/考虑的几点：

\n

\n

1. 主要目标是什么：

   \n

   --使用 OIDC 和 keycloak对 kubernetes 集群进行身份验证？

   \n

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

   \n

   -- minikube openid 身份验证：

   \n
\n

2. 使用 keycloak保护应用程序和服务

   \n

   Keycloak 支持 OpenID Connect（OAuth 2.0 的扩展）和 SAML 2.0。在保护客户和服务时，您需要决定的第一件事是要使用两者中的哪一个。如果您愿意，还可以选择使用 OpenID Connect 保护某些内容，使用 SAML 保护其他内容。

   \n

   为了保护客户端和服务的安全，您还需要一个适用于您选择的协议的适配器或库。Keycloak 带有适用于选定平台的自己的适配器，但也可以使用通用OpenID Connect 依赖方和 SAML 服务提供商库。

   \n

   在大多数情况下，Keycloak 建议使用 OIDC。例如，OIDC 也更适合 HTML5/JavaScript 应用程序，因为它比 SAML 更容易在客户端实现。

   \n

   另请参阅使用 Keycloak 文档向 Kubernetes Web 应用程序添加身份验证。

   \n
\n

\n