nginx 入口控制器文档提供了和的示例:auth-url
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"
...
请注意,此功能仅适用于两个入口对象:
通过为单个主机部署多个 Ingress 对象来启用此功能。一个 Ingress 对象没有特殊的注释并处理身份验证。
然后其他 Ingress 对象可以被注释,要求用户对第一个 Ingress 的端点进行身份验证,并且可以将 401
s 重定向到同一个端点。
本文档展示了如何使用这两个入口对象以实现此功能的一个很好的示例。
所以这里的第一个入口指向/oauth2
路径,然后在单独的入口对象中定义,因为这个入口没有为自己配置身份验证。
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
前面提到的第二个入口定义了/oauth2
同一域下的路径并指向您的 ouauth2 代理部署,这也回答了您的一个问题
第二个 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
是否有关于 nginx.ingress.kubernetes.io/auth-method 和 nginx.ingress.kubernetes.io/auth-signin 到底在做什么的明确文档?
注释指定要使用的auth-method
HTTP 方法,同时
auth-signin
指定错误页面的位置。请在此处查看有效的 nginx 控制器方法。
需要了解/考虑的几点:
主要目标是什么:
--使用 OIDC 和 keycloak对 kubernetes集群进行身份验证?
-- 使用 dex:https ://dexidp.io/docs/kubernetes/
-- minikube openid 认证:
使用 keycloak保护应用程序和服务
Keycloak 支持 OpenID Connect(OAuth 2.0 的扩展)和 SAML 2.0。在保护客户端和服务时,您需要决定的第一件事是您将使用两者中的哪一个。如果您愿意,您还可以选择使用 OpenID Connect 保护一些,使用 SAML 保护其他一些。
为了保护客户端和服务,您还需要一个适用于您选择的协议的适配器或库。Keycloak 自带适用于选定平台的适配器,但也可以使用通用OpenID Connect 依赖方和 SAML 服务提供程序库。
在大多数情况下,Keycloak 建议使用 OIDC。例如,OIDC 也更适合 HTML5/JavaScript 应用程序,因为它比 SAML 更容易在客户端实现。
另请查看使用 Keycloak 文档向您的 Kubernetes Web 应用程序添加身份验证。