Tekton Pipeline Workspace 信任边界隔离：跨信任域共享 PVC 的安全最佳实践

云原生CI/CDDevOps后端【免费下载链接】pipelineA cloud-native Pipeline resource.项目地址https://gitcode.com/gh_mirrors/pipelin/pipeline点击查看免费下载导读本文基于 Tekton Pipelines 官方安全文档深入讲解如何在多信任级别并存例如不可信 Pull Request 校验与可信发布构建的 CI/CD 场景下安全地设计TaskRun与PipelineRun的 Workspace 存储方案。Tekton 本身不是安全边界它把隔离与强制执行的职责完全委托给 Kubernetes 平台掌握 Workspace 的信任模型、volumeClaimTemplate按运行隔离模式以及ReadWriteMany的真实语义是避免跨信任域数据泄露的关键。读完本文你将获得一套可直接落地的 Workspace 安全设计清单与配置模板。总体安全模型Tekton 不是安全边界Tekton Pipelines 将Task与Pipeline作为 Kubernetes 工作负载执行。命名空间隔离、RBAC、准入控制Admission Control、ServiceAccount 权限、存储访问与网络访问等安全属性全部由 Kubernetes 以及 Tekton 周边的平台配置提供详见 Tekton 安全威胁模型。威胁模型明确了 Tekton 的定位Tekton 明确信任Kubernetes API Server、已配置的准入控制器如 Pod Security Admission、OPA/Gatekeeper、Kyverno 等、以及集群的 RBAC 访问决策模型。Tekton 不重复实现特权容器限制、hostPath/hostNetwork访问控制、命名空间隔离或多租户边界、网络出口过滤。一句话概括Tekton 是传令兵准入控制器是守门人。如果集群的准入配置允许某个 Pod 规格Tekton 就会原样提交该规格。这意味着创建TaskRun/PipelineRun等价于创建 Pod是有意设计——拥有创建TaskRun权限的用户天然拥有与创建原生 Pod 相当的能力podTemplate允许调用方配置安全上下文、卷挂载、节点选择器等 Pod 级设置这同样属于预期的信任委托而非可上报的漏洞。希望限制特权容器等能力时正确的执行层是集群的准入控制策略如 Pod Security Admission 的restricted或baselineprofile而不是向 Tekton 提交漏洞报告。Workspace 跨信任边界隔离问题的起点Workspace是TaskRun和PipelineRun挂载 Kubernetes 卷的方式可用于在Task之间共享源码、构建产物、缓存、凭据等文件。当一个 Workspace 由PersistentVolumeClaimPVC支撑时该 Workspace 的安全属性就等于底层 Kubernetes 卷的安全属性。因此必须把每一个被共享的 Workspace 都视为能够挂载它的所有Task/PipelineRun信任模型的一部分。例如一个校验不可信 Pull Request 的PipelineRun与一个构建或发布可信版本的PipelineRun不应该共享同一个可写的 PVC——这是本指南反复强调的第一原则。从源码结构看Workspace 的安全属性天然继承自 Kubernetes 卷在 pkg/workspace/apply.go 中CreateVolumes会把WorkspaceBinding中的PersistentVolumeClaim、EmptyDir、ConfigMap、Secret、Projected、CSI等VolumeSource直接翻译为原生corev1.Volume挂载进 PodWorkspaceBinding结构体本身也直接内嵌 Kubernetes 的PersistentVolumeClaimVolumeSource等类型见 pkg/apis/pipeline/v1/workspace_types.go。换句话说Tekton 在 Workspace 之上没有附加任何额外的文件系统隔离层——共享卷的安全性完全取决于底层 Kubernetes 卷的访问模式、权限与安全上下文。信任模型共享即信任Tekton不在故意挂载同一持久化 Workspace 的多个PipelineRun之间强制执行文件系统级隔离。如果两个PipelineRun把同一个 PVC 绑定到 Workspace它们创建出的 Pod 可以根据 PVC 访问模式、Kubernetes 卷权限以及容器安全上下文访问相同的文件。这一行为是有意设计的Workspace 共享是显式且主动选择opt-in的。它同时意味着可信与不可信工作负载之间的隔离是管道作者与集群运维人员的责任。建议采取以下手段限制谁能创建引用敏感 PVC 的PipelineRunKubernetes RBAC控制谁可以创建/绑定引用特定 PVC 的PipelineRun命名空间与 ServiceAccount 隔离存储策略StorageClass / PVC 归属与配额。需要特别警惕的误区readOnly的 Workspace 绑定只能阻止该挂载点写入不能让卷上已有的内容变得可信。不要仅仅因为高信任运行以只读方式挂载共享卷就把它当作安全数据源——先前运行的写入可能已经被污染。推荐模式按运行隔离per-run的 Workspace当一个PipelineRun需要可写的持久化 Workspace、但不应与其他运行共享文件时使用volumeClaimTemplate。它为每一个PipelineRun或TaskRun创建一个新的 PVC因此一次运行写入的数据不会通过同一 Workspace 绑定被另一次运行看到。apiVersion: tekton.dev/v1 kind: PipelineRun metadata: generateName: validate-pr- spec: pipelineRef: name: validate-pr workspaces: - name: source volumeClaimTemplate: spec: accessModes: - ReadWriteOnce resources: requests: storage: 1GiPVC 生命周期说明由volumeClaimTemplate创建的 PVC 会被自动供给automatically provisioned。其清理行为取决于PipelineRun生命周期与所配置的 Affinity Assistant 模式默认coschedule workspaces模式下PVC不会在PipelineRun完成后自动删除会保留在集群中供复用或手动清理如需自动清理可在PipelineRun上添加注解tekton.dev/auto-cleanup-pvc: true注解值必须严格为true其他任何值都保持默认不清除行为在coschedule pipelineruns与isolate-pipelinerun模式下PVC 无论是否设置注解都会在完成时被删除在disabled模式下不创建 Affinity AssistantPVC 生命周期交给 Kubernetes 垃圾回收带有ownerReference指向PipelineRun的 PVC 会随PipelineRun删除而删除。更完整的模式对照表与注解示例见 docs/affinityassistants.md。从实现侧看该注解常量AutoCleanupPVCAnnotation tekton.dev/auto-cleanup-pvc定义在 pkg/reconciler/pipelinerun/affinity_assistant.go并且只影响volumeClaimTemplate类型的 Workspace用户显式提供的persistentVolumeClaimWorkspace 即使设置该注解也永远不会被自动删除。避免跨信任边界共享现有 PVC只有当每一个可能挂载该声明的PipelineRun都属于同一信任域且都被允许读取或修改该卷上的文件时才应该把已有的persistentVolumeClaim绑定到 Workspace。当PipelineRun由不同信任级别的输入触发例如不可信的 Pull Request 与可信的发布自动化时应避免下面这类模式workspaces: - name: artifacts persistentVolumeClaim: claimName: shared-artifacts-rwx共享 PVC 可能造成的三类典型危害一次运行可以读取另一次运行遗留的文件一次运行可以修改后续运行将要消费的文件不同运行在同一路径上读写时发生竞态race。在共享 PVC 上使用subPath可以帮助组织数据目录但绝不能把它当作跨信任域的隔离边界——subPath只是目录定位不是安全机制。如果持久化数据必须跨越信任边界正确做法是先把它写入受控的存储或制品artifact系统由该系统在可信管道消费之前完成校验、签名、晋级或访问检查。Step 级 Isolated Workspaces 的边界Task 内部还提供 Step 级 Isolated Workspacesbeta 功能需将enable-api-fieldsfeature flag 设为beta。它可以把一个 Workspace 的访问限制在同一个Task内的特定Steps和Sidecars典型用途是让 SSH 凭据只暴露给执行git clone的 Step。其实现位于 pkg/workspace/apply.go 与mountAsIsolatedWorkspacepkg/workspace/apply.go只有当 Step/Sidecar 显式声明workspaces使用时挂载才会被注入到对应容器。需要明确边界该特性只能限制同一个 Task 内部的 Step/Sidecar 访问范围不能隔离绑定同一 PVC 的不同PipelineRun之间的数据。跨运行隔离仍必须依靠前述的 PVC 策略。ReadWriteManyPVC并发共享的文件系统ReadWriteMany是 Kubernetes 的访问模式在存储提供方支持的前提下允许卷被多个 Node 同时以读写方式挂载。任何被允许挂载该 PVC 的 Pod 都能并发访问同一个文件系统——这是 Kubernetes 卷本身的行为与 Tekton 无关。不要把ReadWriteMany当作隔离机制。它适合单一信任域内的共享缓存、协调式工作流但会放大意外在不同信任级别的PipelineRun之间共享 PVC的影响面。ReadWriteOnce同样不是信任边界。它只限制卷被挂载的位置同一时刻仅一个 Node不会清除先前的内容也不能阻止后续有权限的运行读取或修改这些内容。可用性考量并行 Task 与 Affinity Assistant在PipelineRun中使用 PVC 支撑的 Workspace 时访问模式还直接影响并行Task的可用性详见 docs/workspaces.mdReadWriteOnce卷同一时刻只能挂载到一个 Node 上若 Pipeline 中有并行Task并发访问同一卷会出问题Tekton 的 Affinity Assistant 会把共享同一 PVC 的TaskRunPod 调度到同一 Node 来解决该问题ReadOnlyMany通常需要在用前准备数据动态供给的卷一般无法以只读模式使用ReadWriteMany卷若集群内所有 Node 均可访问可考虑禁用 Affinity Assistant但任何能挂载它的 Pod 都能并发访问同一文件系统切勿跨信任域共享。需要额外注意coschedule模式与 PVC 共享也存在约束当coschedule设为workspaces或disabled时一个TaskRun在单个PipelineRun中不允许绑定多个 PVC 支撑的 Workspace避免可用区冲突详见 docs/workspaces.md 与 docs/affinityassistants.md。安全设计清单结合官方文档跨信任边界设计 Workspace 时请逐项核对需要按PipelineRun/TaskRun隔离的可写 Workspace一律使用volumeClaimTemplate不要在不同信任级别如不同来源的代码、输入或凭据运行的管道之间共享已有 PVC把ReadWriteManyPVC 视为并发共享的文件系统——任何能挂载它的 Pod 都可访问不要用作隔离手段不要依赖subPath、访问模式或任务执行顺序task ordering作为可信/不可信工作负载之间的安全边界为不同的信任域使用独立的命名空间、ServiceAccount、RBAC 以及存储类或存储声明跨越信任边界传递制品时先通过能够校验并授权数据的系统校验、签名、晋级、访问检查再由可信管道消费每个 Workspace 绑定都会在 pkg/apis/pipeline/v1/taskrun_validation.go 的ValidateWorkspaceBindings中经过控制器级校验确保绑定与声明匹配但校验只保证配置合法不保证数据可信。与威胁模型的关系什么该上报、什么不是漏洞理解 Workspace 隔离的最佳实践也有助于判断一个安全问题是否在 Tekton 的修复范围内详见 Tekton 安全威胁模型不在修复范围out of scope通过podTemplate请求特权容器、hostPath等——属于预期的信任委托执行层是集群准入控制ResolverGit Resolver、HTTP Resolver、Bundle Resolver 等按用户提供的 URL 拉取定义——解析用户可控 URL正是这些组件的设计目的不应作为 SSRF 上报需要限制外部端点时应使用 KubernetesNetworkPolicy或出口过滤文档与实现不符的一般性文档错误——作为普通 issue 提交除非某份文档做出了明确、无歧义的安全承诺而实现确实违背。在修复范围in scope遇到以下情况应通过私密渠道上报绕过 Tekton 控制器级内部校验如 Workspace 挂载路径校验、/tekton/目录前缀检查、资源名校验畸形资源导致控制器 panic、不可恢复状态、无界内存消耗或停止处理合法工作含对远端端点的无界读取控制器或 Resolver 以超出任务作者显式配置的方式泄露 Secret/凭据如把环境变量值打印进日志、在错误消息中携带凭据TrustedResources/VerificationPolicy当前为 alpha 功能的信任验证绕过导致未经验证或被恶意修改的资源被当作验证通过。结语Workspace 安全的核心不是寻找Tekton 的隔离漏洞而是正确理解信任边界并把它落实到 PVC 的使用模式上按运行隔离用volumeClaimTemplate跨信任域不共享既有 PVCReadWriteMany只是并发文件系统而非隔离机制subPath/readOnly/访问模式都不是安全边界。把隔离职责交给 Kubernetes 的 RBAC、命名空间、准入控制与存储策略并在可信管道消费跨域数据之前引入独立的校验与签名环节——这就是 Tekton 官方安全文档给出的完整答案。相关配置字段与校验逻辑可在 pkg/apis/pipeline/v1/workspace_types.go、pkg/workspace/apply.go 与 pkg/reconciler/pipelinerun/affinity_assistant.go 中继续深入阅读。赞分享云原生CI/CDDevOps后端【免费下载链接】pipelineA cloud-native Pipeline resource.项目地址https://gitcode.com/gh_mirrors/pipelin/pipeline点击查看免费下载相关推荐终极AI安全隔离实战指南如何使用E2B构建零信任AI环境的完整方案终极AI安全隔离实战指南如何使用E2B构建零信任AI环境的完整方案 在AI技术快速发展的今天安全隔离已成为企业部署AI代理的核心挑战。E2B作为开源的Clo人工智能AI AgentAgent 沙箱后端Tekton Pipelines Workspaces深度指南跨任务共享数据与PVC缓存挂载实战Tekton Pipelines Workspaces深度指南跨任务共享数据与PVC缓存挂载实战 Tekton Pipelines 是一款云原生的 CI/CD云原生CI/CDDevOps后端Security-101 共享责任模型解析IaaS/PaaS/SaaS 的安全责任边界、CSP 合规验证与信任但验证实践Security 101 共享责任模型解析IaaS/PaaS/SaaS 的安全责任边界、CSP 合规验证与信任但验证实践 共享责任模型Shared Re网络安全教程文档上一篇3分钟解锁BT下载的隐藏超能力100个公共Tracker的魔法配置下一篇Flet TabBarTheme 主题详解用 Python 统一配置 TabBar 全局样式创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考