Tekton injected init-containers and steps should runAsNonRoot

[skaegi]

Running in a restricted environment a simple example TaskRun pod fails with...

Events:
  Type     Reason     Age                From                  Message
  ----     ------     ----               ----                  -------
  Normal   Scheduled  25s                default-scheduler     Successfully assigned default/echo-hello-world-task-run-pod-jvc89 to 10.94.4.205
  Normal   Pulled     11s (x3 over 23s)  kubelet, 10.94.4.205  Container image "gcr.io/tekton-releases/github.com/tektoncd/pipeline/cmd/entrypoint:v0.14.1@sha256:01aa4367a17cb60af0134175574c62bd40c52c5e07d12c7bf1b04195f228054f" already present on machine
  Warning  Failed     11s (x3 over 23s)  kubelet, 10.94.4.205  Error: container has runAsNonRoot and image will run as root

The entrypoint container (the lucky winner in this case) does not require root however we should also update the other containers Tekton injects to runAsUser: 1001 as they likely don't need root privs.

[ghost]

One thing to be wary of here: assigning a random UID is not quite enough for our various init containers / helpers. The UID needs to have an entry in /etc/passwd with a home directory defined as well. Otherwise behaviour for things like credential initialization can break - errors will start appearing related to things like being unable to copy /tekton/creds/.docker to /.docker. Particularly true when the disable-home-env-override feature flag is "true".

[skaegi]

Hmm... ok thanks Scott. I was also thinking about this some more and we probably could do this better by changing the actual underlying USER in the image.

[gabemontero]

Yeah my team has had similar experiences with random UUID and updating /etc/passwd in other scenarios as @sbwsg notes ... I can +1 the need

[gabemontero]

But in those scenarios yes @skaegi we typically have something like a USER 1001 type directive in the image's Dockerfile.

[dlorenc]

i think I ran into this over at https://github.com/tektoncd/catalog/pull/439 as well

[tekton-robot]

Issues go stale after 90d of inactivity. Mark the issue as fresh with /remove-lifecycle stale. Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with /close.

/lifecycle stale

Send feedback to tektoncd/plumbing.

[ghost]

/remove-lifecycle stale

[tekton-robot]

Issues go stale after 90d of inactivity. Mark the issue as fresh with /remove-lifecycle stale with a justification. Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with /close with a justification. If this issue should be exempted, mark the issue as frozen with /lifecycle frozen with a justification.

/lifecycle stale

Send feedback to tektoncd/plumbing.

[kutsal]

Bump. Has there been any progress on this? Our PSP blocks anything running as root...

[tekton-robot]

Stale issues rot after 30d of inactivity. Mark the issue as fresh with /remove-lifecycle rotten with a justification. Rotten issues close after an additional 30d of inactivity. If this issue is safe to close now please do so with /close with a justification. If this issue should be exempted, mark the issue as frozen with /lifecycle frozen with a justification.

/lifecycle rotten

Send feedback to tektoncd/plumbing.

[ghost]

There's been some progress here. We recently updated the git-init image to also include a nonroot user with UID 65532. See https://github.com/tektoncd/pipeline/issues/3712 and PR https://github.com/tektoncd/pipeline/pull/3727

Obviously all the files cloned with this nonroot user are owned by UID 65532 so it's up to the user's pipeline to enforce any ownership rules they need on the files.

We've created an issue to focus on providing a similar fix in the PullRequest image: https://github.com/tektoncd/pipeline/issues/3746

/remove-lifecycle rotten

[tekton-robot]

Issues go stale after 90d of inactivity. Mark the issue as fresh with /remove-lifecycle stale with a justification. Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with /close with a justification. If this issue should be exempted, mark the issue as frozen with /lifecycle frozen with a justification.

/lifecycle stale

Send feedback to tektoncd/plumbing.

[tekton-robot]

Stale issues rot after 30d of inactivity. Mark the issue as fresh with /remove-lifecycle rotten with a justification. Rotten issues close after an additional 30d of inactivity. If this issue is safe to close now please do so with /close with a justification. If this issue should be exempted, mark the issue as frozen with /lifecycle frozen with a justification.

/lifecycle rotten

Send feedback to tektoncd/plumbing.

[ghost]

@sbwsg check which tekton-provided images still need root access and document accordingly. Create issues to remove this limitation for each image.

[tekton-robot]

Issues go stale after 90d of inactivity. Mark the issue as fresh with /remove-lifecycle stale with a justification. Stale issues rot after an additional 30d of inactivity and eventually close. If this issue is safe to close now please do so with /close with a justification. If this issue should be exempted, mark the issue as frozen with /lifecycle frozen with a justification.

/lifecycle stale

Send feedback to tektoncd/plumbing.

[tekton-robot]

Stale issues rot after 30d of inactivity. Mark the issue as fresh with /remove-lifecycle rotten with a justification. Rotten issues close after an additional 30d of inactivity. If this issue is safe to close now please do so with /close with a justification. If this issue should be exempted, mark the issue as frozen with /lifecycle frozen with a justification.

/lifecycle rotten

Send feedback to tektoncd/plumbing.

[ghost]

/lifecycle frozen

At the very least we should assess whether this is feasible and definitively document yes/no, rather than let it atrophy.

[ghost]

/assign

[vdemeester]

@tektoncd/core-maintainers isn't this fixed by now ?

[vdemeester]

As of recent releases, Tekton Pipelines includes security context support for injected containers:

1. Security Context Implementation (pkg/pod/security_context_config.go)

   • Both LinuxSecurityContext and WindowsSecurityContext now set RunAsNonRoot: true
   • Includes AllowPrivilegeEscalation: false and drops all capabilities
   • Meets Kubernetes "restricted" pod security standards

2. Applied to Injected Containers

   • Init containers (e.g., prepare / entrypoint init)
   • Sidecar containers (e.g., sidecar-tekton-log-results)
   • Affinity Assistant pods

3. Base Images Updated

   • Using Chainguard distroless images that support non-root execution
   • See .ko.yaml

🔧 How to Enable

The feature is disabled by default. To enable it, set the set-security-context feature flag to true:

kubectl patch cm feature-flags -n tekton-pipelines -p '{"data":{"set-security-context":"true"}}'

⚠️ Known Limitations

• Not supported on all Kubernetes implementations (e.g., OpenShift - see docs)
• Requires Kubernetes 1.28+ for full functionality
• Still disabled by default, so the original issue (failing in restricted environments by default) persists for new users

I will close this issue and open a new enhancement issue to discuss making set-security-context: true the default.