Skip to content

fix: decouple skills from the privileged sandbox and default to restricted PSS#2334

Draft
QuentinBisson wants to merge 1 commit into
kagent-dev:mainfrom
QuentinBisson:fix/skills-restricted-pss
Draft

fix: decouple skills from the privileged sandbox and default to restricted PSS#2334
QuentinBisson wants to merge 1 commit into
kagent-dev:mainfrom
QuentinBisson:fix/skills-restricted-pss

Conversation

@QuentinBisson

Copy link
Copy Markdown
Contributor

Fixes #1997. Fixes #2244.

What

Two changes to how the controller renders agent pod security:

Skills no longer imply privileged: true (#1997). Skills loading (git clone / OCI pull in skills-init) needs no elevated privileges; privileged exists only for the srt/bubblewrap BashTool sandbox, and the controller conflated the two. Now only the explicit declarative.executeCodeBlocks: true opt-in requests the privileged sandbox (the existing allowPrivilegeEscalation: false guard still suppresses it), and securityContext.privileged: true remains the manual knob. This is safe rather than a silent downgrade: both runtimes always exec srt, which fails loudly per command when it cannot set up isolation — there is no unsandboxed fallback path.

Restricted-PSS defaults (#2244). When the user provides no securityContext, the agent container and the skills-init container now render the Pod Security Standards restricted profile (allowPrivilegeEscalation: false, runAsNonRoot: true, capabilities.drop: [ALL], seccompProfile: RuntimeDefault) instead of nothing, so agents are admitted on restricted-enforcing clusters out of the box. A user-provided securityContext passes through unchanged. All first-party images already run as non-root; python/Dockerfile.full switches from USER python to the numeric USER 1001:1001 so the kubelet can verify runAsNonRoot without an explicit runAsUser.

Behavior change for skills users who relied on the implicit privileged sandbox: bash commands on clusters without unprivileged user namespaces will return per-command sandbox errors until executeCodeBlocks: true (or securityContext.privileged: true) is set. BYO images that run as root now need an explicit securityContext.

Tests

TestSecurityContext_SkillsDefaultNotPrivileged (flipped from the previous SkillsDefaultPrivilegedSandbox, incl. skills-init), TestSecurityContext_ExecuteCodeBlocksKeepsPrivileged, TestSecurityContext_DefaultIsRestricted; golden files regenerated.

…icted PSS

Skills alone no longer set privileged=true on the agent container: skills loading needs no elevated privileges, and srt fails loudly per command when it cannot sandbox, so nothing runs unsandboxed. The explicit executeCodeBlocks opt-in keeps requesting the privileged sandbox, and securityContext.privileged remains the manual knob.

When no securityContext is provided, the agent and skills-init containers now default to the Pod Security Standards restricted profile (allowPrivilegeEscalation=false, runAsNonRoot, drop ALL, RuntimeDefault seccomp). Dockerfile.full switches to a numeric USER so runAsNonRoot is verifiable by the kubelet.

Fixes kagent-dev#1997
Fixes kagent-dev#2244

Signed-off-by: QuentinBisson <quentin@giantswarm.io>
@github-actions github-actions Bot added the bug Something isn't working label Jul 26, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

bug Something isn't working

Projects

None yet

1 participant