kOps 中的 Service Account Token Volume ProjectionIssuer 发现与 IRSA 配置指南【免费下载链接】kopsKubernetes Operations (kOps) - Production Grade k8s Installation, Upgrades and Management项目地址: https://gitcode.com/gh_mirrors/kop/kops导读本文聚焦 kOps 对 Kubernetes Service Account Token Volume Projection服务账号令牌卷投影Kubernetes 1.12 引入的支持方式重点讲解 kOps 如何自动配置 API Server 的 ServiceAccount Issuer、如何将 OIDC Issuer Discovery 元数据公开发布到对象存储以及如何通过serviceAccountIssuerDiscovery配置打通 AWS IAM Roles for Service AccountsIRSA。读完本文你将掌握在 kOps 集群上为 Istio、Envoy SDS 等依赖投影令牌的服务启用令牌卷投影、并安全落地 IRSA 的完整配置与底层原理。背景为什么需要 Service Account Token Volume ProjectionKubernetes 从 1.12 起引入了 Service Account Token Volume Projection 特性允许通过projected卷以可控方式向 Pod 注入服务账号令牌。与旧版 Secret 令牌相比投影令牌具备可绑定受众audience、可配置过期时间expirationSeconds以及通过 TokenRequest API 签发等能力因而更适合微服务身份交换场景。一些服务如 Istio 和 Envoy 的 Secret Discovery Service即 SDS正是利用了这一特性将服务账号令牌以投影卷方式挂载再通过 OIDCOpenID Connect发现机制完成身份互认。要让这类场景正常工作集群必须满足两个前提API Server 的--service-account-issuer参数被正确配置使令牌的ississuer声明指向一个确定的 URL该 issuer 的 OIDC Discovery 文档含jwks_uri指向的公钥集合可以被依赖方访问以便校验令牌签名。kOps 中的默认行为从 1.20 起开箱即用kOps 文档明确说明自 kOps 1.20 起集群 API Server 会自动配置好 ServiceAccount issuer用户无需再做任何自定义配置默认情况下API Server 本身就承担 issuer discovery 的角色即 discovery 元数据由 API Server 的/.well-known/openid-configuration端点提供。这意味着对于仅需在集群内部完成令牌校验的场景例如 Istio/Envoy 从 API Server 拉取签名公钥升级到 kOps 1.20 之后即可直接使用投影令牌无需手工设置--service-account-issuer、--service-account-key-file等参数。从 1.21 起公开发布 Issuer Discovery 元数据自 kOps 1.21 起还可以公开发布 issuer discovery 元数据让集群外部的依赖方也能校验服务账号令牌。这一能力通过 Cluster 规格中的serviceAccountIssuerDiscovery字段开启同时也是 kOps 支撑 AWS IRSAIAM Roles for Service Accounts的关键机制。相关配置的完整说明见 cluster_spec.md 中的 Service Account Issuer Discovery 章节。在集群规格Cluster Spec中添加如下配置spec: serviceAccountIssuerDiscovery: discoveryStore: s3://publicly-readable-store enableAWSOIDCProvider: true各字段含义如下对应源码定义位于 pkg/apis/kops/cluster.go 的ServiceAccountIssuerDiscoveryConfig结构体字段类型说明discoveryStorestringOIDC Issuer Discovery 元数据openid-configuration文档与 JWKS 公钥集的 VFS 存储路径通常是对象存储 bucket如 S3、GCS一般应使用与 state store 不同的 bucketdiscoveryServiceobject使用托管 discovery 服务发布元数据其中url为服务基础地址含 universe ID如适用为后续可配置证书等预留了空间enableAWSOIDCProviderbool是否在 AWS 上创建信任该 ServiceAccount Issuer 的 OIDC Provider用于 IRSAadditionalAudiences[]string向已创建的 AWS OIDC Provider 追加的用户自定义 audiencediscoveryStore 的作用机制设置discoveryStore后kOps 会将 OIDC 兼容的 discovery 文档发布到该对象存储路径中并自动设置spec.kubeAPIServer.serviceAccountIssuer同时把spec.kubeAPIServer.serviceAccountJWKSURI默认指向对应的 HTTPS URL。也就是说用户无需手工推算jwks_urikOps 会依据存储路径自动生成公网可访问的地址。从源码实现看该逻辑位于 pkg/model/issuerdiscovery.go 的IssuerDiscoveryModelBuilder构建阶段会先从任务集合中取出名为Keypair/service-account的签名密钥任务见 pkg/model/issuerdiscovery.go这是签发服务账号令牌的根密钥然后生成标准 OIDC discovery JSON见 pkg/model/issuerdiscovery.go 的oidcDiscovery结构体包含issuer、jwks_uri、authorization_endpoint、response_types_supported、subject_types_supported、id_token_signing_alg_values_supported、claims_supported等字段通过 VFSutil/pkg/vfs将文档写入discoveryStore指定的路径见 pkg/model/issuerdiscovery.go对 S3 / GCS 存储会判断 bucket 的公开性如果 bucket 本身非公开则对文档对象设置公开读 ACLpublic-read / public-read确保jwks_uri可被外部访问见 pkg/model/issuerdiscovery.go。公开可读性是硬前提如果打算配合enableAWSOIDCProvider使用 IRSAservice account issuer 的 discovery URL 必须对公网公开可读——因为 AWS IAM 需要到该 URL 拉取 OIDC 发现文档与 JWKS 公钥来校验令牌签名。因此若使用 S3建议为该 bucket 开启静态网站托管或确保对象 ACL 为公开读若使用 GCS同样需要公开读权限文档的存储路径应独立于 state storestate store 中可能包含敏感信息不应公开。深入kOps 如何构建 AWS OIDC ProviderIRSA 集成当设置enableAWSOIDCProvider: true时kOps 会在 AWS 上创建一个信任当前 ServiceAccount Issuer 的 OIDC Identity Provider使集群内服务账号可以扮演 IAM 角色即 IRSA。相关实现位于 pkg/model/awsmodel/oidc_provider.go它会依据 discovery URL 在 IAM 中注册 Provider并建立面向sts.amazonaws.com的信任关系。kOps 文档同时给出了如下建议discoveryStore应使用公开可读的 bucket这是enableAWSOIDCProvider生效的前提相关功能自 kOps 1.21 起默认可用具体版本演进记录可参考 1.21-NOTES.md 与 1.22-NOTES.md。为集群 addons 提供专用 IAM 角色大部分需要访问 AWS API 的 kOps addon 可以使用专用 IAM 角色。开启方式spec: iam: useServiceAccountExternalPermissions: true为用户管理的 ServiceAccount 提供 AWS 权限kOps 还可以为任意用户创建的 ServiceAccount 预置 AWS 权限示例配置如下完整说明见 cluster_spec.mdspec: iam: serviceAccountExternalPermissions: - name: someServiceAccount namespace: someNamespace aws: policyARNs: - arn:aws:iam::000000000000:policy/somePolicy - name: anotherServiceAccount namespace: anotherNamespace aws: inlinePolicy: |- [ { Effect: Allow, Action: s3:ListAllMyBuckets, Resource: * } ]要让 Pod 自动继承assume这些 IAM 角色需要启用 Pod Identity Webhook否则需要自行修改 Pod 规格来完成角色绑定。注意事项在现有集群上启用可能具有破坏性kOps 文档对此给出了明确的警告在现有集群上启用上述配置可能造成中断——原因在于控制面会用不同的 issuer 签发令牌。典型症状是Pod 无法通过 Kubernetes API 的认证。若遇到该问题恢复步骤如下删除集群中已存在的 Service Account token Secret杀掉所有无法认证的 Pod让它们基于新配置重新获取令牌。此外如果希望无中断地在现有集群上启用 IRSA可以参照 kOps 提供的迁移流程见 service_account_issuer_migration.md该文档描述了如何在不停机的情况下将集群平滑迁移到新的 issuer 配置。验证与最佳实践小结完成配置后可以从以下几方面验证检查 API Server 参数kubeAPIServer.serviceAccountIssuer与serviceAccountJWKSURI是否已按预期设置访问discoveryStore对应的 HTTPS URL确认/.well-known/openid-configuration或等价的 OIDC 文档路径返回了正确的issuer与jwks_uri在 AWS IAM 控制台确认 OIDC Provider 已注册且信任策略正确部署一个使用投影令牌projected卷、serviceAccountToken条目的测试 Pod验证令牌签名可通过公开的 JWKS 校验。实践建议汇总场景推荐做法集群内部使用Istio/Envoy SDS升级到 kOps 1.20使用默认配置无需额外设置需要集群外部校验令牌配置serviceAccountIssuerDiscovery.discoveryStore指向公开 bucket启用 AWS IRSA同时设置discoveryStore与enableAWSOIDCProvider: true并保证 discovery URL 公开可读已有集群迁移严格参照 service_account_issuer_migration.md 执行避免令牌失效中断addon / 自定义 SA 使用 AWS 权限开启iam.useServiceAccountExternalPermissions并结合 Pod Identity Webhook底层实现方面读者可进一步阅读 pkg/model/issuerdiscovery.goOIDC discovery 文档生成与发布、pkg/model/awsmodel/oidc_provider.goAWS OIDC Provider 编排以及 pkg/apis/kops/cluster.goServiceAccountIssuerDiscoveryConfig字段定义以完整理解从集群规格到云端资源落地的整条链路。【免费下载链接】kopsKubernetes Operations (kOps) - Production Grade k8s Installation, Upgrades and Management项目地址: https://gitcode.com/gh_mirrors/kop/kops创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
