Loading...
Loading...
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.
Identify the SCC used for this application in the appropriate Service Account and find the serviceaccount that is being used by the workloads.Example:
Click on a version to see all relevant bugs
Veeam Integration
Learn more about where this data comes from
BugZero Plan
Streamline upgrades with automated vendor bug scrubs
BugZero Prevent
Wish you caught this bug sooner? Get proactive today.