Tekton Pipelines

What Tekton Pipelines Is Built to Do

Tekton Pipelines turns CI and CD work into Kubernetes-native objects, so build and delivery logic is defined the same way as other cluster workloads. That makes the system flexible and composable, but it also means pipeline design must be treated as part of cluster security and not just build automation.

Because Tekton models execution as reusable tasks and pipelines, teams can standardise delivery steps across many repos and services. The upside is consistency and portability; the trade-off is that a mistake in one shared task, image, or permission set can propagate widely.

How Tekton Pipelines Uses Kubernetes Primitives

Tekton runs workflows through Kubernetes resources, which means the cluster becomes the control plane for pipeline execution. In practice, that ties pipeline behaviour to namespace boundaries, controller permissions, pod execution settings, and the admission and policy controls already present in the cluster.

Service accounts matter because they determine what a pipeline run can reach while it is executing. If a pipeline uses an overly broad account, the workflow may inherit more access than the build itself requires, especially when tasks need registry pushes, secret reads, deployment actions, or access to other internal services.

Reusable steps are a strength when they are curated, versioned, and reviewed. They become a liability when teams assume a task is safe simply because it is shared, since any hidden command, image change, or script injection point can be replicated across multiple pipelines.

Security Implications of Pipeline Execution

Tekton Pipelines sits directly on the path to source code, artifacts, secrets, and deployment targets, so compromise can affect the software supply chain end to end. A pipeline that can read credentials, modify manifests, or publish images can be turned into a fast route from build-time access to production impact.

The most important security questions are whether the pipeline can be trusted to use only approved inputs, whether its steps are isolated enough to limit blast radius, and whether its credentials are scoped tightly enough for the job. For container-based CI/CD, those controls are often the difference between a routine build system and a cluster-wide trust anchor.

Supply-chain integrity is especially important when tasks pull external images or shared components. The stronger the reuse model, the more important provenance, pinning, and review become, because a changed dependency can silently alter how every downstream pipeline behaves.

For a broader control view, SLSA is a useful companion because it focuses attention on build provenance and artifact integrity, while SLSA helps teams reason about what must be verified before a pipeline-produced artifact is trusted.

Operational Boundaries and Trust Decisions

Tekton Pipelines is usually adopted to improve repeatability, but repeatability only helps if the trust boundaries are clear. The practical design choice is whether each pipeline run should have narrowly scoped permissions, isolated workspaces, and predictable network reach, or whether convenience is allowed to override separation between build, test, and deploy functions.

That boundary question extends to secrets handling. If a pipeline step needs credentials, those secrets should be treated as short-lived operational inputs, not as permanent fixtures of the workflow. The same is true for generated artifacts, because a compromised pipeline can reuse or exfiltrate them long after the run ends.

Teams also need to think about review and ownership. Shared pipeline logic should have explicit maintainers, version control discipline, and change review, since a workflow change can be as sensitive as a change to application code or deployment policy.

For identity and privilege controls in Kubernetes-adjacent delivery systems, the key principle is to keep runtime permissions minimal and auditable. NHIMG’s CI/CD pipeline exploitation case study shows how exposed credentials and pipeline control can translate into server-side compromise, which is exactly why delivery permissions need the same scrutiny as production access.

Related resources from NHI Mgmt Group

• How do organisations reduce false positives in secret detection pipelines?
• How should security teams handle exposed secrets in modern software pipelines?
• Why do CI/CD pipelines create special NHI governance problems?
• How should security teams govern credentials used by CI/CD pipelines?