Security Context

什么是安全上下文（Security Context）

安全上下文（Security Context）定义 Pod 或 Container 的特权与访问控制设置。管理员可以使用Security Context 定义运行的Pod是否有以下权限：

Pod 能否运行特权容器。
Linux 权能: 为进程赋予 root 用户的部分特权而非全部特权。
将主机目录当做卷使用。
容器的 SELinux 上下文。
基于用户 ID（UID）和组 ID（GID）来判定对对象（例如文件）的访问权限。
拥有 Pod 的卷的 FSGroup 的分配。
允许的附加组。
容器是否需要使用只读让root文件系统。
允许使用的卷类型。
配置允许的 seccomp 。

配置Pod或Container的Security Context

创建内容如下的scc1.yaml文件。

apiVersion: v1
kind: Pod
metadata:name: security-context-pod-demo
spec:volumes:- name: sec-ctx-volemptyDir: {}securityContext:runAsUser: 1000runAsGroup: 3000fsGroup: 2000containers:- name: sec-ctx-demoimage: busyboxcommand: ["sh", "-c", "sleep 60m"]volumeMounts:- name: sec-ctx-volmountPath: /pod/demosecurityContext:allowPrivilegeEscalation: false

执行命令创建Pod。然后进入该Pod，确认用户id为1000、组id为3000。

$ oc apply -f scc1.yaml
$ oc rsh security-context-pod-demo
~ $ whoami
1000
~ $ id
uid=1000(1000) gid=3000 groups=2000
~ $ more /etc/passwd
root:x:0:0:root:/root:/bin/sh
daemon:x:1:1:daemon:/usr/sbin:/bin/false
bin:x:2:2:bin:/bin:/bin/false
sys:x:3:3:sys:/dev:/bin/false
sync:x:4:100:sync:/bin:/bin/sync
mail:x:8:8:mail:/var/spool/mail:/bin/false
www-data:x:33:33:www-data:/var/www:/bin/false
operator:x:37:37:Operator:/var:/bin/false
nobody:x:65534:65534:nobody:/home:/bin/false
1000:x:1000:0:1000 user:/:/sbin/nologin

查看挂载到Pod中的卷目录所属组的id为2000。

~ $ ls -al /pod/demo
total 0
drwxrwsrwx    2 root     2000             6 Sep 30 01:58 .
drwxr-xr-x    3 root     root            18 Sep 30 01:58 ..

创建内容如下的scc2.yaml文件。

apiVersion: v1
kind: Pod
metadata:name: security-context-container-demo
spec:securityContext:runAsUser: 1000containers:- name: sec-ctx-demoimage: busyboxcommand: [ "sh", "-c", "sleep 60m" ]securityContext:runAsUser: 2000allowPrivilegeEscalation: false

执行命令生成Pod。然后进入该Pod确认Container的用户id为2000，说明Container的Security Context覆盖了Pod的Security Context定义。

$ oc apply -f scc2.yaml
$ oc rsh security-context-container-demo
~ $ id
uid=2000(2000) gid=0(root)

Security Context Constraints

在每个Pod级别控制Security Context比较繁琐，因此OpenShift提供了Security Context Constraints（SCC）的机制。SCC提供了预制和可自定义策略的方式简化对Pod运行权限的管理。
当用户第一次向 API 服务器请求一个 pod 的时候，将使用请求它的User Account作为授权凭证。每个pod都会在一个Service Account下运行，因此如果我们没有为pod指定一个Service Account，它将被自动分配给它所运行的Namespace上可用的默认Service Account。根据Service Account所属的用户、服务账户和/或组，负责检查请求权限的Admission Process找到可用的SCC集，并验证请求的资源Security Context和约束条件之间是否匹配。如果存在匹配，则 pod 被接受，否则就会被拒绝。

OpenShift为每个项目预制了8个SCC，可以执行以下命令查看缺省的SCC对象。

$ oc new-project my-scc
$ oc get scc
NAME                          PRIV    CAPS                           SELINUX     RUNASUSER          FSGROUP     SUPGROUP    PRIORITY     READONLYROOTFS   VOLUMES
anyuid                        false   <no value>                     MustRunAs   RunAsAny           RunAsAny    RunAsAny    10           false            [configMap downwardAPI emptyDir persistentVolumeClaim projected secret]
hostaccess                    false   <no value>                     MustRunAs   MustRunAsRange     MustRunAs   RunAsAny    <no value>   false            [configMap downwardAPI emptyDir hostPath persistentVolumeClaim projected secret]
hostmount-anyuid              false   <no value>                     MustRunAs   RunAsAny           RunAsAny    RunAsAny    <no value>   false            [configMap downwardAPI emptyDir hostPath nfs persistentVolumeClaim projected secret]
hostnetwork                   false   <no value>                     MustRunAs   MustRunAsRange     MustRunAs   MustRunAs   <no value>   false            [configMap downwardAPI emptyDir persistentVolumeClaim projected secret]
node-exporter                 true    <no value>                     RunAsAny    RunAsAny           RunAsAny    RunAsAny    <no value>   false            [*]
nonroot                       false   <no value>                     MustRunAs   MustRunAsNonRoot   RunAsAny    RunAsAny    <no value>   false            [configMap downwardAPI emptyDir persistentVolumeClaim projected secret]
privileged                    true    [*]                            RunAsAny    RunAsAny           RunAsAny    RunAsAny    <no value>   false            [*]
restricted                    false   <no value>                     MustRunAs   MustRunAsRange     MustRunAs   RunAsAny    <no value>   false            [configMap downwardAPI emptyDir persistentVolumeClaim projected secret]

