-
Bug
-
Resolution: Won't Do
-
Major
-
None
-
4.10
-
None
-
Important
-
No
-
Rejected
-
False
-
Description of problem:
After creating a new custom SCC with high priority, the openshift-controller-manager-operator pod is in crashloopbackoff using this new custom SCC. A similar issue was happening with the OpenShift Logging Elasticsearch pods when introduced a custom SCC, the Elasticsearch pods were using it since it was having higher priority. It it's https://issues.redhat.com/browse/LOG-4208.
Version-Release number of selected component (if applicable):
4.10
How reproducible:
Always
Steps to Reproduce:
1.Create a custom SCC restricted-uid-scc.yaml. Available in [1] $ oc create -f restricted-uid-scc.yaml securitycontextconstraints.security.openshift.io/restricted-uid created 2. Restart the openshift-controller-manager-operator pod $ oc delete pod -l app=openshift-controller-manager-operator -n openshift-controller-manager-operator 3. Verify the openshift-controller-manager-operator is in crashloopbackoff $ oc get pods -n openshift-controller-manager-operator NAME READY STATUS RESTARTS AGE openshift-controller-manager-operator-7684f9f68-wnvx4 0/1 Error 1 (3s ago) 5s 4. Confirm the permission denied error observed below $ oc logs openshift-controller-manager-operator-7684f9f68-wnvx4 F0615 06:44:31.193174 1 cmd.go:138] open /var/run/configmaps/config/config.yaml: permission denied
Actual results:
The openshift-controller-manager-operator pod is in crashloopbackoff since it's taking the SCC with higher priority and it doesn't allow to access to `/var/run/configmaps/config/config.yaml`
Expected results:
The openshift-controller-manager-operator pod even when a custom SCC is introduced, it uses the expected default SCC and not one different custom
Additional info:
Similar issue for the OCP Logging Elasticsearch pods: https://issues.redhat.com/browse/LOG-4208
[1]
restricted-uid-scc.yaml" :
kind: SecurityContextConstraints
apiVersion: v1
metadata:
name: restricted-uid
runAsUser:
type: MustRunAsRange
uidRangeMax: 65535
uidRangeMin: 1
seLinuxContext:
type: RunAsAny
fsGroup:
type: RunAsAny
ranges:
- max: 65535
min: 1
supplementalGroups:
type: RunAsAny
ranges:
- max: 65535
min: 1
users: []
groups:
- grp-ns001b004550-edit
- grp-ns001b004551-edit
requiredDropCapabilities:
- KILL
- MKNOD
priority: 50
readOnlyRootFilesystem: true
allowHostDirVolumePlugin: false
allowHostIPC: false
allowHostNetwork: false
allowHostPID: false
allowHostPorts: false
allowPrivilegeEscalation: false
allowPrivilegedContainer: false
allowedCapabilities: []
apiVersion: security.openshift.io/v1
defaultAddCapabilities: []
volumes:
- configMap
- downwardAPI
- emptyDir
- persistentVolumeClaim
- projected
- secret
- is cloned by
-
-
- Closed
-
- relates to
-
-
- Closed
-
- links to
[OCPBUGS-15245] custom SCC breaks openshift-controller-manager-operator pod
Ben Parees
added a comment - sorry, that was what i was looking for. thanks. i'm afraid it's not immediately apparent to me why that alternate SCC changes the filesystem permissions or uid such that things don't work though.
Ben Parees
added a comment - sorry, that was what i was looking for. thanks. i'm afraid it's not immediately apparent to me why that alternate SCC changes the filesystem permissions or uid such that things don't work though. 
Oscar Casal Sanchez
added a comment - Hello bparees@redhat.com ,
The SCC is provided in the bug description where you can read [1]restricted-uid-scc.yaml or are you looking for something different?
Best regards
Oscar Casal Sanchez
added a comment - Hello bparees@redhat.com ,
The SCC is provided in the bug description where you can read [1] restricted-uid-scc.yaml or are you looking for something different?
Best regards Ben Parees
added a comment - Can you provide the definition of the custom SCC? We need to better understand:
1) why it's matching that SCC (to see if it's even possible to force the match to the restricted SCC instead)
2) why matching that SCC causes the mounted configmap permissions to be wrong (so we can potentially fix the pod to tolerate the alternate permissions)
But the answer of "just specify the security context more fully" doesn't work here because the pod wants to run as a range/assigned uid. There is no way for a pod to specify "only match me to an SCC that runs as range user" currently (there are some enhancements coming that will enable that flow).
Ben Parees
added a comment - Can you provide the definition of the custom SCC? We need to better understand:
1) why it's matching that SCC (to see if it's even possible to force the match to the restricted SCC instead)
2) why matching that SCC causes the mounted configmap permissions to be wrong (so we can potentially fix the pod to tolerate the alternate permissions)
But the answer of "just specify the security context more fully" doesn't work here because the pod wants to run as a range/assigned uid. There is no way for a pod to specify "only match me to an SCC that runs as range user" currently (there are some enhancements coming that will enable that flow). Diff your expected SCC vs this one and find which security aspect makes your workload break. Fix that by properly specifying your securityContext (if possible).
4.10 is EOL