Rehearse authorization recovery
Authorization recovery is under qualification for the next Enterprise minor release. The commands below describe that development workflow and are unavailable in Enterprise 0.7. Publication of this guide is not a claim that both providers have passed qualification.
Recover data and schemas first, then release application permissions through an explicitly reviewed plan. Use an isolated destination with existing test identities and independently provisioned bootstrap administration.
Prepare the destination
Record the source and destination provider, organization, environment and cluster identifiers. Map every selected principal explicitly, including principals whose names stay the same. Prepare exact-name or prefix mappings for topics, consumer groups, transactional IDs, subjects and component resources. Preserve pattern types and host restrictions.
Keep bootstrap credentials outside the captured permissions. The product does not create accounts or recover credentials. Platform RBAC, Cloud IAM and Kafka ACLs keep their native semantics; the planner does not translate one into another or substitute broader permissions for unsupported roles.
Use separate identities for bootstrap, recovery and application probes. Seed a destination-only sentinel assignment so the rehearsal can prove that additive recovery preserves it.
Capture and review
With the development release and an enterprise.authorization configuration:
kafka-backup authorization backup --config authorization.yaml \
--out snapshot.json --format json
kafka-backup authorization plan --config authorization.yaml \
--snapshot snapshot.json --out plan.json --format json
Keep snapshots and reports access controlled: they contain identity and resource inventories. A usable snapshot must be complete and pass checksum validation. Capture failures remain inspectable but cannot be restored. Legacy RBAC exports require a fresh capture.
Review create, already_present, target_only and blocked decisions. Resolve every blocked entry before applying. Administrator bindings require explicit selection and allow_privileged_bindings; enabling it is a decision to restore those named administrators.
The plan binds its checksum to the snapshot, mappings, destination and relevant destination state. Generate a new plan when those inputs change. Restore and independently verify the required schemas, records and consumer offsets before approving permission release.
Apply, resume and verify
Use the checksum from the reviewed plan output:
kafka-backup authorization apply --config authorization.yaml \
--plan plan.json --approve REVIEWED_CHECKSUM --format json
kafka-backup authorization verify --config authorization.yaml \
--plan plan.json --format json
Apply installs applicable DENY ACLs before grants, then orders selected role bindings by dependency. A failure stops recovery, preserves completed changes and records a partial result. Resume with the same approved plan after resolving the failure. Exact existing assignments become successful no-ops. Keep the recovery journal with the backup storage.
Repeat apply and require zero created assignments. Compare the sentinel and other destination-only assignments before and after recovery. Run planning and verification using a read-only identity to confirm that neither performs permission writes.
Use independent access probes
Assignment verification proves the selected assignments exist. Existing target permissions, identity-provider policy and provider-specific RBAC/ACL interactions can still change effective access.
Use a Kafka client independent of the backup binary and direct component clients:
| Probe | Required evidence |
|---|---|
| Produce and consume | Allowed topic succeeds; unauthorized topic receives an authorization error |
| Consumer groups | Mapped group or prefix succeeds; an unrelated group fails |
| Transactions | Mapped transactional ID succeeds; an unrelated ID fails |
| DENY, wildcard and host rules | Exact restored tuple and observed provider behaviour |
| Schema Registry | Mapped subject read succeeds; prohibited write or unrelated subject fails |
| Connect and ksqlDB | Selected operations succeed; unrelated resource operations fail |
| Additive recovery | Target-only sentinels remain unchanged |
| Repeat and interruption | Second apply creates zero assignments; committed interrupted writes reconcile on resume |
| Source outage | Recovery and probes succeed while source services are actually unavailable |
Record exact client versions, image digests, binary hashes, assignment counts and probe results. Credential removal from a configuration alone is not evidence of a source outage. A dependency-download failure, unavailable evaluation licence or unavailable security extension is a failed prerequisite, not a passed test.
Clean up the rehearsal
Delete only the fixture resources identified by the run manifest. For Cloud, include both environments, clusters, fixture identities, API keys and temporary administrative bindings. Re-enumerate with independently authorized credentials and verify those identifiers are absent; an HTTP 403 alone does not establish deletion.
Revoke temporary bootstrap credentials last. Retain redacted reports and remove credential-bearing Terraform state, downloaded keys, generated configurations and private logs. For local Compose rehearsals, remove only the dedicated project's containers, networks and volumes. Preserve unrelated development stacks.