北京
CI/CD环境里的静态凭据，一直是安全风险的高发区。日志里可能泄露，构建产物里可能残留，更别提在配置过程中，你永远不知道谁复制过、保存过、分享过这些密钥。为了满足安全要求，还得定期轮换，运维成本居高不下。
正因如此，包括主流云厂商在内的许多服务，现在都支持用短时有效的OIDC身份令牌来做认证。这样一来，CI/CD流水线就能在不存储静态凭据的情况下完成身份验证。本文要聊的，就是OIDC认证的工作原理，以及TeamCity新推出的OIDC JWT插件，如何让你的构建配置安全地认证到AWS、Google Cloud等支持OIDC的服务。
OIDC到底是什么？
OpenID Connect（OIDC）最初是用于验证用户身份的标准。不过，AWS、Google Cloud等不少云厂商和服务，都借用了OIDC规范中的一部分来认证工作负载。本文只聚焦这部分内容。
认证流程的起点，是身份提供商（IdP）签发一个经过加密签名的JSON Web Token（JWT），里面包含工作负载的相关信息。令牌里的每条信息都叫一个claim（声明）。每个令牌都包含有效期、预期受众（即令牌签发给哪些服务）以及签发者URL。签发的令牌可以提交给第三方服务（比如云厂商），也就是所谓的令牌消费者。
令牌消费者收到令牌后，会通过签发者URL去获取元数据文档（{issuer_url}/.well-known/openid-configuration）。这份文档里，除了其他信息，还包含指向签发者JSON Web Key Set（JWKS）的链接，里面存着用于验证令牌签名的公钥。OIDC签发者URL必须使用https协议，所以元数据文档只能通过HTTPS提供服务。部分消费者也支持用预配置的密钥集做验证，这种情况下，签发者就不需要把元数据文档暴露在公网上了。
验证流程：签名、受众、有效期
拿到公钥后，消费者会用它们来验证令牌签名。签名有效的话，消费者会继续检查令牌是否签发给预期的受众，以及是否在有效期内（未过期）。验证通过的令牌claims，会被消费者用来认证工作负载。
有些消费者直接接受IdP签发的令牌。另一些则会做一次令牌交换，返回服务特定的临时凭据给工作负载使用。要让TeamCity构建用上这种认证方式，服务器需要扮演身份提供商的角色，为构建签发令牌。
TeamCity OIDC JWT插件来了
新推出的OIDC JWT插件，为TeamCity服务器补上了签发令牌所需的IdP能力，让构建配置可以直接对接支持OIDC的第三方服务。这意味着，你的CI/CD流水线可以彻底告别静态凭据，改用短时令牌完成认证，既降低了泄露风险，也省去了定期轮换的运维负担。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
