Skip to content

fix(shield): gate host OpenShift SCC privileged fields on .Values.host.privileged#2625

Open
EdwardArchive wants to merge 1 commit into
sysdiglabs:mainfrom
EdwardArchive:fix/shield-host-scc-2621
Open

fix(shield): gate host OpenShift SCC privileged fields on .Values.host.privileged#2625
EdwardArchive wants to merge 1 commit into
sysdiglabs:mainfrom
EdwardArchive:fix/shield-host-scc-2621

Conversation

@EdwardArchive
Copy link
Copy Markdown
Contributor

Fixes #2621

Summary

The host SecurityContextConstraints unconditionally granted:

allowPrivilegeEscalation: true
allowPrivilegedContainer: true

…even though the daemonset's pod security context (host.security_context in templates/host/_helpers.tpl) already sets allowPrivilegeEscalation: false and drops to a curated capability set when .Values.host.privileged is false:

{{- else if .Values.host.privileged }}
privileged: true
runAsNonRoot: false
runAsUser: 0
runAsGroup: 0
readOnlyRootFilesystem: false
allowPrivilegeEscalation: true
capabilities:
  drop:
    - ALL
{{- else }}
allowPrivilegeEscalation: false
seccompProfile:
  type: Unconfined
...

The same SCC file was already partially aware of host.privileged for allowedCapabilities, but allowPrivilegeEscalation / allowPrivilegedContainer remained hardcoded. As a result, users running Universal eBPF in non-privileged mode received an over-permissive SCC, defeating the security benefit of choosing the non-privileged driver.

Changes

  • templates/host/openshift-securitycontextconstraint.yaml — render both fields from .Values.host.privileged, mirroring the daemonset.
  • tests/host/openshift-securitycontextconstraint_test.yaml — two new helm-unittest cases (privileged true → both true; privileged false + universal_ebpf → both false).
  • Chart.yaml — bump to 1.37.2.

Behavioral compatibility

Default values keep host.privileged: true, so the rendered SCC for the default install is identical. Only users who have deliberately switched to non-privileged Universal eBPF mode see a tighter SCC — which is what they were already trying to achieve at the daemonset level.

Test plan

  • helm unittest --strict -f tests/host/openshift-securitycontextconstraint_test.yaml charts/shield → 11 passed
  • helm template privileged → allowPrivilegeEscalation: true, allowPrivilegedContainer: true
  • helm template host.privileged=false host.driver=universal_ebpf → both false, capabilities set drops to DAC_READ_SEARCH … SYS_RESOURCE

Checklist

  • Title starts with type and scope (fix(shield):)
  • Chart version bumped (1.37.1 → 1.37.2)
  • Tests added in tests/ with _test suffix

🤖 Generated with Claude Code

…ed (sysdiglabs#2621)

The host SCC unconditionally granted `allowPrivilegeEscalation: true`
and `allowPrivilegedContainer: true`, while the daemonset's pod
security context (`host.security_context` in _helpers.tpl) already
sets `allowPrivilegeEscalation: false` and drops to a curated
capability set when `.Values.host.privileged` is false. The same SCC
file was already partially aware of `host.privileged` for
`allowedCapabilities`, so users running Universal eBPF in
non-privileged mode got an over-permissive SCC that defeated the
security benefit of the unprivileged driver.

Gate both fields on `.Values.host.privileged`, mirroring the
daemonset. Tests cover both privileged and unprivileged paths.

Refs: sysdiglabs#2621
@EdwardArchive EdwardArchive requested a review from a team as a code owner May 13, 2026 03:09
@github-actions
Copy link
Copy Markdown
Contributor

Hi @EdwardArchive. Thanks for your PR.

After inspecting your changes someone with write access to this repo needs
to approve and run the workflow.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[Security] host OpenShift SCC hardcodes allowPrivilegeEscalation/allowPrivilegedContainer regardless of .Values.host.privileged

2 participants