为何在OpenShift中创建ServiceAccount时会生成两个关联Secret？

双Secret的功能差异 #

你创建ServiceAccount后自动生成的两个Secret功能完全独立：

• API访问令牌类Secret（类型标识为kubernetes.io/service-account-token）：存储由OpenShift API Server签发的JWT认证令牌。当你将该ServiceAccount挂载到Pod时，这个令牌会被自动注入到容器的/var/run/secrets/kubernetes.io/serviceaccount/token路径下，容器内运行的进程可以通过该令牌访问OpenShift API，权限匹配你绑定的edit角色。
• 镜像拉取类Secret（类型标识为kubernetes.io/dockerconfigjson）：存储OpenShift内置容器镜像仓库的认证凭证。kubelet调度Pod启动时，会优先使用该凭证拉取当前项目、以及ServiceAccount有权限访问的其他项目下的私有镜像，无需额外手动配置镜像拉取密钥。

无法合并为单Secret的原因 #

两类凭证的设计逻辑、使用场景完全不同，拆分是为了满足隔离和可用性要求：

1. 生效周期完全分离：镜像拉取凭证在Pod启动前、kubelet拉取镜像阶段生效，此时容器尚未运行；API访问令牌是容器运行后、内部业务进程调用API时才会使用，两者生效阶段无重叠，合并没有意义。
2. 权限边界隔离需求：镜像拉取凭证仅具备镜像仓库的读权限，API令牌具备你配置的项目编辑权限，拆分可以避免权限过度集中，某一类凭证泄露后不会扩大风险影响面。
3. 独立管理更灵活：两类凭证的轮换、吊销逻辑互相独立，比如你需要定期轮换API访问令牌时，不会影响存量Pod的镜像拉取能力，反之修改镜像拉取凭证也不会影响正在运行的业务的API访问权限。

内容的提问来源于stack exchange，提问作者Yashar