Clone Job Fails Due to Security Context Constraints (SCC) Issue

Cloned-restore jobs time out and eventually fail because an application's security context provides permissions in the original application namespace. This results in the application's pod being in a non-running state.

Example:

Namespace = quay-enterprise 
SCC (during deployment) = anyuid
SA = default
Cloned namespace = quay-enterprise-restore

$ oc logs postgres-856bf449fb-p7r6t 
chmod: changing permissions of '/var/lib/pgsql/data/userdata': Operation not permitted 
$ oc get pods 
NAME                                        READY  STATUS           RESTARTS  AGE 
postgres-856bf449fb-p7r6t                   0/1    CrashLoopBackOff 5         3m40s 
quay-enterprise-app-dff657895-nvh8n         1/1    Running          1         3m40s 
quay-enterprise-config-app-74f5cd5558-94w6d 1/1    Running          0         3m40s 
quay-enterprise-redis-65fb758bff-l2c8l      1/1    Running          0         3m40s

Like RBAC (Role-Base Access Control) resources control user access, administrators can use Security Context Constraints (SCCs) to control pod permissions. Veeam Kasten for Kubernetes allows applications to be restored in-place (overwriting) or cloned-restore (to a different namespace) on the same cluster.

Generally, an SCC is added to a Service Account (SA) in the application namespace. Depending on how an application is configured with SCC permissions, cloned-restores may fail because application resources are returned to a new namespace.