SCC using UserID, FsGroupID and supplemental group ID and the like SELinux label strategy, by checking whether the ID definition pod Pod restricted rights in the effective range. If the check fails, the Pod will fail to start. SCC policy value is set to RunAsAny represent pod has all the rights under the policy. Otherwise, only pod of SCC and SCC policies set match to pass certification.
SCC may give strategy allowed range of values (e.g. Must RunAsRange), if the policy is not specified value corresponds to the pod, the pod using the minimum project is located in a default.
A custom SCC follows:
OC $ GET Project default - O YAML ... the Metadata: Annotations: # provide default values when the SCC policy of non-RunAsAny openshift.io / when c1, c0 # SCC is not defined in the pod or SELinux provides: s0: sa.scc.mcs default openshift.io /sa.scc.supplemental-groups: 1000000000 / 10000 # allowed group ID ranges. It can support a plurality of ranges, separated by commas openshift.io /sa.scc.uid-range: 1000000000 / 10000 # range permissible user ID, supports only a single range of $ OC GET SCC SCC-My-Custom - O YAML ... fsGroup: type: MustRunAs #MustRunAs forcing group ID verification, and to provide a default Group container, this default group ID SCC 5000. If the SCC defined fields, use 1 billion default. Use RunAsAny not verify that the effective range (ID allow all Group) Ranges: - min: 5000 max: 6000 runAsUser is: type: MustRunAsRange #MustRybAsRange forced to verify user ID, and provides a default UID. This default UID SCC is 1000100000. If the SCC defined fields, use 1 billion default. Other similar to MustRunAsNonRoot and RunAsAny. ID can be used to define access target stored uidRangeMin: 1.0001 billion uidRangeMax: 1000100999 seLinuxContext: # of the type: # MustRunAs set MustRunAs, SCC SELinux option defines the container use to create, or use the default MCS project. RunAsAny SELinux represents not check SELinuxOptions: User: <SELinux-User-name> Role: ... type: ... Level: ... supplementalGroups: type: MustRunAs #同FSGroup ranges: - min: 5000 max: 6000
M / N expressed as a starting M ID, range M ~ M + N-1
Supplemental groups ID for controlling access to shared storage, such as NFS, Gluster FS, and fsGroup for controlling access to the storage block, such as Ceph RBD, iSCSI. OpenShift container mounted volume and target storage has the same privileges. The target is stored UID 1234, groupID 5678, and then to mount the container volume node also has the ID value. Therefore, the process of the container needs to match the ID to use one or both of these volumes. The supplementalGroups fsGroup pod and at the system level is no distinction is only used to distinguish scenes pod level, in the definition of such values pod, will be added to the system in the supplemental groups.
verification:
SCC mainly related to User Strategy, SELinux Context Strategy, FSGroup Strategy and Supplemental Groups Strategy four strategies. SCC below to verify the functionality by hostpath access to mount the volume.
First, create an authorization object as a pod of serviceaccount
# Cat new - sa.yaml apiVersion: v1 kind: ServiceAccount metadata: name: new-in
Then create a separate SCC, the name for the new-scc. It will be used later to verify hostpath volume, thus setting allowHostDirVolumePlugin: true; all the policy settings to verify RunAsAny, i.e. permission not pod, if the pod is not set the values of these policies, the default value is used in the project are provided. Is validated does not affect the current environment, the use of the newly created SCC, which reads as follows:
# cat new-scc.yaml allowHostDirVolumePlugin: true allowHostIPC: false allowHostNetwork: false allowHostPID: false allowHostPorts: false allowPrivilegedContainer: false allowedCapabilities:
- '*' apiVersion: v1 defaultAddCapabilities: [] fsGroup: type: RunAsAny groups: - system:authenticated kind: SecurityContextConstraints metadata: annotations: kubernetes.io/description: for test scc name: new-scc priority: null readOnlyRootFilesystem: false
runAsUser: type: RunAsAny seLinuxContext: type: RunAsAny supplementalGroups: type: RunAsAny volumes: - configMap - downwardAPI - emptyDir - persistentVolumeClaim - projected - secret
Creating serviceaccount, scc use the following command, and create a new-scc authorized to give serviceaccount
# oc create -f new-sa.yaml # oc create -f new-scc.yaml # oadm policy add-scc-to-user new-scc system:serviceaccount:monitor:new-sa
Create a deploymentconfig, to facilitate the positioning problem, use the centos mirror (centos mirroring feature comparison). The deploymentconfig configured serviceaccount newly created, and the Pod does not configure any SCC limit.
apiVersion: V1 kind: DeploymentConfig Metadata: name: CentOS namespace : Monitor spec: Replicas: . 1 Template: Metadata: Labels: busybox: ' to true ' spec: Containers: - args: Image: ' CentOS: V2 ' imagePullPolicy: IfNotPresent name: busybox SecurityContext: runAsUser: 1000 runAsGroup: 2000 # this feature is only supported after k8s 1.10, this environment is not supported, seeSupport for RunAsGroup as a pod security context volumeMounts: - mountPath: /centos name: centos-volume securityContext: {} nodeSelector: kubernetes.io/hostname: test volumes: - hostPath: path: /home/testHostPath name: centos-volume serviceAccountName: new-sa triggers: - type: ConfigChange
The host / home / testHostPath permissions as follows:
# ls -Z drwxr-xr-x. root root unconfined_u:object_r:home_root_t:s0 testHostPath
Directly create the deploymentconfig (oc create -f centos.yaml), by oc describe pod can see the pod using scc and set serviceaccount
Annotations: openshift.io/scc=new-scc
...... Containers: busybox: ...... Mounts: /centos from centos-volume (rw) /var/run/secrets/kubernetes.io/serviceaccount from new-sa-token-q5rxk (ro)
Into the container, you can see the folder has been mounted in, but do not have any authority to operate the folder
sh-4.2$ cd /centos sh-4.2$ ls ls: cannot open directory .: Permission denied
The container where the landing node node, view the container SELinux set as follows, with the container file SELinux apparently created folder does not match, the host SELinux settings on a folder to match the container.
# docker inspect c21736278d1a|grep "MountLabel" "MountLabel": "system_u:object_r:svirt_sandbox_file_t:s0:c15,c10",
# chcon -Rt svirt_sandbox_file_t testHostPath/
After completion resolve SELinux, see the container corresponds to the process (docker inspect $ CONTAINERID | grep Pid ) information / proc / $ PID / status (see the specific meaning of / proc / [pid] / Status ). Can be seen that the container is used for user id 1000, group id is 0, supplemental groups of 100,023,000. user id and supplemental groups (Groups) using default values where the project, group id (including fsgroup) 0 is used.
# cat /proc/23032/status ...... Uid: 1000 1000 1000 1000 Gid: 0 0 0 0 FDSize: 2048 Groups: 1000230000
......
# oc describe project monitor Name: monitor Created: 2 weeks ago Labels: <none> Annotations: openshift.io/description= openshift.io/display-name= openshift.io/sa.scc.mcs=s0:c15,c10 openshift.io/sa.scc.supplemental-groups=1000230000/10000 openshift.io/sa.scc.uid-range=1000230000/10000
So far, the container can be read as a groupid 0 file folder, but DAC permissions testHostPath mount 755, no write permissions for the user group to group id 0, so need to set the DAC permissions. Such containers can read and write the folder of the mounted file.
# chmod 775 testHostPath/
- Here an example to verify the SCC runAsUser restrictions on the pod. RunAsAny value is modified from the following (oc edit scc new-scc), which allows the user ID is in the range [3000, 4000].
runAsUser: type: MustRunAsRange uidRangeMax: 4000 uidRangeMin: 3000
Re-create the deploymentconfig, the following error that invalid user ID occur. Description of the SCC user ID pod in the process has been restricted, only the qualifying process to perform (in this case pod uses the default value of the project). Other strategies such as fsGroup, supplementalGroups, seLinuxContext is similar, only the pod of policy values (not set the default value) and SCC SCC match to pass certification.
Error creating: pods "centos-1-" is forbidden: unable to validate against any security context constraint: [provider restricted: .spec.containers[0].securityContext.volumes[0]: Invalid value: "hostPath": hostPath volumes are not allowed to be used securityContext.runAsUser: Invalid value: 1000: UID on container busybox does not match required range. Found 1000, required min: 3000 max: 4000]
- Verify immediately preceding set, pod set of User id = 4000 (profile below). The permissions on the host testHostPath modified as follows, this time by the pod can not access the restricted DAC mount / centos directory (when using pod uid = 4000, gid = 0)
# cd /home
# chown -R 5000:6000 testHostPath/
# chmod 770 testHostPath/
Can be seen mounted directory permissions from the vessel consistent with the DAC host, the group as a pod case other group, can not perform read and write operations.
$ ls -Z /drwxrwx---. 5000 6000 unconfined_u:object_r:container_file_t:s0 centos
...
Use the following supplementalGroups authorized access, modify deploymentconfig as follows, to add support of supplementalGroups
apiVersion: v1 kind: DeploymentConfig metadata: name: centos namespace: monitor spec: replicas: 1 template: metadata: labels: busybox: 'true' spec: containers: - args: image: 'centos:v2' imagePullPolicy: IfNotPresent name: busybox securityContext: runAsUser: 4000 runAsGroup: 2000 volumeMounts: - mountPath: /centos name: centos-volume securityContext: supplementalGroups: [6000] nodeSelector: kubernetes.io/hostname: test volumes: - hostPath: path: /home/testHostPath name: centos-volume serviceAccountName: new-sa triggers: - type: ConfigChange
Re-create the deploymentconfig, into the container, see id, can be found supplementgroups added 6000, so that you can read and write to mount the volume.
$ id uid=4000 gid=0(root) groups=0(root),6000,1000230000
TIPS:
- It is generally used as a supplemental group ID or access stored credentials fsGroup
- SCC corresponding to kubernetes of PodSecurityPolicy , which is a beta version in v1.14
- -O yaml pod can be used by the view command oc get pod <pod_name> SCC, for the key corresponding to the annotation openshift.io/scc.
- openshift role and clusterrole control pod for service access to openshift resources; and the SCC is used to control access to the start pod and mounted volumes
reference:
https://docs.openshift.com/container-platform/3.6/install_config/persistent_storage/pod_security_context.html
https://docs.openshift.com/enterprise/3.0/architecture/additional_concepts/authorization.html#roles