fix(paperless-eval): admit the namespace to OpenBao, restore the capabilities

The instance deployed and got nowhere. Both ExternalSecrets reported "could not get secret data from provider", so hetzner-s3-creds never existed, and the CNPG restore job died on it: can't get credentials for cluster pprleval-pg: while getting secret hetzner-s3-creds: secrets "hetzner-s3-creds" not found The openbao ClusterSecretStore carries an explicit namespace allowlist in spec.conditions, and paperless-eval was not on it. Nothing in the manifests shows that — it is cluster state, which is why neither the review nor `kubectl kustomize` caught it, and why the failure only appeared on deploy. The paperless container also gets production's securityContext back. The review was right about this and it was dismissed as being about the scanner and mail bridge sidecars, which those manifests were only cited as evidence for the pattern. The paperless-ngx entrypoint starts as root, chowns the mounted volumes and drops to uid 1000 via setgid/setuid, so drop: ["ALL"] with nothing added fails that sequence with EPERM. It would have bitten as soon as the restore succeeded and the pod actually tried to start — and harder here than in production, whose volumes were chowned once and kept it, while these are fresh on every rebuild. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-09-03 08:53:04 +02:00
2 changed files with 12 additions and 1 deletions
@@ -165,10 +165,20 @@ spec:
              memory: 512Mi
            limits:
              memory: 2Gi
+          # Production's context verbatim, and it has to be: the paperless-ngx
+          # entrypoint starts as root, chowns the mounted data/media/consume
+          # volumes and then drops to uid 1000 via setgid/setuid. Without these
+          # the same image fails that sequence with EPERM.
+          #
+          # It bites harder here than in production, where those volumes were
+          # chowned once years ago and keep their ownership. These are fresh on
+          # every rebuild, so the chown is not a no-op.
          securityContext:
-            allowPrivilegeEscalation: false
+            runAsNonRoot: false
+            allowPrivilegeEscalation: true
            capabilities:
              drop: ["ALL"]
+              add: ["CHOWN", "DAC_OVERRIDE", "FOWNER", "SETGID", "SETUID"]
      volumes:
        - name: data
          persistentVolumeClaim:
@@ -27,6 +27,7 @@ spec:
        - ingress
        - monitoring
        - paperless
+        - paperless-eval # same apps/paperless key plus the shared barman S3 creds
        - trmnl
        - velero
        - woodpecker # wp-pg barman creds; woodpecker moving out of `apps` (#433)