云原生环境中的 MFA：Kubernetes 和 Docker 的二次验证实践
云原生环境下，Kubernetes 集群和 Docker 环境的身份管理跟传统服务器差别很大。K8s 里有 ServiceAccount、RBAC、kubeconfig；Docker 里有 Registry 认证、Daemon 权限。这些地方的传统身份管理已经很成熟，但 MFA 的覆盖相对滞后。
Kubernetes 的 MFA 切入方式
K8s 本身不内置 MFA。它是一个 API 驱动的系统，认证靠 kubeconfig 里的证书或 Token。但有几个间接的方式可以加 MFA：
通过 OIDC 接入 IdP。在 K8s 集群中配置 OpenID Connect，把认证委托给支持 MFA 的 IdP（Keycloak、Okta、Azure AD、Dex）。开发者登录时先在 IdP 完成 MFA 验证，拿到短效 Token 后再访问 K8s API。
通过堡垒机前置。把集群的 kube-apiserver 放在 JumpServer 之类的堡垒机后面。开发者先通过堡垒机的 MFA 验证（TOTP），再由堡垒机转发请求到 K8s 集群。这是目前国内最务实的做法。
kubectl 插件拦截。部分自研方案在 kubectl 命令执行前弹出 MFA 验证。比如定义一个 kubectl 插件，在执行敏感操作（delete、scale、apply）时要求额外输入 TOTP 验证码。这种方法灵活但不通用。
Docker 和容器镜像的 2FA
Docker Hub。Docker Hub 支持标准 TOTP 2FA。Settings → Security → Enable 2FA。如果你的 Docker Hub 账号用于推送生产镜像，必须开 2FA——攻击者推送恶意镜像到你的仓库，下游所有拉取这个镜像的部署都会受影响。
Harbor 和私有 Registry。Harbor 支持通过 LDAP/OIDC 接入已有 IdP，利用 IdP 的 MFA 机制做多因素认证。如果你的团队自建 Harbor 做镜像管理，建议配置 OIDC + MFA，而不是用本地密码认证。
实践建议
ServiceAccount 和人类账号分开。CI/CD 里用的是 ServiceAccount，人登录用的是个人账号。ServiceAccount 走最小权限而不做 MFA；个人账号走 OIDC+MFA。不要混用。
kubeconfig 文件不要外传。kubeconfig 里嵌着证书和密钥。把它看成跟 SSH 私钥一样敏感的东西。存密码管理器或加密存储，不要放 GitHub 上。
用支持云备份的 TOTP 验证器。微信小程序「二次验证码Free2FA」可以作为堡垒机、OIDC IdP、Docker Hub 等入口的统一 MFA 管理方案——标准 TOTP 协议，换手机一键全恢复。