如果不指定，OpenShift为每个Pod缺省指定的是“restricted”类的SCC。执行命令查看“restricted”类SCC对象。

$ oc describe scc restricted
Name:                                           restricted
Priority:                                       <none>
Access:Users:                                        <none>Groups:                                       system:authenticated
Settings:Allow Privileged:                             falseAllow Privilege Escalation:                   trueDefault Add Capabilities:                     <none>Required Drop Capabilities:                   KILL,MKNOD,SETUID,SETGIDAllowed Capabilities:                         <none>Allowed Seccomp Profiles:                     <none>Allowed Volume Types:                         configMap,downwardAPI,emptyDir,persistentVolumeClaim,projected,secretAllowed Flexvolumes:                          <all>Allowed Unsafe Sysctls:                       <none>Forbidden Sysctls:                            <none>Allow Host Network:                           falseAllow Host Ports:                             falseAllow Host PID:                               falseAllow Host IPC:                               falseRead Only Root Filesystem:                    falseRun As User Strategy: MustRunAsRangeUID:                                        <none>UID Range Min:                              <none>UID Range Max:                              <none>SELinux Context Strategy: MustRunAsUser:                                       <none>Role:                                       <none>Type:                                       <none>Level:                                      <none>FSGroup Strategy: MustRunAsRanges:                                     <none>Supplemental Groups Strategy: RunAsAnyRanges:                                     <none>

查看my-scc项目的annotations，其中“sa.scc”相关参数是当SCC策略非RunAsAny时提供默认值。

$ oc get project my-scc -o json | jq .metadata.annotations
{"openshift.io/description": "","openshift.io/display-name": "","openshift.io/requester": "system:admin","openshift.io/sa.scc.mcs": "s0:c26,c10","openshift.io/sa.scc.supplemental-groups": "1000670000/10000","openshift.io/sa.scc.uid-range": "1000670000/10000"
}

使用以下命令将SCC对象和用户、组绑定或解绑。

$ oc adm policy add-scc-to-user <SCC_NAME> user-name
$ oc adm policy add-scc-to-group <SCC_NAME> group-name
$ oc adm policy remove-scc-from-user <SCC_NAME> user-name
$ oc adm policy remove-scc-from-group <SCC_NAME> group-name

使用以下命令将SCC对象和Service Account绑定或解绑。

oc adm policy add-scc-to-user <SCC_NAME> -z service-account-name
oc adm policy remove-scc-from-user <SCC_NAME> -z service-account-name

使用以下命令查看哪些用户/组/ServiceAccount可以使用“nonroot”类的SCC。

$ oc adm policy who-can use scc nonroot
resourceaccessreviewresponse.authorization.openshift.io/<unknown>Namespace: my-scc
Verb:      use
Resource:  securitycontextconstraints.security.openshift.ioUsers:  opentlc-mgrsystem:adminsystem:serviceaccount:openshift-apiserver-operator:openshift-apiserver-operatorsystem:serviceaccount:openshift-apiserver:openshift-apiserver-sasystem:serviceaccount:openshift-authentication-operator:authentication-operatorsystem:serviceaccount:openshift-authentication:oauth-openshiftsystem:serviceaccount:openshift-cluster-node-tuning-operator:cluster-node-tuning-operatorsystem:serviceaccount:openshift-cluster-storage-operator:csi-snapshot-controller-operatorsystem:serviceaccount:openshift-cluster-version:defaultsystem:serviceaccount:openshift-controller-manager-operator:openshift-controller-manager-operatorsystem:serviceaccount:openshift-etcd-operator:etcd-operatorsystem:serviceaccount:openshift-etcd:installer-sasystem:serviceaccount:openshift-kube-apiserver-operator:kube-apiserver-operatorsystem:serviceaccount:openshift-kube-apiserver:installer-sasystem:serviceaccount:openshift-kube-apiserver:localhost-recovery-clientsystem:serviceaccount:openshift-kube-controller-manager-operator:kube-controller-manager-operatorsystem:serviceaccount:openshift-kube-controller-manager:installer-sasystem:serviceaccount:openshift-kube-controller-manager:localhost-recovery-clientsystem:serviceaccount:openshift-kube-scheduler-operator:openshift-kube-scheduler-operatorsystem:serviceaccount:openshift-kube-scheduler:installer-sasystem:serviceaccount:openshift-kube-scheduler:localhost-recovery-clientsystem:serviceaccount:openshift-kube-storage-version-migrator-operator:kube-storage-version-migrator-operatorsystem:serviceaccount:openshift-kube-storage-version-migrator:kube-storage-version-migrator-sasystem:serviceaccount:openshift-machine-config-operator:defaultsystem:serviceaccount:openshift-network-operator:defaultsystem:serviceaccount:openshift-operator-lifecycle-manager:olm-operator-serviceaccountsystem:serviceaccount:openshift-service-ca-operator:service-ca-operatorsystem:serviceaccount:openshift-service-catalog-apiserver-operator:openshift-service-catalog-apiserver-operatorsystem:serviceaccount:openshift-service-catalog-controller-manager-operator:openshift-service-catalog-controller-manager-operator
Groups: system:cluster-adminssystem:masters

