Kubernetes Namespace Protection Under Restricted RBAC
A retail company runs three Tanzu Kubernetes Grid clusters. PPDM is deployed in the management cluster and must protect 40 namespaces across the clusters. Platform security enforces RBAC: the PPDM service account may list namespaces and create snapshots, but cannot create cluster-scoped resources. The container storage interface supports snapshots, but two clusters use different VolumeSnapshotClasses. Egress from workload clusters is denied by default; only TCP 443 to the PPDM VIP and TCP 443 to the DD management interface are open. After registration, one cluster shows no namespaces, and a test backup of a 200 GB namespace fails at 40% with a snapshot timeout. The team wants to know whether PPDM can work within those permissions, what to validate first, and how to design policies for the two storage classes.
1. Assess whether PPDM can operate within the stated RBAC restrictions.
Read the worked answer
It can likely work for namespace-scoped discovery and snapshot requests, but only if the snapshot controller, not PPDM, creates the cluster-scoped VolumeSnapshotContent objects. Validate the exact permissions against the support matrix and test with kubectl auth can-i for namespaces, PVCs, pods, VolumeSnapshots, and snapshot classes. A practical design uses a dedicated kubeconfig with a narrowly scoped ClusterRole for get/list/watch on namespaces and snapshot resources, plus namespace-scoped create/delete for snapshots. Do not grant cluster-admin. If PPDM insists on creating a namespace, CRD, or other cluster-scoped object, that is a design blocker; pre-create the namespace and pre-install the CSI snapshot controller so PPDM only consumes them. Document the split of responsibilities before registration.
2. Diagnose why one cluster shows no namespaces and why the 200 GB backup times out at 40%.
Read the worked answer
Treat these as separate faults. For missing namespaces, check kubeconfig context, API server certificate SAN, token expiry, PPDM-to-API TCP 443, and whether the service account can list namespaces and PVCs. Compare RBAC bindings and network policy on the failing cluster against a working one. For the 40% timeout, discovery is not the issue; snapshot creation is. Inspect VolumeSnapshot status, CSI provisioner logs, storage latency, and whether the VolumeSnapshotClass is supported. The 200 GB size may exceed snapshot timeout or datastore capability. Collect PPDM job logs, kubectl get events, and CSI controller logs. If the snapshot controller is unhealthy, PPDM cannot compensate with RBAC changes.
3. Design the protection policy split for two VolumeSnapshotClasses and the large namespace.
Read the worked answer
Create separate policies per VolumeSnapshotClass because the snapshot class is a policy-level setting; do not mix classes and assume fallback. Group namespaces by storage class and RPO. For the 200 GB namespace, validate snapshot completion time and change rate before setting a schedule; if timeouts persist, exclude large ephemeral volumes or use an application-consistent method if supported. Set retention by business tier, not by cluster. Restore-test into a different namespace to avoid overwriting production. Place a cProxy local to each workload cluster and size it for concurrent snapshots. Keep the policy count manageable, but do not merge classes just to reduce policy count.