Issue
When migrating applications from one OpenShift cluster to another using crane, the export phase captures runtime security context values that are cluster-specific and cause SCC (Security Context Constraints) validation failures on the target cluster.
These issues occur regardless of whether export/apply is done as cluster-admin or non-admin, because the problem is with the exported content itself—crane exports runtime state instead of declarative intent.
Description
When crane exports a running pod from OpenShift, it captures the actual running security context that was injected by the SCC admission controller:
Source cluster - Exported Pod:
spec:
securityContext:
fsGroup: 1000840000
seLinuxOptions:
level: s0:c29,c14
containers:
- name: app-pod
securityContext:
runAsUser: 1000840000
seLinuxOptions:
level: s0:c29,c14These values are cluster-specific and based on the source namespace's UID range:
Source namespace:
apiVersion: v1
kind: Namespace
metadata:
name: my-app
annotations:
openshift.io/sa.scc.uid-range: "1000840000/10000"
openshift.io/sa.scc.mcs: "s0:c29,c14"When applying this pod to a target cluster with a different UID range, SCC validation fails:
Error from server (Forbidden): error when creating "pod.yaml":
pods "app-pod" is forbidden: unable to validate against any security context constraint: [
provider restricted-v2: .spec.securityContext.fsGroup: Invalid value: []int64{1000840000}:
1000840000 is not an allowed group,
provider restricted-v2: .spec.securityContext.seLinuxOptions.level: Invalid value: "s0:c29,c14":
must be s0:c29,c9,
provider restricted-v2: .containers[0].runAsUser: Invalid value: 1000840000:
must be in the ranges: [1000830000, 1000839999]
]
Target namespace has different values:
metadata:
annotations:
openshift.io/sa.scc.uid-range: "1000830000/10000" # DIFFERENT!
openshift.io/sa.scc.mcs: "s0:c29,c9" # DIFFERENT!
Issue
When migrating applications from one OpenShift cluster to another using crane, the export phase captures runtime security context values that are cluster-specific and cause SCC (Security Context Constraints) validation failures on the target cluster.
These issues occur regardless of whether export/apply is done as cluster-admin or non-admin, because the problem is with the exported content itself—crane exports runtime state instead of declarative intent.
Description
When crane exports a running pod from OpenShift, it captures the actual running security context that was injected by the SCC admission controller:
Source cluster - Exported Pod:
These values are cluster-specific and based on the source namespace's UID range:
Source namespace:
When applying this pod to a target cluster with a different UID range, SCC validation fails:
Target namespace has different values: