Auth & Pod config

The Kubernetes identity a TaskRun's Pod runs as; defaults to the namespace's default SA unless set.

It carries two things at once: the Secrets that credential initialization turns into git/docker config, and the RBAC token steps use against the API server. Pick it per task, not per cluster.

Before the first step, Tekton turns the SA's annotated Secrets into ~/.gitconfig, ~/.git-credentials, ~/.ssh/* and ~/.docker/config.json under /tekton/creds, then copies them into each step's $HOME.

Tools like git and crane pick credentials up with no Task changes. The flip side: every attached secret lands in every step, whether that step needs it or not.

Annotations on a Secret that tell Tekton which host (or registry) the credential is for, e.g. tekton.dev/git-0: https://github.com.

The annotation is the match key. git matches on protocol + host, ssh on Host and port, docker on the registry. An https token does nothing for an ssh URL.

A kubernetes.io/basic-auth Secret (username + password/token), usable for git over https or a registry.

For git it becomes a [credential] entry plus a line in ~/.git-credentials used by the store helper. For docker it becomes an auths entry.

A kubernetes.io/ssh-auth Secret with ssh-privatekey and optionally known_hosts, for git over ssh.

It becomes a Host block in ~/.ssh/config pointing at the key. Without known_hosts the server's host key is not pinned, so add it.

A kubernetes.io/dockerconfigjson Secret holding a full Docker config; attached to the SA, its auths are merged into ~/.docker/config.json.

No annotation needed. Not the same thing as imagePullSecrets, which the kubelet uses to pull step images.

Kubernetes rules (apiGroups, resources, verbs) bound to a ServiceAccount, which decide what kubectl in a step may do.

A deploy task's kubectl apply needs get plus create or patch on its objects. Anything more is reach an attacker inherits if a step is compromised.

Give each pipeline task an SA that can do exactly its job: clone and build get no API rights, deploy gets a narrow Role.

One shared, powerful SA means every step, including third-party test code, holds a token that can deploy or read Secrets.

PipelineRun field that sets serviceAccountName and podTemplate for every TaskRun it creates.

The pipeline-wide default. It replaced the older top-level serviceAccountName / podTemplate fields in the v1 API.

PipelineRun field that overrides serviceAccountName, podTemplate, compute resources and more for one named pipeline task.

This is how you give only the deploy task the deployer SA, or only the build task arm64 nodes.

Binding a Secret to a workspace mounts its keys as read-only files in the Task, optionally only in the steps that declare it.

Explicit and auditable: the Task says it needs a credential, only the bound tasks get it, and nothing lands in env or in API objects.

A step env var whose value comes from a Secret key; the Pod spec shows only the reference.

Convenient for tools that only read env vars, but env is inherited by child processes and easily printed. Tekton does not redact secrets in logs.

A subset of Pod spec fields (nodeSelector, tolerations, affinity, securityContext, imagePullSecrets, env, hostAliases, dnsConfig, priorityClassName, volumes…) applied to the TaskRun's Pod.

It's how you control where and how a Task runs without editing the Task: a Task stays portable, the run carries the cluster-specific bits.

The default-pod-template key in the config-defaults ConfigMap, merged under every TaskRun's podTemplate.

Cluster-wide defaults like proxies, pull secrets or a non-root securityContext. Fields are replaced wholesale by higher layers; env and volumes merge by name.

Secrets the kubelet uses to pull the step and sidecar images, set on the SA or in podTemplate.

Pulling the image that runs a step is the kubelet's job. Pushing an image from inside a step uses credential initialization or a workspace.

Pod- and container-level settings: runAsNonRoot, runAsUser, allowPrivilegeEscalation, capabilities, seccompProfile, privileged.

Some fields, like allowPrivilegeEscalation and capabilities, only exist per container, so a pod-level securityContext from podTemplate can't make every container compliant by itself.

The built-in admission controller that enforces the privileged / baseline / restricted profiles per namespace via labels.

Under restricted a privileged DinD build won't even get a Pod: the TaskRun fails at creation with a 'violates PodSecurity' message.

Feature flag that makes Tekton give its injected init containers (and its own containers) a restricted-compatible securityContext.

Without it, Tekton's prepare and place-scripts containers fail the restricted profile even when your steps are clean.

Building container images inside a step without a Docker daemon or privileged mode.

kaniko drops the privileged flag but still runs as root, rootless buildah needs privilege escalation for user namespaces, and ko/jib need nothing special because they never run RUN instructions.

Each step's computeResources requests/limits; a namespace LimitRange supplies defaults and min/max per container.

Steps run one at a time but are regular containers, so the scheduler reserves the sum of their requests. Tekton splits a LimitRange default request across the steps that don't set one.