cyberchef: seccompProfile RuntimeDefault in the pod context

Sets seccompProfile.type: RuntimeDefault in the pod security context, so
the container runtime's default syscall filter applies to every container
in the pod. Verified in k3d: /proc/1/status reports Seccomp: 2 (filter
mode) with one filter loaded, and nginx keeps serving the app.

The value lives in the pod context rather than the container context
because it covers init containers and any container added later without
being repeated; a container that needs a different filter can still
override it under securityContext.container, which wins over the pod
value.

Major bump: runtime behavior changes, even though it stays invisible for
this workload.

Refs #84
This commit is contained in:
jklein committed 2026-08-23 23:00:02 +02:00
1 parent 69202d5e13
commit 4a61f763e8
3 files changed
+12 -2

No files matched your search

+1 -1
View File
@@ -5,7 +5,7 @@ icon: https://raw.githubusercontent.com/gchq/CyberChef/master/src/web/static/ima
type: application type: application
version: 8.0.0+up11.4.0 version: 9.0.0+up11.4.0
appVersion: "11.4.0" appVersion: "11.4.0"
maintainers: maintainers:
+2 -1
View File
@@ -214,7 +214,8 @@ default probe needs no further context.
{{- $defaults := dict {{- $defaults := dict
"runAsNonRoot" true "runAsNonRoot" true
"runAsUser" 101 "runAsUser" 101
"runAsGroup" 101 -}} "runAsGroup" 101
"seccompProfile" (dict "type" "RuntimeDefault") -}}
{{- include "cyberchef.defaultedDict" (dict "defaults" $defaults "given" $given "path" "cyberchef.securityContext.pod") -}} {{- include "cyberchef.defaultedDict" (dict "defaults" $defaults "given" $given "path" "cyberchef.securityContext.pod") -}}
{{- end -}} {{- end -}}
+9
View File
@@ -16,6 +16,15 @@ cyberchef:
runAsNonRoot: true runAsNonRoot: true
runAsUser: 101 runAsUser: 101
runAsGroup: 101 runAsGroup: 101
# RuntimeDefault applies the container runtime's default seccomp filter,
# which blocks the syscalls a normal workload never makes. It sits in the
# pod context on purpose: from here it covers every container in the pod
# including init containers, while a container-level seccompProfile would
# have to be repeated for each one (and silently missed on the next one
# added). A container that genuinely needs a different filter can still
# override it under securityContext.container, which wins over this value.
seccompProfile:
type: RuntimeDefault
container: container:
allowPrivilegeEscalation: false allowPrivilegeEscalation: false
readOnlyRootFilesystem: true readOnlyRootFilesystem: true