1.概述
通过权限系统,用户可以在OpenShift中有效控制不同用户在系统中对什么资源对象进行什么样的操作。权限控制的对象是资源。而SCC要管控的是具体容器可以或不可以执行哪些操作或调用。SCC是OpenShift规范用户运行容器行为的一个有效途径。
OpenShift使用Docker作为平台的容器引擎,因此OpenShift可以运行符合Docker标准的容器镜像。那为何同样的镜像通过Docker和通过OpenShift运行效果会不一致呢?其实是因为DockerHub中的大量镜像都是直接使用root用户启动应用的,这在某些特殊的场景下可能导致安全隐患。OpenShift考虑到企业的安全需要,引入了SCC这一特性。SCC限制了容器内启动用户的UID范围。也就是说,虽然Dockerfile文件中定义了容器使用root执行启动应用,但通过OpenShift运行容器时,OpenShift会根据当前容器和用户的安全上下文设置决定是按Docker指定的用户启动,还是随机生成一个普通用户运行。
2.系统默认的SCC组
通过命令oc get scc,可以看到集群默认定义了一组具有不同权限的SCC组。不同的SCC组有不同的权限配置,如下所示。这些配置控制了容器运行用户的UID、访问、支持卷的类型、是否能访问宿主机的文件、PID及网络等权限。在这些系统默认定义的SCC组中,privileged SCC组的权限最大,restricted SCC组的权限最小。普通用户及其创建项目的Service Account默认都归属于restricted组。
[root@master ~]# oc get sccNAME PRIV CAPS SELINUX RUNASUSER FSGROUP SUPGROUP PRIORITY READONLYROOTFS VOLUMES anyuid false [] MustRunAs RunAsAny RunAsAny RunAsAny 10 false [configMap downwardAPI emptyDir persistentVolumeClaim projected secret] hostaccess false [] MustRunAs MustRunAsRange MustRunAs RunAsAny <none> false [configMap downwardAPI emptyDir hostPath persistentVolumeClaim projected secret] hostmount-anyuid false [] MustRunAs RunAsAny RunAsAny RunAsAny <none> false [configMap downwardAPI emptyDir hostPath nfs persistentVolumeClaim projected secret] hostnetwork false [] MustRunAs MustRunAsRange MustRunAs MustRunAs <none> false [configMap downwardAPI emptyDir persistentVolumeClaim projected secret] nonroot false [] MustRunAs MustRunAsNonRoot RunAsAny RunAsAny <none> false [configMap downwardAPI emptyDir persistentVolumeClaim projected secret] privileged true [*] RunAsAny RunAsAny RunAsAny RunAsAny <none> false [*] restricted false [] MustRunAs MustRunAsRange MustRunAs RunAsAny <none> false [configMap downwardAPI emptyDir persistentVolumeClaim projected secret]
一个用户或者Service Account可以被赋予多个SCC,不同SCC的设置值可能相互覆盖。用户可以为不同的SCC值设置优先级,优先级更高的SCC设置值为最终生效值。
3.检查SCC
可以通过oc get,oc describe,oc export,或oc edit命令检查SCC组。
[root@master ~]# oc describe scc restricted Name: restricted Priority: <none>Access: Users: <none> Groups: system:authenticated Settings: Allow Privileged: false Default Add Capabilities: <none> Required Drop Capabilities: KILL,MKNOD,SETUID,SETGID Allowed Capabilities: <none> Allowed Seccomp Profiles: <none> Allowed Volume Types: configMap,downwardAPI,emptyDir,persistentVolumeClaim,projected,secret Allowed Flexvolumes: <all> Allow Host Network: false Allow Host Ports: false Allow Host PID: false Allow Host IPC: false Read Only Root Filesystem: false Run As User Strategy: MustRunAsRange UID: <none> UID Range Min: <none> UID Range Max: <none> SELinux Context Strategy: MustRunAs User: <none> Role: <none> Type: <none> Level: <none> FSGroup Strategy: MustRunAs Ranges: <none> Supplemental Groups Strategy: RunAsAny Ranges: <none>
4.创建SCC
定义SCC文件,选用json或yaml格式,如下:
kind: SecurityContextConstraints apiVersion: v1 metadata: name: scc-admin allowPrivilegedContainer: truerunAsUser: type: RunAsAny seLinuxContext: type: RunAsAny fsGroup: type: RunAsAny supplementalGroups: type: RunAsAny users: - my-admin-user groups: - my-admin-group
执行创建命令:
[root@master ~]# oc create -f scc-admin.yamlsecuritycontextconstraints "scc-admin" created
检查创建的SCC:
[root@master ~]# oc get scc scc-adminNAME PRIV CAPS SELINUX RUNASUSER FSGROUP SUPGROUP PRIORITY READONLYROOTFS VOLUMES scc-admin true [] RunAsAny RunAsAny RunAsAny RunAsAny <none> false [awsElasticBlockStore azureDisk azureFile cephFS cinder configMap downwardAPI emptyDir fc flexVolume flocker gcePersistentDisk gitRepo glusterfs iscsi nfs persistentVolumeClaim photonPersistentDisk portworxVolume projected quobyte rbd scaleIO secret storageOS vsphere]
5.删除SCC
删除一个SCC,命令格式如下:
[root@master ~]# oc delete scc scc-adminsecuritycontextconstraints "scc-admin" deleted
注:如果您删除了一个默认的SCC,它将在重新启动后重新生成。
6.更新SCC
命令格式:oc edit scc <scc-name>
7.更新默认SCC
默认SCC被删除,当主设备重启时会创建默认的SCC。要将SCC重置为默认值,或在升级后将现有的SCC更新为新的默认值,可以通过如下方式:
删除任何想要重置的SCC,并通过重启主设备来重新创建;
使用oc adm policy reconcile-sccs命令
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">oc adm policy reconcile-sccs命令将所有SCC策略设置为默认值,但保留任何其他用户、组、标签及可能已设置的优先级。如果需要查看那些SCC将被更改,您可以运行没有选项的命令或通过选项指定您的输出格式-o <format>
8.基于SCC的操作
8.1.授予Service Account账户进入SCC
创建一个Service Account账户,或者使用项目自动创建的Service Account。
创建Service Account账户命令格式:oc create serviceaccount <service-account-name> -n <project>
添加Service Account账户到SCC。命令格式:
oadm policy add-scc-to-user <scc> system:serviceaccount:<project>:<service-account-name>
或
oadm policy add-scc-to-user <scc> -z <<meta content="text/html; charset=utf-8" http-equiv="Content-Type">service-account-name> -n <project>
8.2.以Dockerfile指定的USER运行镜像
在某些特殊的场景下,使用root用户启用应用可能会导致安全隐患,而通过SCC可以限制或指定容器内启动用户的UID范围,这需要在Dockerfile文件中通过USER指定。若要使用USER指定的UID,则需要账户具有RunAsAny的权限。
授予所有的认证账户进入anyuid SCC。通过认证的账户,默认划归system:authenticated组。
$ oc adm policy add-scc-to-group anyuid system:authenticated
通过该配置,如果Dockerfile中没有设置USER指定用户UID,则运行镜像通过root用户启动应用。
作者:四冶
链接:https://www.jianshu.com/p/5b150f3aa944
共同学习,写下你的评论
评论加载中...
作者其他优质文章