Merge pull request #127 from jk-cluster/feat/cyberchef-seccomp-runtimedefault

cyberchef: seccompProfile RuntimeDefault in the pod context
This commit is contained in:
jklein authored and GitHub committed 2026-08-23 21:06:07 +00:00
commit a039b873c9
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