You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Support isolated rootless builder jobs on Kind without relaxing worker security #273
The 0.9.0 builder security backport retains Kubernetes user namespaces (hostUsers: false), a non-privileged rootless worker, no service-account token and the BuildKit process sandbox. Kind must support legitimate builds without disabling those protections.
In an isolated lab with Kind 0.30.0, Kubernetes 1.33.1, containerd 2.1.1 and Linux 6.8.0-146, a valid build is accepted but fails before the worker starts: mounting sysfs ... operation not permitted. A minimal BusyBox pod with hostUsers: false reproduces it; the equivalent ordinary pod succeeds.
An initial read-only sysfs mount inside the Kind node clears the sandbox mount failure and exposes a second error: /kind/bin/mount-product-files.sh: permission denied; the node's /kind directory is mode 0644. This is still under test, not a completed compatibility fix.
Acceptance: a valid base-image and dependency build completes and pushes to the authenticated lab registry; the resulting image can run an action; malformed and cross-tenant targets remain rejected; worker user namespaces, non-privileged mode, token exclusion and process sandbox remain enabled. Node setup must be repeatable and survive node restart without granting workers access to the host Docker socket or host paths.
Scheduling clarification: Kind compatibility targets 0.9.3 and will not be included in 0.9.0. The Apache task/admin-api repositories do not yet have a 0.9.3 branch. Development and lab validation continue on personal fork branches; the compatibility PRs will wait for that base branch. Related 0.9.0 security PRs remain separate.
Both use branch fix-0.9.3-kind-builder. The admin-api branch is currently based on the security backport; the final diff/base must be reconciled when Apache 0.9.3 exists. Compatibility PRs have deliberately not been opened against 0.9.0.
Validation on Kind 0.30.0 / Kubernetes 1.33.1 / containerd 2.1.1:
Minimal user-namespace pod succeeds.
Node preparation is repeatable; its service and read-only sysfs mount survive a node restart.
Base-image build and authenticated registry push succeed.
Dependency build installs pyfiglet 1.0.2, pushes its image, and an action using it returns HTTP 200 with the expected library version. Repeated successfully after node restart and service readiness.
Invalid source/target and cross-tenant target requests still return HTTP 400; seven focused unit tests pass.
hostUsers: false, token automount disabled, non-privileged worker, bounded UID mappings and BuildKit process-mode:sandbox remain in place. No worker hostPath or Docker socket was added. The extra sysfs is read-only/nosuid/nodev/noexec under a root-only directory inside the Kind node.
Test qualifications: the lab registry secret required an additional auth endpoint matching its internal service name (authentication was retained). The public Python 3.12 baseline image lacks /bin/extend; the dependency test used a test-only derived runtime implementing that existing 0.9.0 contract. No Alpha/Beta source code was changed. These are functional/regression tests, not a claim of an exhaustive independent security audit.
Activity
miki3421 commentedon Oct 14, 2026
Scheduling clarification: Kind compatibility targets 0.9.3 and will not be included in 0.9.0. The Apache task/admin-api repositories do not yet have a 0.9.3 branch. Development and lab validation continue on personal fork branches; the compatibility PRs will wait for that base branch. Related 0.9.0 security PRs remain separate.
miki3421 commentedon Oct 14, 2026
Kind compatibility is implemented and validated in the isolated lab, held for the future 0.9.3 branch as agreed.
Personal fork commits (no Apache branch was created):
Both use branch
fix-0.9.3-kind-builder. The admin-api branch is currently based on the security backport; the final diff/base must be reconciled when Apache 0.9.3 exists. Compatibility PRs have deliberately not been opened against 0.9.0.Validation on Kind 0.30.0 / Kubernetes 1.33.1 / containerd 2.1.1:
hostUsers: false, token automount disabled, non-privileged worker, bounded UID mappings and BuildKitprocess-mode:sandboxremain in place. No worker hostPath or Docker socket was added. The extra sysfs is read-only/nosuid/nodev/noexec under a root-only directory inside the Kind node.Test qualifications: the lab registry secret required an additional auth endpoint matching its internal service name (authentication was retained). The public Python 3.12 baseline image lacks
/bin/extend; the dependency test used a test-only derived runtime implementing that existing 0.9.0 contract. No Alpha/Beta source code was changed. These are functional/regression tests, not a claim of an exhaustive independent security audit.Related 0.9.0 security PRs remain apache/openserverless-admin-api#60 and apache/openserverless-task#237. Once 0.9.3 is available, the Kind PRs will be linked here for closure.