执行命令先创建用户，然后为用户分配名为 nonroot 的 SCC，最后可以通过以下第三个命令在 clusterrolebinding 中找到用户/组/ServiceAccount包含 johndoe 的记录并显示出来。

$ oc create user johndoe
$ oc adm policy add-scc-to-user nonroot johndoe
clusterrole.rbac.authorization.k8s.io/system:openshift:scc:nonroot added: "johndoe"
$ oc describe clusterrolebinding $(oc get clusterrolebinding -owide | grep johndoe | awk '{print $1}')
Name:         system:openshift:scc:nonroot
Labels:       <none>
Annotations:  <none>
Role:Kind:  ClusterRoleName:  system:openshift:scc:nonroot
Subjects:Kind  Name     Namespace----  ----     ---------User  johndoe

参考

https://docs.openshift.com/container-platform/4.5/authentication/managing-security-context-constraints.html#managing-pod-security-policies
https://github.com/IBM/scc-tutorial-assets
https://cloud.redhat.com/blog/managing-sccs-in-openshift

OpenShift 4 - 安全上下文 SecurityContext相关推荐

Spring Security : 概念模型 SecurityContext 安全上下文
概述介绍 Spring Security使用接口SecurityContext抽象建模"安全上下文"这一概念.这里安全上下文SecurityContext指的是当前执行线程使用的 ...
OpenShift / RHEL / DevSecOps 汇总目录
文章目录 OpenShift / RHEL / DevSecOps 汇总目录 OpenShift 入门 OpenShift 安装免费线上环境 CRC单机环境 MicroShift Online安装 ...
OpenShift从入门到精通系列之二：深入了解OpenShift与K8S的关系
OpenShift从入门到精通系列之二:深入了解OpenShift与K8S的关系一.OpenShift与K8s的关系二.OpenShift发展简史三.OpenShift对K8s的增强四.Ope ...
SecurityContextPersistenceFilter和SecurityContextHolder的作用
SecurityContextPersistenceFilter和SecurityContextHolder的作用 SecurityContextHolder SecurityContextHolde ...
7-Spring Boot的安全管理
一.Spring Security基础 1.Spring Security介绍 a.Spring Security是基于Spring生态圈的,用于提供安全访问控制解决方案的框架. b.Spring S ...
SpringSecurity框架【详解】
SpringSecurity 来源视频文章目录 SpringSecurity 1.概述 2.Spring Security.Apache Shiro 选择问题 2.1.Shiro 2.1.1.shi ...
kubernetes的ingress：Ingress controller，traefik
文章目录 Ingress介绍 nginx ingress controller ingress URL Rewrite Basic Auth 灰度发布等各种发布方式 HTTPS CertManager ...
spring security技术分享
Spring Security技术专题一.初识认证和授权 1.1 认证 1.2 会话 1.3 授权 1.4 授权的数据模型 1.5 RBAC 1.5.1 角色访问控制 1.5.2 资源访问控制 1. ...
Pod资源管理进阶-Pod对象的生命周期
目录 Pod的生命周期 1.存活性探测行为属性 (Liveness probe) 2.Pod就绪性探测 3.Pod对象的相位 4.Pod的创建过程 5.Pod生命周期中的重要阶段 6.容器的重启策略 ...

OpenShift 4 - 安全上下文 SecurityContext

文章目录

Security Context

什么是安全上下文（Security Context）

配置Pod或Container的Security Context

Security Context Constraints

参考

OpenShift 4 - 安全上下文 SecurityContext相关推荐

最新文章

热门文章