域名未做运行网站解析,网页素材图,建设网站 翻译,怎么做网站前台第一部分#xff1a;开篇明义 —— 定义、价值与目标 定位与价值 在云原生时代#xff0c;容器镜像已成为软件分发与部署的核心载体。然而#xff0c;镜像仓库如同一个巨大的数字港口#xff0c;每天吞吐着数以百万计的镜像。攻击者可以通过入侵构建管道、投毒公共仓库、或…第一部分开篇明义 —— 定义、价值与目标定位与价值在云原生时代容器镜像已成为软件分发与部署的核心载体。然而镜像仓库如同一个巨大的数字港口每天吞吐着数以百万计的镜像。攻击者可以通过入侵构建管道、投毒公共仓库、或实施中间人攻击等方式将恶意代码注入镜像使其成为供应链攻击的跳板。容器镜像签名与验证就是为每一个出厂构建完成的镜像附加一个基于密码学的“数字封条”并在装载部署运行前进行校验。它回答了一个根本性问题“我所拉取的镜像是否确实来自我所信任的发布者且在传输过程中未被篡改”这项工作已从“最佳实践”演变为“生存必需”。无论是《关键信息基础设施安全保护条例》等法规的合规性要求还是应对SolarWinds等国家级供应链攻击的实战教训都指向了同一个结论没有完整签名与验证流程的软件供应链如同在数字战场上“裸奔”。本文将深入剖析从经典的Notary到现代的Sigstore方案并揭示其如何与SLSA框架集成共同构筑从代码到容器的可信防线。学习目标读完本文你将能够阐述容器镜像签名与验证的核心价值并辨析Notary与Sigstore项目的设计哲学与优劣。独立完成使用Sigstore的Cosign工具对容器镜像进行签名、验证并将验证策略集成到Kubernetes准入控制。分析并规划一个将镜像签名、验证与SLSA构建等级要求相结合的软件供应链安全加固方案。前置知识· 容器基础了解Docker/OCI镜像的基本概念仓库、镜像、标签。· 公钥基础设施PKI基础了解非对称加密、数字签名、证书的基本原理。· Kubernetes基础了解Pod、Deployment及准入控制器的概念。第二部分原理深掘 —— 从“是什么”到“为什么”核心定义与类比· 容器镜像签名使用发布者的私钥对镜像的摘要Digest如SHA256哈希值进行加密计算生成一段唯一的签名数据。这个过程如同艺术品作者在完成作品后用自己独有的印章私钥在鉴定证书上盖章。· 容器镜像验证在拉取或运行镜像前使用发布者公开的公钥或证书对附带的签名数据进行解密和校验确认该签名确实由对应私钥生成且镜像摘要自签名后未被更改。这如同买家在收货时用已知的官方印章样本公钥来核对艺术品证书上的印章真伪并确保艺术品本身完好无损。· 软件物料清单SBOM一份嵌套的、正式且机器可读的清单包含软件组件及其依赖关系的详细信息。它是软件供应链的“成分表”。· SLSA框架一套由谷歌发起、行业共建的安全等级标准用于衡量和提升软件供应链的完整性。它定义了从SLSA 1到SLSA 4逐级递进的安全要求。根本原因分析从Notary到Sigstore的范式转移Notary (TUF) 的设计哲学Notary项目基于TUF, The Update Framework的核心思想是防御持续性攻击。它假设仓库密钥可能被长期入侵因此设计了一个分层密钥体系根密钥、目标密钥、快照密钥等通过定期的元数据轮换和阈值签名来限制单点密钥泄露的影响。其工作模式是“客户端驱动验证”客户端如Docker CLI信任一个根证书并从Notary服务器公证服务拉取经过签名的镜像元数据信任数据进行本地验证。挑战复杂性TUF模型非常严谨但复杂部署、维护和理解成本高。中心化仍需要一个受信的Notary服务来存储和分发签名元数据。密钥管理长寿命的发布者密钥管理仍然是用户的负担存在泄露风险。用户体验与新兴的供应链安全工具链如SLSA、SBOM集成路径不畅。Sigstore的设计哲学Sigstore的诞生是对上述挑战的直接回应。其核心理念是 “免费、自动、开放” 的签名服务。它通过三个核心组件彻底重新设计了签名范式Fulcio一个基于短期证书的根证书颁发机构CA。它使用OpenID Connect (OIDC)身份如GitHub, Google账号来颁发仅有效期10-20分钟的代码签名证书。私钥在签名后立即销毁从根本上消除了密钥管理的负担。Cosign用于实际执行签名和验证操作的客户端工具。它支持容器镜像、文件、SBOM等多种对象的签名并将签名存储在OCI仓库中作为“附件”避免了中心化的签名服务器。Rekor一个透明的、防篡改的日志服务。每次签名操作都会产生一个包含签名元数据、证书和签名的“记录”并提交到Rekor。这提供了不可抵赖性和公开可审计性。范式优势· 消除密钥管理开发者无需保管长期私钥。· 身份驱动签名直接绑定到可识别的开发者或自动化系统如CI/CD工作流身份。· 透明与审计所有签名记录公开可查便于事后审计和自动化策略检查。· 无缝集成天然适合集成到CI/CD流水线通过工作流身份获取短期证书和Kubernetes通过准入控制器验证。可视化核心机制Sigstore签名与验证流程下图展示了开发者通过GitHub Actions CI/CD工作流使用Sigstore对容器镜像进行签名以及Kubernetes集群在部署时进行验证的完整流程。policy-controllerKubernetes (w/ policy-controller)OCI 镜像仓库Rekor (透明日志)Fulcio (CA)CI/CD Pipeline (GitHub Actions)GitHub (OIDC Provider)开发者policy-controllerKubernetes (w/ policy-controller)OCI 镜像仓库Rekor (透明日志)Fulcio (CA)CI/CD Pipeline (GitHub Actions)GitHub (OIDC Provider)开发者b【签名阶段 - 在CI/CD中自动完成】/bb【验证阶段 - 在部署时强制执行】/balt[验证通过][验证失败]推送代码 / 创建PR/标签触发工作流运行请求OIDC令牌 (JWT)颁发身份令牌 (含仓库、提交等信息)申请代码签名证书 (附OIDC令牌)验证令牌有效性验证通过颁发短期X.509证书 (绑定身份)生成临时密钥对用私钥签名镜像提交签名记录 (含证书、签名)返回包含日志索引的收据推送镜像及签名 (作为OCI附件)(可选)推送SBOM及签名提交Deployment (引用已签名镜像)拦截创建Pod请求拉取镜像及签名附件查询签名记录 (根据摘要/日志索引)返回签名记录执行验证策略 (e.g.,签名者身份匹配?证书由Fulcio签发?记录存在于Rekor?)允许创建Pod部署成功拒绝创建Pod部署被拒绝 (错误信息)第三部分实战演练 —— 从“为什么”到“怎么做”环境与工具准备· 演示环境Ubuntu 22.04 LTS 或 macOS。确保具有sudo权限。· 核心工具· docker / podman容器运行时。· cosignv2.0。Sigstore的签名/验证命令行工具。· rekor-cli与Rekor服务交互的工具。· jq用于处理JSON输出。· helm / kubectl用于部署Kubernetes验证组件可选用于演示完整流程。· 最小化实验环境我们将使用Sigstore的公共服务fulcio.sigstore.dev, rekor.sigstore.dev进行演示这是生产环境的推荐方式。对于私有环境可部署自托管服务。#!/bin/bash# 安装 Cosignwgethttps://github.com/sigstore/cosign/releases/latest/download/cosign-linux-amd64-O /usr/local/bin/cosignchmodx /usr/local/bin/cosign# 安装 rekor-cliwgethttps://github.com/sigstore/rekor/releases/latest/download/rekor-cli-linux-amd64-O /usr/local/bin/rekor-clichmodx /usr/local/bin/rekor-cli# 验证安装cosign version rekor-cli version标准操作流程发现/识别准备镜像与身份首先我们需要一个镜像和一个用于签名的身份。我们将使用一个测试镜像并模拟在CI环境中通过环境变量获取OIDC令牌本地演示可使用交互式登录。# 1.1 拉取或构建一个测试镜像dockerpull hello-world:latestdockertag hello-world:latest ghcr.io/YOUR_USERNAME/test-signed:latest# 注意请将 YOUR_USERNAME 替换为你的GitHub用户名或自有仓库地址。# 1.2 (方法A) 交互式登录适用于本地测试# Cosign 将通过浏览器引导你使用GitHub等OIDC提供商登录。cosign login ghcr.io# 1.2 (方法B) 在CI环境中使用模拟# 假设环境变量 SIGSTORE_ID_TOKEN 已由CI平台如GitHub Actions注入。# export SIGSTORE_ID_TOKEN$(curl -s -H Authorization: bearer $ACTIONS_ID_TOKEN_REQUEST_TOKEN $ACTIONS_ID_TOKEN_REQUEST_URLaudiencesigstore | jq -r .value)利用/分析使用Cosign签名使用cosign sign命令进行签名。该命令会自动与Fulcio和Rekor交互。# 2.1 基本签名命令# 此命令将# 1. 生成临时密钥对。# 2. 使用你的OIDC身份向Fulcio申请短期证书。# 3. 使用该证书的私钥对镜像摘要进行签名。# 4. 将签名作为OCI附件推送到同一镜像仓库。# 5. 将签名记录提交到Rekor透明日志。cosign sign --yes ghcr.io/YOUR_USERNAME/test-signed:latest# 输出示例# Using payload from: /tmp/cosign-payload123456# tlog entry created with index: 12345678# Pushing signature to: ghcr.io/YOUR_USERNAME/test-signed:sha256-abcdef...sig# 2.2 同时生成并签名SBOM软件物料清单# 首先使用syft生成SBOMdockerrun -v /tmp:/tmp anchore/syft:latest ghcr.io/YOUR_USERNAME/test-signed:latest -o spdx-json/tmp/sbom.json# 然后签名SBOM并将其关联到镜像cosign sign --yes --attachment sbom /tmp/sbom.json ghcr.io/YOUR_USERNAME/test-signed:latest验证/深入验证签名与策略检查签名后任何人均可使用cosign verify进行验证。# 3.1 基本验证 - 验证镜像是否由可信的Fulcio证书签名# --certificate-identity 和 --certificate-oidc-issuer 用于指定我们信任的签名者身份。# 以下示例信任来自特定GitHub仓库的CI工作流。cosign verify ghcr.io/YOUR_USERNAME/test-signed:latest\--certificate-identity-regexp^https://github\.com/YOUR_ORG/YOUR_REPO/.*\--certificate-oidc-issuer https://token.actions.githubusercontent.com# 成功输出将显示验证通过的证书信息、签名者和Rekor日志条目。# 3.2 查询Rekor透明日志# 使用上一步输出中的 tlog index 或镜像摘要进行查询rekor-cli get --log-index12345678--format json|jq.# 或通过镜像摘要查询DIGEST$(dockerinspect --format{{index .RepoDigests 0}}ghcr.io/YOUR_USERNAME/test-signed:latest|cut-d-f2)rekor-cli search --sha$DIGEST自动化与脚本Kubernetes准入控制集成静态验证有用但真正的威力在于将验证策略强制执行于部署时。我们使用sigstore/policy-controller原cosigned在Kubernetes中实现这一点。警告以下脚本仅用于授权测试环境。# policy-controller-install.yaml# 使用 Helm 安装 policy-controllerhelm repo add sigstore https://sigstore.github.io/helm-charts helm repo update helm install policy-controller sigstore/policy-controller \--namespace cosign-system \--create-namespace \--set webhook.image.pullPolicyIfNotPresent \--set config.cosign.secretRefscustom-secret# 可选用于私有仓库认证# clusterimagepolicy.yaml# 定义一个集群范围的镜像验证策略 (ClusterImagePolicy)apiVersion:policy.sigstore.dev/v1beta1kind:ClusterImagePolicymetadata:name:require-gh-actions-signedspec:images:-glob:ghcr.io/YOUR_ORG/**# 匹配你组织下的所有镜像authorities:-keyless:# 信任由 GitHub Actions OIDC 颁发者认证的身份url:https://fulcio.sigstore.devidentities:# 仅信任来自特定GitHub仓库的签名-issuer:https://token.actions.githubusercontent.comsubjectRegExp:^https://github\.com/YOUR_ORG/YOUR_REPO/.*\.git$refs/heads/main$# subject 格式通常为仓库URLgit ref可根据需要调整正则ctlog:# 信任 Sigstore 的公共证书透明日志url:https://rekor.sigstore.devattestations:# (可选) 要求存在特定类型的 attestation如SBOM-name:sbompredicateType:https://spdx.dev/Document应用此策略后任何试图部署不符合策略例如未签名或签名者身份不匹配的镜像的Pod都将被准入控制器拒绝。对抗性思考绕过与进化· 窃取OIDC令牌攻击者若能在CI环境中窃取到有效的OIDC令牌即可在令牌有效期内通常很短签发恶意镜像。防御关键在于强化CI环境安全如最小权限、隔离以及使用精细化的身份策略例如在ClusterImagePolicy中严格限定subject为特定的Git Ref如refs/tags/v*仅允许签名的发布标签。· 滥用Rekor过期策略Rekor有日志条目修剪策略。攻击者可能希望其恶意签名记录尽快被遗忘。防御方案是在验证策略中强制执行签名记录的“存在性”和“新鲜度”policy-controller支持检查Rekor条目并考虑私有的、长期保留的Rekor实例用于关键资产审计。· 镜像标签重用Tag Mutability容器仓库通常允许覆盖同一标签。攻击者可能用恶意镜像覆盖已签名的latest标签。签名与不可变的镜像摘要Digest 绑定而非标签。最佳实践是始终通过摘要而非标签来引用生产镜像。在Kubernetes中可以使用镜像摘要或配合不可变标签的策略。第四部分防御建设 —— 从“怎么做”到“怎么防”构建一个基于Sigstore和SLSA的软件供应链防御体系需要开发、安全和运维团队的协同。开发侧修复将安全内建于CI/CD流水线危险模式手动、非确定性的构建无签名。# 开发者本地构建并推送dockerbuild -t myapp:latest.dockerpush myapp:latest# 任何知道仓库地址的人都可以推送 myapp:latest。安全模式自动化、可重复的流水线集成签名与SBOM生成。# .github/workflows/build-and-sign.yml (示例)name:Build,Sign and Pushon:push:tags:[v*]# 仅在打版本标签时触发正式构建pull_request:{}# PR时触发构建测试jobs:build-and-sign:runs-on:ubuntu-latestpermissions:id-token:write# 关键请求OIDC令牌的权限contents:readpackages:writesteps:-uses:actions/checkoutv3-name:Set up Docker Buildxuses:docker/setup-buildx-actionv2-name:Log in to Container Registryuses:docker/login-actionv2with:registry:ghcr.iousername:${{github.actor}}password:${{secrets.GITHUB_TOKEN}}-name:Extract metadata for Dockerid:metauses:docker/metadata-actionv4with:images:ghcr.io/${{github.repository}}tags:|typesemver,pattern{{version}} typesha,prefix{{branch}}-,formatshort-name:Build and push Docker imageuses:docker/build-push-actionv4with:context:.push:truetags:${{steps.meta.outputs.tags}}labels:${{steps.meta.outputs.labels}}-name:Install Cosignuses:sigstore/cosign-installerv3-name:Sign the published Docker imagerun:|# 为每个构建的标签签名 IMAGE_REFghcr.io/${{ github.repository }} for TAG in ${{ steps.meta.outputs.tags }}; do cosign sign --yes ${IMAGE_REF}:${TAG} done运维侧加固部署时强制验证与监控部署策略即代码· 如上文实战部分所示使用ClusterImagePolicy定义所有工作负载的镜像签名要求。· 将策略文件纳入Git版本控制并通过GitOps工具如ArgoCD, Flux进行部署和管理。架构设计原则· 零信任镜像仓库将集群配置为仅允许从特定、已强制验证签名的仓库拉取镜像通过ImagePolicyWebhook与网络策略结合。· 分阶段验证在CI流水线末尾进行“软验证”确保产出的镜像已正确签名在CD部署时进行“硬验证”通过准入控制器强制拦截。与SLSA框架集成· SLSA 1级文档化你的CI/CD流水线脚本如上文的GitHub Actions文件本身就是构建过程文档化的开始。· SLSA 2级防篡改、生成出处Sigstore签名直接满足了“防篡改”要求。你需要额外生成出处证明Provenance描述镜像是如何构建的源代码、构建环境、参数等。cosign可以生成和签名符合SLSA Provenance格式的证明。# 在CI中使用cosign生成出处证明cosign attest --yes --predicate provenance.json --type slsaprovenance ghcr.io/YOUR_IMAGE:TAG· SLSA 3级额外安全控制要求构建服务隔离、参数化。你的托管CI服务如GitHub Actions或自建环境如Tekton in isolated cluster需要满足这些隔离要求。出处证明中将包含这些隔离环境的信息。· SLSA 4级最高级要求可重复的构建和两步验证。通过锁死所有依赖包括基础镜像、编译器版本实现可重复性并通过严格的ClusterImagePolicy要求特定签名者、出处实现两步验证。检测与响应线索· 日志关注点· policy-controller日志关注denied拒绝和error验证错误条目。频繁的拒绝可能意味着配置错误或攻击尝试。· Kubernetes审计日志关注对ClusterImagePolicy资源的变更操作update, delete这可能意味着策略被恶意修改。· 私有Rekor实例日志分析签名模式异常例如同一身份在极短时间内从不同IP签发大量镜像可能意味着凭证泄露。· 威胁狩猎起点· 查询集群中所有运行中的Pod找出任何不满足当前ClusterImagePolicy的镜像即“遗留”的未签名或旧策略签名的镜像这是供应链风险的潜在盲点。· 对比镜像的出处证明与CI/CD系统的实际日志检查是否存在构建参数不一致的情况例如源代码提交ID不符可能指向构建过程被劫持。第五部分总结与脉络 —— 连接与展望核心要点复盘信任基石的转移容器安全的核心从“保护仓库”转向“验证内容”。数字签名是不可或缺的验证手段它建立了从生产者到消费者的密码学信任链。Sigstore的范式革命通过短期证书Fulcio、透明日志Rekor和易用工具Cosign 的三位一体Sigstore几乎消除了采用镜像签名的关键障碍密钥管理、复杂性使其成为现代软件供应链安全的默认选择。验证的强制化签名本身不提供安全强制验证才提供。必须通过Kubernetes准入控制器如policy-controller 等机制在部署关口自动执行验证策略将安全要求转化为不可绕过的技术约束。与SLSA的协同进化Sigstore是达成SLSA等级特别是L2防篡改要求的关键工具和实践。它们共同定义和度量了从源代码到产成品的端到端供应链完整性。知识体系连接· 前序基础· 《容器安全基础命名空间、Cgroups与Capabilities》理解容器隔离的底层机制是思考运行时安全本文聚焦构建与分发安全的前提。· 《公钥基础设施PKI在DevSecOps中的应用》深入理解X.509证书、OIDC等概念是掌握Sigstore工作原理的基石。· 后继进阶· 《软件物料清单SBOM的生成、管理与漏洞关联》本文提到SBOM的签名SBOM的深入应用是供应链安全的下一环——成分分析与漏洞管理。· 《Kubernetes多租户安全与策略引擎OPA/Gatekeeper深度实践》policy-controller是特化的策略引擎。理解通用的策略引擎可以设计更复杂、统一的安全策略。进阶方向指引eBPF驱动的运行时签名验证不仅要在部署时验证镜像还要在容器运行时利用eBPF技术监控进程行为并与镜像签名或出处证明中的预期行为如允许的系统调用列表进行比对实现从“静态验证”到“动态验证”的延伸。基于身份的细粒度策略与机密管理将SPIFFE/SPIRE项目与Sigstore结合。为每个工作负载或服务颁发唯一身份SVID并在签名验证策略中不仅检查镜像是否由某个CI系统签名更进一步检查部署该镜像的服务是否拥有相应的身份权限实现更深层次的零信任架构。自检清单· 是否明确定义了本主题的价值与学习目标开篇即阐述其在供应链安全中的核心地位并列出三层学习目标· 原理部分是否包含一张自解释的Mermaid核心机制图包含Sigstore签名与验证全流程的序列图清晰展示各组件交互· 实战部分是否包含一个可运行的、注释详尽的代码片段包含从环境搭建、签名、验证到Kubernetes集成的完整命令行和YAML示例· 防御部分是否提供了至少一个具体的安全代码示例或配置方案提供了安全的CI/CD流水线模板和ClusterImagePolicy策略定义示例· 是否建立了与知识大纲中其他文章的联系明确了与前序容器基础、PKI以及后继SBOM、策略引擎文章的关联· 全文是否避免了未定义的术语和模糊表述所有关键术语如Sigstore、SLSA、SBOM、OIDC等首次出现时均加粗并附有解释