Kubernetes: add instance-wide default and enforced Security Context#6310
Draft
Aex12 wants to merge 2 commits into
Draft
Kubernetes: add instance-wide default and enforced Security Context#6310Aex12 wants to merge 2 commits into
Aex12 wants to merge 2 commits into
Conversation
Aex12
force-pushed
the
feat/kubernetes-security-context-flags
branch
from
efc9339 to
310a379
Compare
Contributor
|
Surge PR preview deployment succeeded. View it at https://woodpecker-ci-woodpecker-pr-6310.surge.sh |
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #6310 +/- ##
==========================================
+ Coverage 33.26% 33.40% +0.13%
==========================================
Files 420 420
Lines 28344 28413 +69
==========================================
+ Hits 9428 9490 +62
- Misses 18037 18042 +5
- Partials 879 881 +2 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
Aex12
force-pushed
the
feat/kubernetes-security-context-flags
branch
from
b8bfe37 to
68354ea
Compare
6543
pushed a commit
that referenced
this pull request
Apr 28, 2026
### Problem When the working directory is set to a directory that doesn't exists (for example, as `plugin-git` does), kubelet will pre-create it with ownership set to `root:root` and permissions `0755` . This makes pods running as non-root unable to write to it, causing permission errors. ### Solution Added a `podInitContainer` function that conditionally creates an init container to pre-create the working directory with the correct permissions before the main step container starts. ### Behavior - If the pod runs as root (`RunAsUser == 0` or unset), no init container is created. Kubelet handles directory creation automatically - If the working directory matches a volume mount path exactly, no init container is needed. `FSGroupChangePolicy` handles permissions - An init container is only created when the working directory is nested within a volume mount path - The init container uses `busybox:stable-musl` with minimal resource limits (5m CPU, 5Mi memory) and drops all capabilities. ### Related issues and PRs - Solves the error mentioned in #5346 (comment) without requiring a previous step. - In addition to #6307 and #6310, this will make it easier to run woodpecker ci workloads in a namespace that enforces [Pod Security Standards](https://kubernetes.io/docs/concepts/security/pod-security-standards/)
Member
|
#6307 got merged ... |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
This PR depends on PR #6307 being merged first.
Description
Currently, when using the Kubernetes backend, there is no mechanism for instance owners to define an instance-wide Security Context that applies to all CI workloads running in the cluster.
This poses several problems:
This PR tries to fix this by allowing instance owners to define two new variables on the agent:
WOODPECKER_BACKEND_K8S_DEFAULT_SECCTX: This is the securityContext that will be applied by default to all CI workloads running in the cluster, and it can be overridden by workflows.WOODPECKER_BACKEND_K8S_ENFORCED_SECCTX: This is the securityContext that will be applied to all CI workloads, it cannot be overridden by individual workflows.An example configuration of this two variables that will allow running the ci workloads in an unprivileged namespace is:
Possible deprecations
This PR preserves the functionality of the existing
BACKEND_K8S_SECCTX_NONROOTvariable for backward compatibility purposes, however with this PR changes we can achieve the same functionality by settingWOODPECKER_BACKEND_K8S_ENFORCED_SECCTX='{"runAsNonRoot":true}'With the added advantage of it being more flexible for instance owners to configure a wider range of enforced security context options.
About the environment variable names
I decided to go with SECCTX to make it more consistent with the existing
BACKEND_K8S_SECCTX_NONROOT, however I think it'll be more appropiate to useSECURITY_CONTEXT, to make the intent clear. What is your opinion about this?Added documentation
This PR also includes a small guide that explains how to run CI workloads in unprivileged namespaces using the added functionality. Currently the guide includes a workaround for the unprivileged clone step as mentioned in #5346. If PR #6312 gets merged, we can safely remove that from the guide, as it'll become unnecessary.