本文共 1921 字,大约阅读时间需要 6 分钟。
本文是的下篇,将图文详解如何使用基于的为自身本没有认证授权功能的Web站点实现认证及授权。
示例是使用的服务作为K8S环境。鉴于K8S的应用运行时属性,该示例也可以部署在其他云厂商托管的K8S。
web.kane.mx
oauth.kane.mx
<http or https>/<认证服务域名>/oauth2/callback
。记录下来应用的appId
和appSecret
。EKS集群中工作节点的公网IP
或者NAT EIP
,取决于工作节点如何访问Internet。并记录下来应用appKey
和appSecret
。values.yaml
中的dingtalk_corpid
为工作台应用的appKey
, dingtalk_corpsecret
为工作台应用的appSecret
。由于社区维护的并不支持dingtalk扩展的SECRET ENV,所以将密钥配置到了
configmap
中。用于生产环境的话,建议按使用secret
保存应用secret。
oauth2-proxy: config: clientID: aaa clientSecret: bbb cookieSecret: ccc configFile: |+ email_domains = [ "*" ] cookie_domain = "kane.mx" cookie_secure = false dingtalk_corpid = "" dingtalk_corpsecret = " "
如果仅希望企业部分部门的员工可以获得授权,在上面configFile
配置下添加如下配置,
dingtalk_departments = ["xx公司/产品技术中心","xx公司/部门2/子部门3"]
helm dep up
helm upgrade --install -f values.yaml --set oauth2-proxy.config.clientID= <移动应用appid> ,oauth2-proxy.config.clientSecret= <移动应用appsecret> site-with-auth --wait ./ 移动应用appsecret> 移动应用appid>
如果集群中已经部署了Nginx Ingress Controller
,修改values.yaml
如下将忽略部署Nginx ingress,
affinity: {}nginx-ingress: enabled: false controller: ingressClass: nginx config:
ELB
地址。kubectl get svc -o jsonpath='{ $.status.loadBalancer.ingress[*].hostname }'-nginx-ingress-controller;echoa3afe672259c511e98e2a0a0d88fda3e-xx.elb.ap-southeast-1.amazonaws.com
将站点和oauth服务域名解析到上面部署创建的ELB上。
访问Web站点(如本示例中的http://web.kane.mx
),未授权的情况下,调转到钉钉应用扫码登录界面。使用组织内成员的钉钉扫码授权后,将跳转回Web站点应用,可以正常浏览该域名下的页面。
转载地址:http://dytla.baihongyu.com/