yldmdocs

Dex · 集群统一 OIDC 身份认证入口

Dex 是部署在 dex 命名空间的 OpenID Connect (OIDC) 身份提供商。它把外部的 Google OAuth 当作上游 connector,自己对外签发标准 OIDC 令牌,让集群里各个组件不必各自对接 Google,只需信任 https://dex.yldm.tech 这一个 issuer 即可完成 SSO。

它同时是 Kubernetes API 的 OIDC 认证入口:用户经 Google 登录拿到令牌后,身份(邮箱)由 Kubernetes RBAC 决定权限(ClusterRoleBinding / RoleBinding 按邮箱授权,见仓库内 rbac/users/)。Dex 把自身状态(授权码、刷新令牌等)持久化在 Kubernetes 自定义资源里(storage.type: kubernetes),不依赖外部数据库。

部署形态

  • Name
    命名空间
    Description
    dex
  • Name
    工作负载
    Description
    Deployment(单容器 dex + 一个 initContainer config-init)
  • Name
    镜像
    Description
    ghcr.io/dexidp/dex:v2.45.1(initContainer 用 busybox:1.38 渲染配置)
  • Name
    副本数
    Description
    replicas: 1(由 HPA 在 1~3 之间伸缩)
  • Name
    调度
    Description
    nodeSelector workload: infra
  • Name
    端口
    Description
    容器 5556(name: http)
  • Name
    存储
    Description
    无 PVC;状态存于 Kubernetes CR(storage.type: kubernetes, inCluster),配置通过 emptyDir 在 initContainer 与主容器间传递
  • Name
    资源
    Description
    requests 100m / 128Mi,limits 200m / 256Mi

配置不是直接挂 ConfigMap 启动,而是经过一次模板渲染:config-init initContainer 把 dex-config ConfigMap 里的 config.yaml 模板拷到 emptyDir,用 sed 把 __XXX_SECRET__ 占位符替换成从 Secret 注入的环境变量(Google client id/secret、各 OAuth2 client 的 secret),主容器再以 dex serve /etc/dex/cfg/config.yaml 启动。这样敏感值不会出现在 ConfigMap 里。

Dex 自身需要一个 ClusterRole(rbac/clusterrole.yaml):对 dex.coreos.com 资源的全部权限,以及创建 customresourcedefinitions 的权限——这是 storage.type: kubernetes 用 CR 存状态所必需的。

配置与依赖

issuer 为 https://dex.yldm.tech,上游 connector 只有一个:Google(type: google,scopes 为 openid/profile/email,redirectURI https://dex.yldm.tech/callback)。oauth2.skipApprovalScreen: true,enablePasswordDB: false(不启用本地密码库,只走 Google)。

静态客户端(staticClients)即各个接 SSO 的下游组件,redirectURI 指向各自的回调地址:

client id名称回调地址类型
kubernetesKuberneteslocalhost:8000/18000 等本地回环public
argocdArgoCDhttps://argocd.yldm.tech/auth/callbackconfidential
argocd-cliArgoCD CLI同 argocd(本地回环)public
grafanaGrafanahttps://grafana.yldm.tech/login/generic_oauthconfidential
prometheus-oauth2-proxyPrometheushttps://prometheus.yldm.tech/oauth2/callbackconfidential
vaultVaulthttps://vault.yldm.tech/ui/vault/auth/oidc/oidc/callbackconfidential
minioMinIOhttps://minio.yldm.tech/oauth_callbackconfidential
argo-workflowsArgo Workflowshttps://argo-workflows.yldm.tech/oauth2/callbackconfidential

敏感值由两个 ExternalSecret 从 Vault(ClusterSecretStore vault-backend,刷新间隔 1h)拉取:

  • Name
    dex-google-oauth → Secret dex-google-client
    Description
    remoteRef.key dex/google-oauth,取 property clientID / clientSecret(对应 env DEX_GOOGLE_CLIENT_ID / DEX_GOOGLE_CLIENT_SECRET)
  • Name
    dex-oauth2-clients → Secret dex-oauth2-clients
    Description
    remoteRef.key dex/clients/<client>(kubernetes / argocd / grafana / prometheus / vault / minio / glitchtip / argo-workflows),各取 property secret

依赖项:上游身份源是 Google OAuth;敏感配置依赖 Vault + External Secrets Operator;状态存储依赖 Kubernetes API(CR)。各下游 SSO 组件反过来依赖 Dex 这个 issuer 可达。

访问与监控

集群内通过 ClusterIP Service dex:5556 访问。对外经 Traefik Ingress(ingressClassName: traefik,host dex.yldm.tech)暴露,TLS 证书由 cert-manager letsencrypt-prod 签发(secret dex-tls),并经 Cloudflare Tunnel 入站(external-dns 注解 cfargotunnel.com target,cloudflare-proxied: "true")。

Ingress 只放行 OIDC 协议路径到 dex 服务:/.well-known、/auth、/token、/keys、/userinfo、/callback、/device;根路径 / 原本指向 dex-welcome 服务(装饰性欢迎页)。

欢迎页(dex-welcome)已于 2026-06-12 在 kustomization 中注释停用,manifests 保留在 welcome/ 目录,取消注释即可恢复。注意 kustomization 仍把 / 路由指向 dex-welcome 服务,而该服务当前未部署。

伸缩与防护:

  • Name
    HPA
    Description
    dex-hpa,Deployment dex,minReplicas 1 / maxReplicas 3,CPU 75% + Memory 80% 阈值
  • Name
    ServiceMonitor / PrometheusRule
    Description
    manifest 目录中未发现,Dex 暂无专门的监控采集 / 告警规则
  • Name
    NetworkPolicy
    Description
    命名空间为 default-deny-ingress,另放行 same-namespace、来自 ingress、来自 argo-workflows、minio-ingress;egress 放行 DNS、外部(Google)、kube-api
  • Name
    ResourceQuota
    Description
    该命名空间设有 resourcequota

OIDC 发现端点:https://dex.yldm.tech/.well-known/openid-configuration;设备授权:https://dex.yldm.tech/device。

注意事项

Dex 是整个集群 SSO 的单点入口:它不可用时,ArgoCD、Grafana、Vault、MinIO、Argo Workflows 的登录以及 kubectl 的 OIDC 认证都会受影响。单副本部署,HPA 可临时扩到 3 副本,但状态存于 Kubernetes CR,扩副本本身是无状态友好的。

用户授权不在 Dex 配置里,而在 Kubernetes RBAC:任何 Gmail 用户都能通过 Google 完成 OIDC 认证,但能做什么由按邮箱命名的 ClusterRoleBinding / RoleBinding 决定。新增/移除用户走 rbac/users/<邮箱>.yaml(当前 suzukaze.haduki@gmail.com 为 cluster-admin,evan@yldm.tech 为 production namespace admin)。

仓库里有两份 Dex 清单需注意:kustomization.yaml 实际引用的是 base/ 下的 deployment.yaml / configmap.yaml(其 staticClients 含 argo-workflows);目录顶层的 deployments-dex.yaml / configmaps-dex-config.yaml 未被 kustomization 引用(后者的 staticClients 里是 glitchtip 而非 argo-workflows)。以 base/ 为准。

返回 infrastructure 总览

评论