云原生环境中的 MFA：Kubernetes 和 Docker 的二次验证实践

云原生环境下Kubernetes 集群和 Docker 环境的身份管理跟传统服务器差别很大。K8s 里有 ServiceAccount、RBAC、kubeconfigDocker 里有 Registry 认证、Daemon 权限。这些地方的传统身份管理已经很成熟但 MFA 的覆盖相对滞后。Kubernetes 的 MFA 切入方式K8s 本身不内置 MFA。它是一个 API 驱动的系统认证靠 kubeconfig 里的证书或 Token。但有几个间接的方式可以加 MFA通过 OIDC 接入 IdP。在 K8s 集群中配置 OpenID Connect把认证委托给支持 MFA 的 IdPKeycloak、Okta、Azure AD、Dex。开发者登录时先在 IdP 完成 MFA 验证拿到短效 Token 后再访问 K8s API。通过堡垒机前置。把集群的 kube-apiserver 放在 JumpServer 之类的堡垒机后面。开发者先通过堡垒机的 MFA 验证TOTP再由堡垒机转发请求到 K8s 集群。这是目前国内最务实的做法。kubectl 插件拦截。部分自研方案在 kubectl 命令执行前弹出 MFA 验证。比如定义一个 kubectl 插件在执行敏感操作delete、scale、apply时要求额外输入 TOTP 验证码。这种方法灵活但不通用。Docker 和容器镜像的 2FADocker 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个人账号走 OIDCMFA。不要混用。kubeconfig 文件不要外传。kubeconfig 里嵌着证书和密钥。把它看成跟 SSH 私钥一样敏感的东西。存密码管理器或加密存储不要放 GitHub 上。用支持云备份的 TOTP 验证器。微信小程序「二次验证码Free2FA」可以作为堡垒机、OIDC IdP、Docker Hub 等入口的统一 MFA 管理方案——标准 TOTP 协议换手机一键全恢复。