用于多个应用程序的Kubernetes SSO Github OAuth

Question

这就是交易。我正在使用Kubernetes，我想保护集群内的应用程序。因此，我添加了一个oauth2代理，如果用户没有登录，它会重定向到GitHub。登录完成后，用户将重定向到应用程序(登录图(。目前，我有两个echo-http服务器(echo1和echo2(和Jenkins的伪部署。我在本地用minikube做所有事情，所以请不要介意域名。

在Jenkins中，我安装了Github OAuth插件，并按照我发现的多篇帖子中所说的进行了配置(例如Jenkins Github OAuth(。还创建了GitHub OAuth应用程序并设置了回调。由于我想为Jenkins之外的多个应用程序提供SSO，因此我将调用设置回https://auth.int.example.com/oauth2/callback而不是https://jenkins.int.example.com/securityRealm/finishLogin.因此，在登录GitHub后，我被重定向到Jenkins网页，但作为一名访客。如果我尝试登录，结果会出错。我使用Helm设置oauth2代理(家中的k8s/oauth2代理人(

我是不是错过了什么？

这些是我正在使用的oauth2代理和入口控制器的入口配置。

Nginx入口

apiVersion: networking.k8s.io/v1beta1
kind: Ingress
metadata:
name: echo-ingress
annotations:
kubernetes.io/ingress.class: nginx
certmanager.k8s.io/cluster-issuer: letsencrypt-prod
nginx.ingress.kubernetes.io/auth-url: "https://auth.int.example.com/oauth2/auth"
nginx.ingress.kubernetes.io/auth-signin: "https://auth.int.example.com/oauth2/start?rd=https%3A%2F%2F$host$request_uri"
spec:
tls:
- hosts:
- echo1.int.example.com
- echo2.int.example.com
- jenkins.int.example.com
secretName: letsencrypt-prod
rules:
- host: echo1.int.example.com
http:
paths:
- backend:
serviceName: echo1
servicePort: 80
- host: echo2.int.example.com
http:
paths:
- backend:
serviceName: echo2
servicePort: 80
- host: jenkins.int.example.com
http:
paths:
- path:
backend:
serviceName: jenkins-service
servicePort: 8080
- path: /securityRealm/finishLogin
backend:
serviceName: jenkins-service
servicePort: 8080

OAuth2代理配置

config:
existingSecret: oauth2-proxy-creds
extraArgs:
whitelist-domain: .int.example.com
cookie-domain: .int.example.com
provider: github
authenticatedEmailsFile:
enabled: true
restricted_access: |-
my_email@my_email.com 
ingress:
enabled: true
path: /
hosts:
- auth.int.example.com
annotations:
kubernetes.io/ingress.class: nginx
certmanager.k8s.io/cluster-issuer: letsencrypt-prod
tls:
- secretName: oauth2-proxy-https-cert
hosts:
- auth.int.example.com

Answer 1

您在那里构建的身份验证架构很好！

我想说，你可能忽略了Jenkins有自己的身份验证这一事实。您还需要将Jenkins本身配置为允许通过Github访问Oauth2。

那么到底发生了什么呢？您的Oauth代理解决方案非常棒。您可以在k8s集群中构建应用程序，而不必担心直接从应用程序进行用户管理或身份验证。然而，这只适用于没有自己身份验证机制的应用程序。Oauth代理只是保护对后端Web服务器的访问。一旦你被代理允许，你就可以直接与应用程序交互，所以如果应用程序需要身份验证，你作为最终用户也会这样做。

我的建议是，对没有用户管理机制的应用程序使用Oauth代理，并对Jenkins等具有身份验证机制的应用软件开放访问。否则，您可能会使用双重身份验证(在本例中为proxy和Jenkins(，这就不那么好了。

然后，为了保持使用Github帐户访问集群的高级概念，您需要将这些基于用户的应用程序配置为也使用GithubOauth2。这样，对集群的访问是同质的(你只需要你的Github帐户(，但实际的集成有两种不同的类型：不需要用户管理的应用程序(它们受到Oauth代理的保护(和具有身份验证的应用程序，然后用Github的Oauth2独立配置。