gotenberg: 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.

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.

Gotenberg is the chart where a syscall filter was most likely to bite: it
drives headless Chromium and LibreOffice, and browser sandboxes are the
classic casualty of a restrictive seccomp profile. Verified in k3d that
both engines still work under the filter - Chromium HTML->PDF and
LibreOffice document->PDF both return real, non-empty PDFs, and the
kernel reports Seccomp: 2 (filter mode) inside the container.

Major bump: runtime behavior changes.

Refs #84

gotenberg/Chart.yaml

@@ -5,7 +5,7 @@ icon: https://gotenberg.dev/img/logo.png
 
 type: application
 
-version: 7.0.0+up8.36.0
+version: 8.0.0+up8.36.0
 appVersion: "8.36.0"
 
 maintainers:

gotenberg/templates/_helpers.tpl

@@ -214,7 +214,8 @@ rebuilt default probe needs no further context.
 {{- $defaults := dict
       "runAsNonRoot" true
       "runAsUser" 1001
-      "runAsGroup" 1001 -}}
+      "runAsGroup" 1001
+      "seccompProfile" (dict "type" "RuntimeDefault") -}}
 {{- include "gotenberg.defaultedDict" (dict "defaults" $defaults "given" $given "path" "gotenberg.securityContext.pod") -}}
 {{- end -}}
 

gotenberg/values.yaml

@@ -16,6 +16,20 @@ gotenberg:
       runAsNonRoot: true
       runAsUser: 1001
       runAsGroup: 1001
+      # 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.
+      #
+      # Verified against both conversion engines, because a browser sandbox is
+      # the classic case where a syscall filter bites: Chromium HTML->PDF and
+      # LibreOffice document->PDF both still return real PDFs under the filter,
+      # and /health reports chromium and libreoffice as "up".
+      seccompProfile:
+        type: RuntimeDefault
     container:
       allowPrivilegeEscalation: false
       readOnlyRootFilesystem: true