docs(backups): stop presenting admin-only demo steps as tenant work

The kafka and nats walkthroughs put steps 03, 04, 06, 07 and cleanup
under the tenant persona, and the scenario docs and helper comments
had the tenant create the backup Secret. The scripts read, create and
delete Secrets, wait on HelmReleases, COSI objects and operator
resources, exec into a CLI Pod, read Pod logs, and delete the Backup
and the cluster-scoped BackupClass and strategy. The tenant roles grant
none of that, so a tenant following the docs hit Forbidden at the
first read. The tables now say admin and name the part a tenant admin can
do on its own, and the scenario docs say the same.

Assisted-by: LLM
Signed-off-by: Aleksei Sviridkin <f@lex.la>

examples/backups/kafka/00-helpers.sh

@@ -309,7 +309,7 @@ topic_replication_factor() {
 # Create the "<app>-backup-s3" Secret the Job strategy Pod consumes, from the
 # bucket coordinates cached by 03-create-bucket.sh. The generic Job strategy -
 # unlike the app-specific drivers - has no chart support to emit this Secret,
-# so the tenant provides it. Called for the source app (step 04) and the
+# so the demo provides it. Called for the source app (step 04) and the
 # restore target (step 07). The S3 endpoint's CA, when 03-create-bucket.sh
 # cached one, rides along as ca.crt: the strategy Pod mounts that key and
 # verifies the endpoint against it instead of disabling verification.

examples/backups/kafka/01-create-strategy.sh

@@ -82,7 +82,7 @@ spec:
               value: "{{ .Release.Namespace }}"
             - name: MODE
               value: "{{ .Mode }}"
-            # S3 coordinates from the tenant-provided <release>-backup-s3 Secret
+            # S3 coordinates from the demo-provided <release>-backup-s3 Secret
             # (created by create_s3_secret in 00-helpers.sh from the Bucket).
             - name: AWS_ACCESS_KEY_ID
               valueFrom:
@@ -169,7 +169,7 @@ spec:
 
               # curl --aws-sigv4 signs the request (SigV4) so no separate S3
               # client image is needed. The certificate is verified: against the
-              # CA projected from the Secret when the tenant supplied one, else
+              # CA projected from the Secret when it carries one, else
               # against the image's trust store. \${CA_OPT} and \${CONNECT_TO}
               # are deliberately unquoted so an empty value expands to no
               # argument.

examples/backups/kafka/03-create-bucket.sh

@@ -1,7 +1,7 @@
 #!/bin/bash
 # Step 03: Provision an in-cluster Bucket and cache its S3 coordinates. The
 # generic Job strategy has no chart support to emit a backup Secret, so the
-# tenant materialises the "<app>-backup-s3" Secret itself. This step only
+# demo materialises the "<app>-backup-s3" Secret itself. This step only
 # caches the coordinates; create_s3_secret (00-helpers.sh) turns them into
 # per-app Secrets in steps 04 and 07.
 set -euo pipefail

examples/backups/kafka/90-scenario-admin-prepare.md

@@ -1,9 +1,6 @@
 # Scenario: Cluster admin prepares Kafka topic-data backups
 
-A cluster administrator performs the cluster-level preparation once. Tenants
-will then be able to back up and restore the topic data of their Kafka
-applications by referencing the BackupClass created here, with no further
-admin action.
+A cluster administrator performs the cluster-level preparation once. Tenant admins can then back up and restore the topic data of their Kafka applications with a `BackupJob` or `RestoreJob` that references the BackupClass created here. The demo scripts around those jobs still need admin access, because they create Secrets and work through a CLI Pod; the README's step table says which part of each step a tenant admin can do.
 
 ## Prerequisites
 
@@ -11,9 +8,7 @@ admin action.
   backupstrategy-controller installed.
 - `kubectl` access with permissions to create cluster-scoped
   `Job.strategy.backups.cozystack.io` and `BackupClass.backups.cozystack.io`.
-- Reachable S3-compatible storage. The demo uses the in-cluster `Bucket` app
-  (step 03); the tenant turns its coordinates and the endpoint's CA into a
-  `<app>-backup-s3` Secret that the strategy Pod reads (step 04 / 07).
+- Reachable S3-compatible storage. The demo uses the in-cluster `Bucket` app (step 03), and steps 04 and 07 turn its coordinates and the endpoint's CA into a `<app>-backup-s3` Secret that the strategy Pod reads. Creating that Secret needs admin access, since no tenant role grants `create` on `secrets`.
 
 ## Steps
 

examples/backups/kafka/91-scenario-user-backup.md

@@ -2,14 +2,13 @@
 
 This scenario assumes the admin steps (`01-...`, `02-...`) have already run.
 
+The user's own action here, at the tenant admin level, is the `BackupJob` in step 05, plus creating the `Bucket` and the `Kafka`. Steps 03 and 04 as scripted need admin access: they read and create Secrets, wait on HelmReleases and operator resources, and seed the topic through a CLI Pod, which no tenant role allows. The README's step table has the details.
+
 ## Prerequisites
 
 - Tenant namespace (default: `tenant-root`, the tenant whose Pods can reach
   the in-cluster seaweedfs; see the README).
-- A Cozystack `Bucket` (step 03) and the `<app>-backup-s3` Secret derived from
-  it (step 04). The generic `Job` strategy has no chart support to emit this
-  Secret, so the tenant creates it from the bucket's `BucketInfo` plus the S3
-  endpoint's CA (see `create_s3_secret` in `00-helpers.sh`).
+- A Cozystack `Bucket` (step 03) and the `<app>-backup-s3` Secret derived from it (step 04). The generic `Job` strategy has no chart support to emit this Secret, so step 04 creates it from the bucket's `BucketInfo` plus the S3 endpoint's CA (see `create_s3_secret` in `00-helpers.sh`). Creating it needs admin access.
 - A `Kafka` application with at least one plain (neither compacted nor
   transactional) topic holding data.
 

examples/backups/kafka/92-scenario-user-restore.md

@@ -4,6 +4,8 @@ Two restore variants are supported. Both append: the strategy recreates a
 topic only if it is absent and then replays every record, so it refuses a
 target topic that already holds data.
 
+The user's own action in both variants, at the tenant admin level, is the `RestoreJob`, plus the second `Kafka` in variant B. The scripts as written need admin access: variant A deletes and checks the topic through a CLI Pod and reads the refused restore's Pod log, and variant B checks the topic the same way, creates the target's Secret and waits on its `HelmRelease` and Strimzi `Kafka`, none of which a tenant role allows. The README's step table has the details.
+
 ## A. In-place restore
 
 Restore back into the same Kafka application.

examples/backups/kafka/README.md

@@ -36,15 +36,15 @@ For a faithful, offset-preserving Kafka backup, prefer a volume-snapshot strateg
 | `00-helpers.sh` | Shared bash helpers, env defaults, and the kafka-CLI / S3-secret helpers; sourced by every step. | n/a |
 | `01-create-strategy.sh` | Creates the cluster-scoped `Job` strategy (the Kafka backup/restore `PodTemplateSpec`). | admin |
 | `02-create-backupclass.sh` | Maps `apps.cozystack.io/Kafka` to that strategy, with the `topics` parameter (and the optional `replicationFactor` override). | admin |
-| `03-create-bucket.sh` | Provisions a `Bucket` and caches its S3 coordinates plus the endpoint's CA into `.bucket-info.env` (chmod 600; raw access keys). `cleanup.sh` removes this file. | tenant, **plus admin** for the CA copy: it reads a Secret in `tenant-root`, which a tenant persona is not granted (see the TLS bullet above) |
-| `04-create-kafka.sh` | Provisions a two-broker `Kafka`, creates the `<app>-backup-s3` Secret, seeds a topic (replication factor 2) with sentinel messages. | tenant |
+| `03-create-bucket.sh` | Provisions a `Bucket` and caches its S3 coordinates plus the endpoint's CA into `.bucket-info.env` (chmod 600; raw access keys). `cleanup.sh` removes this file. | **admin**. A tenant admin can create the `Bucket` itself, but the script also waits on its `HelmRelease` and COSI objects, reads the `bucket-<name>-backup` Secret, and copies the CA from a Secret in `tenant-root` (see the TLS bullet above); no tenant role grants access to `helmreleases` or `objectstorage.k8s.io`, or `get` on those Secrets |
+| `04-create-kafka.sh` | Provisions a two-broker `Kafka`, creates the `<app>-backup-s3` Secret, seeds a topic (replication factor 2) with sentinel messages. | **admin**. A tenant admin can create the `Kafka` itself, but the script also waits on its `HelmRelease` and Strimzi `Kafka`, creates the Secret, and seeds the topic through a CLI Pod it execs into; no tenant role grants access to `helmreleases` or `kafkas.kafka.strimzi.io`, `create` on `secrets` or `pods`, or `pods/exec` |
 | `05-create-backupjob.sh` | Submits a `BackupJob`, waits for Succeeded and caches the resolved `Backup` name into `.backup-name.env`. | tenant |
-| `06-restore-in-place.sh` | Deletes the topic and restores it into the same instance via `RestoreJob`, then submits a second `RestoreJob` that must be refused because the topic is no longer empty. | tenant |
-| `07-restore-to-copy.sh` | Provisions a second two-broker `Kafka` and restores into it via `RestoreJob.spec.targetApplicationRef`. | tenant |
-| `cleanup.sh` | Removes everything created by the demo. | admin or tenant |
+| `06-restore-in-place.sh` | Deletes the topic and restores it into the same instance via `RestoreJob`, then submits a second `RestoreJob` that must be refused because the topic is no longer empty. | **admin**. A tenant admin can submit the two `RestoreJob`s, but the script deletes and checks the topic through the CLI Pod and reads the refusal from the restore Pod's log; no tenant role grants `create` on `pods` or `pods/exec`, or `get` on `pods/log` |
+| `07-restore-to-copy.sh` | Provisions a second two-broker `Kafka` and restores into it via `RestoreJob.spec.targetApplicationRef`. | **admin**, for the same reasons as step 04. The tenant admin's part is the second `Kafka` and the `RestoreJob` |
+| `cleanup.sh` | Removes everything created by the demo. | **admin**: it deletes Secrets, the `Backup`, and the cluster-scoped `BackupClass` and strategy, and no tenant role grants `delete` on any of them |
 | `run-all.sh` | Convenience runner that executes 01..07 in order. | demo |
 
-The scenario walk-throughs `90-scenario-admin-prepare.md`, `91-scenario-user-backup.md` and `92-scenario-user-restore.md` describe the same steps from the admin's and the tenant's side.
+The scenario walk-throughs `90-scenario-admin-prepare.md`, `91-scenario-user-backup.md` and `92-scenario-user-restore.md` describe the same steps from the admin's and the tenant's side, and say which parts of the tenant's side need admin access.
 
 ## Running
 

examples/backups/nats/00-helpers.sh

@@ -131,7 +131,7 @@ stream_message_count() {
 # Create the "<app>-backup-s3" Secret the Job strategy Pod consumes, from the
 # bucket coordinates cached by 03-create-bucket.sh. The generic Job strategy -
 # unlike the app-specific drivers - has no chart support to emit this Secret,
-# so the tenant provides it. Called for the source app (step 04) and the
+# so the demo provides it. Called for the source app (step 04) and the
 # restore target (step 07).
 create_s3_secret() {
     local app="$1"

examples/backups/nats/01-create-strategy.sh

@@ -64,7 +64,7 @@ spec:
               value: "{{ if .Backup }}{{ .Backup.ApplicationRef.Name }}{{ end }}"
             - name: MODE
               value: "{{ .Mode }}"
-            # S3 coordinates from the tenant-provided <release>-backup-s3 Secret
+            # S3 coordinates from the demo-provided <release>-backup-s3 Secret
             # (created by create_s3_secret in 00-helpers.sh from the Bucket).
             - name: AWS_ACCESS_KEY_ID
               valueFrom:

examples/backups/nats/03-create-bucket.sh

@@ -1,7 +1,7 @@
 #!/bin/bash
 # Step 03: Provision an in-cluster Bucket and cache its S3 coordinates. Unlike
 # the ClickHouse demo - where the chart emits the backup Secret from
-# spec.backup.* - the generic Job strategy has no chart support, so the tenant
+# spec.backup.* - the generic Job strategy has no chart support, so the demo
 # materialises the "<app>-backup-s3" Secret itself. This step only caches the
 # coordinates; create_s3_secret (00-helpers.sh) turns them into per-app Secrets
 # in steps 04 and 07.

examples/backups/nats/90-scenario-admin-prepare.md

@@ -1,8 +1,6 @@
 # Scenario: Cluster admin prepares NATS backups
 
-A cluster administrator performs the cluster-level preparation once. Tenants
-will then be able to back up and restore their NATS applications by referencing
-the BackupClass created here, with no further admin action.
+A cluster administrator performs the cluster-level preparation once. Tenant admins can then back up and restore their NATS applications with a `BackupJob` or `RestoreJob` that references the BackupClass created here. The demo scripts around those jobs still need admin access, because they create Secrets and work through a CLI Pod; the README's step table says which part of each step a tenant admin can do.
 
 ## Prerequisites
 
@@ -10,9 +8,7 @@ the BackupClass created here, with no further admin action.
   backupstrategy-controller installed.
 - `kubectl` access with permissions to create cluster-scoped
   `Job.strategy.backups.cozystack.io` and `BackupClass.backups.cozystack.io`.
-- Reachable S3-compatible storage. The demo uses the in-cluster `Bucket` app
-  (step 03); the tenant turns its coordinates into a `<app>-backup-s3` Secret
-  that the strategy Pod reads (step 04 / 07).
+- Reachable S3-compatible storage. The demo uses the in-cluster `Bucket` app (step 03), and steps 04 and 07 turn its coordinates into a `<app>-backup-s3` Secret that the strategy Pod reads. Creating that Secret needs admin access, since no tenant role grants `create` on `secrets`.
 
 ## Steps
 

examples/backups/nats/91-scenario-user-backup.md

@@ -2,13 +2,12 @@
 
 This scenario assumes the admin steps (`01-...`, `02-...`) have already run.
 
+The user's own action here, at the tenant admin level, is the `BackupJob` in step 05, plus creating the `Bucket` and the `NATS`. Steps 03 and 04 as scripted need admin access: they read and create Secrets, wait on HelmReleases and the `StatefulSet`, and seed the stream through a CLI Pod, which no tenant role allows. The README's step table has the details.
+
 ## Prerequisites
 
 - Tenant namespace (default: `tenant-test`).
-- A Cozystack `Bucket` (step 03) and the `<app>-backup-s3` Secret derived from
-  it (step 04). The generic `Job` strategy has no chart support to emit this
-  Secret, so the tenant creates it from the bucket's `BucketInfo` (see
-  `create_s3_secret` in `00-helpers.sh`).
+- A Cozystack `Bucket` (step 03) and the `<app>-backup-s3` Secret derived from it (step 04). The generic `Job` strategy has no chart support to emit this Secret, so step 04 creates it from the bucket's `BucketInfo` (see `create_s3_secret` in `00-helpers.sh`). Creating it needs admin access.
 - A `NATS` application with JetStream enabled and a stream holding data.
 
 ## Steps

examples/backups/nats/92-scenario-user-restore.md

@@ -2,6 +2,8 @@
 
 Two restore variants are supported.
 
+The user's own action in both variants, at the tenant admin level, is the `RestoreJob`, plus the second `NATS` in variant B. The scripts as written need admin access: variant A deletes and checks the stream through a CLI Pod, and variant B checks the stream the same way, creates the target's Secret and waits on its `HelmRelease` and `StatefulSet`, none of which a tenant role allows. The README's step table has the details.
+
 ## A. In-place restore
 
 Restore back into the same NATS application.

examples/backups/nats/README.md

@@ -30,12 +30,12 @@ driver, with tools you already have.
 | `00-helpers.sh` | Shared bash helpers, env defaults, and the `nats`/S3-secret helpers; sourced by every step. | n/a |
 | `01-create-strategy.sh` | Creates the cluster-scoped `Job` strategy (the nats-box `PodTemplateSpec`). | admin |
 | `02-create-backupclass.sh` | Maps `apps.cozystack.io/NATS` to that strategy, with `stream`/`natsUser` parameters. | admin |
-| `03-create-bucket.sh` | Provisions a `Bucket` and caches its S3 coordinates into `.bucket-info.env` (chmod 600; raw access keys). `cleanup.sh` removes this file. | tenant |
-| `04-create-nats.sh` | Provisions a `NATS` instance, creates the `<app>-backup-s3` Secret, seeds a JetStream stream with sentinel messages. | tenant |
+| `03-create-bucket.sh` | Provisions a `Bucket` and caches its S3 coordinates into `.bucket-info.env` (chmod 600; raw access keys). `cleanup.sh` removes this file. | **admin**. A tenant admin can create the `Bucket` itself, but the script also waits on its `HelmRelease` and COSI objects and reads the `bucket-<name>-backup` Secret; no tenant role grants access to `helmreleases` or `objectstorage.k8s.io`, or `get` on that Secret |
+| `04-create-nats.sh` | Provisions a `NATS` instance, creates the `<app>-backup-s3` Secret, seeds a JetStream stream with sentinel messages. | **admin**. A tenant admin can create the `NATS` itself, but the script also waits on its `HelmRelease` and `StatefulSet`, creates the Secret, and seeds the stream through a CLI Pod it execs into; no tenant role grants access to `helmreleases` or `statefulsets`, `create` on `secrets` or `pods`, or `pods/exec` |
 | `05-create-backupjob.sh` | Submits a `BackupJob` and waits for Succeeded. | tenant |
-| `06-restore-in-place.sh` | Deletes the stream and restores it into the same instance via `RestoreJob`. | tenant |
-| `07-restore-to-copy.sh` | Provisions a second `NATS` and restores into it via `RestoreJob.spec.targetApplicationRef`. | tenant |
-| `cleanup.sh` | Removes everything created by the demo. | admin or tenant |
+| `06-restore-in-place.sh` | Deletes the stream and restores it into the same instance via `RestoreJob`. | **admin**. A tenant admin can submit the `RestoreJob`, but the script deletes and checks the stream through the CLI Pod; no tenant role grants `create` on `pods` or `pods/exec` |
+| `07-restore-to-copy.sh` | Provisions a second `NATS` and restores into it via `RestoreJob.spec.targetApplicationRef`. | **admin**, for the same reasons as step 04. The tenant admin's part is the second `NATS` and the `RestoreJob` |
+| `cleanup.sh` | Removes everything created by the demo. | **admin**: it deletes Secrets, the `Backup`, and the cluster-scoped `BackupClass` and strategy, and no tenant role grants `delete` on any of them |
 | `run-all.sh` | Convenience runner that executes 01..07 in order. | demo |
 | `90-scenario-admin-prepare.md` | Narrative for the admin preparation steps. | docs |
 | `91-scenario-user-backup.md` | Narrative for the user backup flow. | docs |