背景
SolarWinds Orion 软件更新包在2020年底被黑客植入后门，此次攻击事件波及范围极大，包括美国政府部门、关键基础设施以及多家全球500强企业，影响难以估计。如果用户能确认软件来源是可信的 SolarWinds 官方，这次事件可能可以避免。
为了确认软件的来源和构建方式，实现完整性保护，Linux基金会联合Red Hat、Google 和 Purdue 在 2021年3月推出了 Sigstore 代码签名项目，该项目致力于让开发人员签署发布时无感和让用户轻松验证。
Sigstore 在发布后快速发展，多个社区将 Sigstore 加入集成计划。2021年11月，Sigstore 加入了 OpenSSF（开源安全基金会），并且也受到了 Github 的青睐，12月份 Github Actions 集成了 Sigstore 对容器镜像的签名能力。2022年初，Shopify 发布了使用 Sigstore 改进 RubyGems 签名的 RFC。5月份，Kubernetes 在 1.24 版本中使用 Sigstore 无缝验证签名。
什么是Sigstore
Sigstore 是一款制品签名、验证的自动化工具，其优势在于对组件的自动化签名和验证实现，公开可审计日志服务的构建，和开源生态的支持。
Sigstore 由 Fulcio，Rekor 和 Cosign 三个主要组件组成。
Fulcio，证书颁发机构，根据 OIDC 身份颁发证书，且只能签署少于 20 分钟的短期证书。OIDC 是基于 OAuth 2.0 的认证+授权协议，用于用户身份认证，安全的暴露用户数据给第三方，可使用 Github、Google 等账号为 Fulcio 提供认证。
Rekor，完全公开日志，使用 Trillian （提供仅增加日志模式的功能，是 Certificate Transparency 思想的概括和扩展）作为防篡改的日志服务，记录验证签名有效性的证据，提供基于 RESTful API的用于存储和验证签名的服务。
Cosign，签名客户端，为容器镜像或制品（artifact，如可执行文件）提供签名、验证和存储支持。签名会写入到如下支持的 OCI 注册表（Oracle云基础设施容器注册表，是一种由 Oracle 管理的 Docker 注册表服务，可以安全的存储和共享容器映像。可用 Docker 命令和 API 轻松推送和拉取 Docker 映像。），并且容器镜像和制品也可以存储在注册表中。
- AWS Elastic Container Registry
- GCP's Artifact Registry and Container Registry
- Docker Hub
- Azure Container Registry
- JFrog Artifactory Container Registry
- The CNCF distribution/distribution Registry
- GitLab Container Registry
- GitHub Container Registry
- The CNCF Harbor Registry
- Digital Ocean Container Registry
- Sonatype Nexus Container Registry
- Alibaba Cloud Container Registry
Sigstore 中各组件的工作流程如下图：
- 开发人员通过 OIDC（Google、Github、Mircosoft 等账号）进行身份认证
- 认证通过后，Fulcio 给开发者颁发关联邮箱身份的短期证书，也同步给 Rekor
- 开发人员使用对应的短期密钥对制品进行签名，并发布制品，会将签名和验证证据同步给 Rekor
- 使用者在使用制品前可以通过 Cosign 使用 Rekor 数据验证签名的有效性
- 监督者通过 Rekor 的日志对证书的颁发记录进行审计
Sigstore为什么能保障安全
Sigstore 可以有效保证从获取 OIDC 身份到用户使用过程的安全性。
从签名的有效性来说，Fulcio 基于 OIDC 身份生成短期证书，Cosign 生成临时密钥为容器镜像或制品签名，证书和密钥的有效期都较短，极大减少了泄露的风险。
从签名的真实性来说，Cosign 会将生成的签名和相关的验证证据存入防篡改且公开的 Rekor，并且通过 Rekor 中的数据对签名进行验证，保证签名是真实的可靠的。
与常规的哈希值校验相比，Sigstore 的优势在于签名记录不可改变，完全公开防篡改的日志保证了验证成功的制品就是签名的开发者发布的制品。
相比同类的完整性保护方案，sigstore解决的问题场景更通用、实现方案更完备，一些类似的解决方案包括：
- Tekton Chains，一款收集 CI/CD 行为信息用于安全审计的供应链安全工具。但它只有做审计的用途，并没有签名验证的能力。
- Open Science Chain 利用联盟区块链安全地存储包含来源的不可变数据，实现对其真实性的独立验证。不足也是提供了审计的数据，还需要再开发验证数据的工具。
- in-toto 提供了一个包含软件供应链顺序和每个步骤的授权人员在内的框架来保护软件供应链的完整性。它需要项目所有者创建一个包含步骤和授权人员在内的框架，前期过程复杂，sigstore是基于in-toto的扩展。
如何使用sigstore
Github Actions
在 GitHub Actions工作流程中，增加对容器镜像签名的流程就能实现签署容器镜像并将其存储在 GitHub Packages。
jobs:
build:
steps:
# ... build steps here
- uses: sigstore/cosign-installer@main
- name: Write signing key to disk (only needed for `cosign sign --key`)
run: echo "${{ secrets.SIGNING_SECRET }}" > cosign.key
- name: Sign container image
run: |
cosign sign --key cosign.key \
ghcr.io/your-org/your-repo:some-tag
env:
COSIGN_PASSWORD: ""
用户可以在部署前拉取镜像时验证其签名。
cosign verify --key cosign.pub ghcr.io/your-org/your-repo:some-tag
Kubernetes
Kubernetes 在 1.24 版本中采用了 Sigstore 对容器镜像或制品进行签名和验签。
使用如下命令会在 kubernetes secret 中存储私钥、公钥和解密私钥的密码，当使用 cosign verify 验证镜像签名，会使用储存在 kubernetes secret 中的密码自动解密私钥。
cosign generate-key-pair k8s://[NAMESPACE]/[NAME]
独立使用
Rekor 组件提供了自定义部署的方式，Cosign 只是一个签名、验签工具，企业用户可以自行搭建一套用来管理公司内部的代码，并且还可以通过公共的 Rekor 为内部员工使用的开源组件做引入前的验证，减少开源软件造成的漏洞引入。
开发者们可以使用 Cosign 工具来对自己的制品进行签名，减少自己的开源产品被攻击者利用的风险。
# 生成密钥对
cosign generate-key-pair
# 签署容器镜像并将签名存储在注册表
cosign sign --key cosign.key dlorenc/demo
# 查找容器镜像的签名，并使用公钥验证
cosign verify --key cosign.pub dlorenc/demo
# 签署制品（artifact）
# 默认情况下，签名作为base64编码字符串输出
cosign sign-blob --key cosign.key artifact
# 输出：MEQCIAU4wPBpl/U5Vtdx/eJFgR0nICiiNCgyWPWarupH0onwAiAv5ycIKgztxHNVG7bzUjqHuvK2gsc4MWxwDgtDh0JINw==
# 验证制品
cosign verify-blob --key cosign.pub --signature MEQCIAU4wPBpl/U5Vtdx/eJFgR0nICiiNCgyWPWarupH0onwAiAv5ycIKgztxHNVG7bzUjqHuvK2gsc4MWxwDgtDh0JINw== artifact
展望
Sigstore 实现了自动化对组件进行数字签名和验证的能力，同时也解决了从获取身份到用户使用过程中的信任难题，能够很大程度上降低开发者使用成本。
可以预见未来会有更多的开源软件生态集成sigstore，Chainguard等公司也在做基于sigstore的商业解决方案，软件供应链的完整性保护将变得更加普遍。
但是，安全没有银弹。获取的 OIDC 身份不能完全信任、Sigstore 本身的安全问题、Fulcio 的根密钥安全性仍然是潜在的风险点。
参考链接
