Kubernetes: Support allowPrivilegeEscalation and capabilities backend_options#6307
Conversation
@qwerty287 Currently, most kubernetes distributions run pods with This PR allows users to tighten the workflow pod security context, so they can run in namespaces enforcing the Pod Security Standards. That said, we could change this so that Regarding I think this changes make sense, I'll submit a new commit with them. |
|
Surge PR preview deployment was removed |
|
Sorry @qwerty287, I forgot to relaunch the tests after my last commit. I just added a new commit that fixes the test. SecurityContext is being set because privileged steps set the SecurityContext.Privileged field to true unless set otherwise. This was the existing behavior prior to my changes, which is preserved. |
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #6307 +/- ##
==========================================
+ Coverage 34.17% 34.24% +0.06%
==========================================
Files 426 426
Lines 28541 28562 +21
==========================================
+ Hits 9755 9782 +27
+ Misses 17898 17892 -6
Partials 888 888 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
|
Code itself seems fine, @woodpecker-ci/maintainers could someone check out the k8s impact? |
|
@Aex12 can you rebase once again? Implementation looks good to me. @henkka @MartinSchmidt as you contributed multiple times to the K8s backend and seem to user it on a daily basis you might want to take a look as well :) |
|
Hi @xoxys, just rebased from main and squashed my commits. |
### 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/)
5 participants
With this PR changes, we can finally run workflows in a restricted namespace in the Kubernetes backend.
Related to #5346. I wouldn't say it closes it, but improves the situation by providing means to run in a fully unprivileged namespace.
Also, I'm not sure how should I backport this to v3.13.x, I can't find the release/v3.13 branch