fix(backups): restrict the kafka-metadata CLI Pod and correct demo personas - #4695

What this PR does

This fixes two problems in the Kafka and NATS backup demos under examples/backups/.

The Kafka metadata demo ran its CLI Pod without any securityContext, so a namespace that enforces the restricted Pod Security level would reject it. The Pod now gets the same restricted context as the CLI Pod in the topic-data demo: runAsNonRoot, the RuntimeDefault seccomp profile, no privilege escalation, all capabilities dropped. The new bats case reads the overrides passed to kubectl run and fails if any of those fields is missing or the patch is not sent as --override-type=json. It is red on main, and it goes red on each of seven single-field mutations of the patch while the other five cases stay green.

One known limit: runAsNonRoot needs an image that runs as a non-root user. The default Strimzi image runs as UID 1001 and is fine. If KAFKA_IMAGE is overridden with an image that runs as root, the kubelet refuses to start the container, and the helper fails only when its 5 minute kubectl wait times out.

The kafka and nats walkthroughs told a tenant to run scripts that the tenant roles forbid. Steps 03, 04, 06, 07 and cleanup.sh were in the tenant column, and the scenario docs and several script comments had the tenant create the backup Secret. Those rows now say admin and name the part a tenant admin can do on its own, and the scenario docs say the same. After this change the persona column in both tables matches the tenant roles. kafka-metadata has no persona table, so I didn't change anything there.

These are the tenant rules on pods and backup objects, plus one example of the per-app secret rules. Each app chart's dashboard Role allows get, list and watch on a few named Secrets and no other verb on secrets. Nothing aggregated into the tenant roles grants pods/exec, pods/log, helmreleases, objectstorage.k8s.io, statefulsets or kafkas.kafka.strimzi.io.

# packages/system/cozystack-basics/templates/clusterroles.yaml:100-112 (cozy:tenant:view:base, every tenant level)
- apiGroups:
  - ""
  resources:
  - pods
  - services
  - persistentvolumes
  - endpoints
  - events
  - resourcequotas
  verbs:
  - get
  - list
  - watch
# packages/system/cozystack-basics/templates/clusterroles.yaml:238-246 (cozy:tenant:admin:base)
- apiGroups: [""]
  resources:
  - pods
  - services
  - persistentvolumes
  - endpoints
  - events
  verbs:
  - delete
# packages/system/backup-controller/templates/tenant-clusterroles.yaml:35-44 (cozy:backups:admin)
- apiGroups: ["backups.cozystack.io"]
  resources:
  - plans
  - backupjobs
  - restorejobs
  verbs:
  - create
  - update
  - patch
  - delete
# packages/apps/bucket/templates/dashboard-resourcemap.yaml:6-14 (bound at the tenant "use" level)
- apiGroups:
  - ""
  resources:
  - secrets
  resourceNames:
  {{- range $name, $user := .Values.users }}
  - {{ $.Release.Name }}-{{ $name }}-credentials
  {{- end }}
  verbs: ["get", "list", "watch"]

How each changed row runs into those rules:

Step 05 stays a tenant step. Its BackupJob comes from cozy:backups:admin, so in practice that means a tenant admin. The nats demo's CLI Pod has the same missing securityContext as the kafka-metadata one, and I left it for a separate issue.

Closes #4625

Closes #4636

Screenshots

Not a UI change.

Downstream repositories

• No downstream repository is affected by this change
• cozystack/website - follow-up:
• cozystack/terraform-provider-cozystack - follow-up:
• cozystack/ansible-cozystack - follow-up:
• cozystack/ccp - follow-up:
• cozystack/talm - follow-up:
• cozystack/cozyhr - follow-up:
• cozystack/cozy-proxy - follow-up:
• cozystack/cozystack-telemetry-server - follow-up:
• cozystack/external-apps-example - follow-up:
• cozystack/examples - follow-up:
• cozystack/community - follow-up:

Release note

fix(backups): the kafka-metadata backup demo now runs its CLI Pod with the restricted Pod Security context, and the kafka and nats backup demos now list steps 03, 04, 06, 07 and cleanup as admin steps, because they need Pod, exec, Secret and cluster-scoped permissions that tenant roles do not grant.

Summary by CodeRabbit

• Security
  • Kafka metadata backup CLI Pods are recreated with restricted security settings when they are not running or lack the required non-root configuration.
• Documentation
  • Kafka and NATS guides clarify which setup, restore, and cleanup steps require administrator access and which job actions tenants can perform.
  • Updated examples clarify that the demo provides required storage Secrets and certificates.