深入分析集群安全机制
API Server认证管理
我们知道，Kubernetes集群中所有资源的访问和变更都是通过 Kubernetes API Server的REST API来实现的，所以集群安全的关键点就 在于如何识别并认证客户端身份（Authentication），以及随后访问权限 的授权（Authorization）这两个关键问题
Kubernetes集群提供了3种级别的客户端身份认证方式
◎ 最严格的HTTPS证书认证：基于CA根证书签名的双向数字证 书认证方式。
◎ HTTP Token认证：通过一个Token来识别合法用户
◎ HTTP Base认证：通过用户名+密码的方式认证。
CA认证大概包含下面几个步骤
（1）HTTPS通信双方的服务器端向CA机构申请证书，CA机构是 可信的第三方机构，它可以是一个公认的权威企业，也可以是企业自 身。企业内部系统一般都用企业自身的认证系统。CA机构下发根证 书、服务端证书及私钥给申请者。
（2）HTTPS通信双方的客户端向CA机构申请证书，CA机构下发 根证书、客户端证书及私钥给申请者。
（3）客户端向服务器端发起请求，服务端下发服务端证书给客户 端。客户端接收到证书后，通过私钥解密证书，并利用服务器端证书中 的公钥认证证书信息比较证书里的消息，例如，比较域名和公钥与服务 器刚刚发送的相关消息是否一致，如果一致，则客户端认可这个服务器 的合法身份。
（4）客户端发送客户端证书给服务器端，服务端在接收到证书 后，通过私钥解密证书，获得客户端证书公钥，并用该公钥认证证书信 息，确认客户端是否合法。
（5）客户端通过随机密钥加密信息，并发送加密后的信息给服务 端。在服务器端和客户端协商好加密方案后，客户端会产生一个随机的 密钥，客户端通过协商好的加密方案加密该随机密钥，并发送该随机密 钥到服务器端。服务器端接收这个密钥后，双方通信的所有内容都通过 该随机密钥加密。
上述是双向认证SSL协议的具体通信过程，这种情况要求服务器和 用户双方都有证书。单向认证SSL协议则不需要客户端拥有CA证书，对 于上面的步骤，只需将服务器端验证客户证书的过程去掉，之后协商对称密码方案和对称通话密钥时，服务器发送给客户的密码没被加密即 可。
HTTP Token的认证是用一个很长的特殊编码方式的并且难以被模 仿的字符串—Token来表明客户身份的一种方式。在通常情况下，Token 是一个很复杂的字符串，比如我们用私钥签名一个字符串后的数据就可 以被当作一个Token。此外，每个Token对应一个用户名，存储在API Server能访问的一个文件中。当客户端发起API调用请求时，需要在 HTTP Header里放入Token，这样一来，API Server就能识别合法用户和 非法用户了
HTTP Base认证:HTTP是无状态的，浏览器和Web服务器之间可以通过 Cookie来进行身份识别。桌面应用程序（比如新浪桌面客户端、 SkyDrive客户端、命令行程序）一般不会使用Cookie，那么它们与Web 服务器之间是如何进行身份识别的呢？这就用到了HTTP Base认证，这种认证方式是把“用户名+冒号+密码”用BASE64算法进行编码后的字符 串放在HTTP Request中的Header Authorization域里发送给服务端，服务 端在收到后进行解码，获取用户名及密码，然后进行用户身份鉴权
当客户端发起API Server调用时，API Server内部要先进行用户认 证，然后执行用户授权流程，即通过授权策略来决定一个API调用是否 合法。对合法用户进行授权并且随后在用户访问时进行鉴权，是权限与 安全系统的重要一环。简单地说，授权就是授予不同的用户不同的访问 权限。API Server目前支持以下几种授权策略（通过API Server的启动参 数“--authorization-mode”设置）
◎ AlwaysDeny：表示拒绝所有请求，一般用于测试。
◎ AlwaysAllow：允许接收所有请求，如果集群不需要授权流 程，则可以采用该策略，这也是Kubernetes的默认配置。
◎ ABAC（Attribute-Based Access Control）：基于属性的访问控 制，表示使用用户配置的授权规则对用户请求进行匹配和控制。
◎ Webhook：通过调用外部REST服务对用户进行授权。
◎ RBAC：Role-Based Access Control，基于角色的访问控制。
◎ Node：是一种专用模式，用于对kubelet发出的请求进行访问控 制
RBAC（Role-Based Access Control，基于角色的访问控制）在 Kubernetes的1.5版本中引入，在1.6版本时升级为Beta版本，在1.8版本时 升级为GA
◎ 对集群中的资源和非资源权限均有完整的覆盖。
◎ 整个RBAC完全由几个API对象完成，同其他API对象一样，可 以用kubectl或API进行操作。
◎ 可以在运行时进行调整，无须重新启动API Server。
1.RBAC的API资源对象说明
RBAC引入了4个新的顶级资源对象：Role、ClusterRole、 RoleBinding和ClusterRoleBinding。同其他API资源对象一样，用户可以 使用kubectl或者API调用等方式操作这些资源对象
1）角色（Role）一个角色就是一组权限的集合，这里的权限都是许可形式的，不存 在拒绝的规则。在一个命名空间中，可以用角色来定义一个角色，如果 是集群级别的，就需要使用ClusterRole了
rules中的参数说明如下。
◎ apiGroups：支持的API组列表，例如“apiVersion: batch/v1”“apiVersion: extensions:v1beta1”“apiVersion: apps/v1beta1”等
◎ resources：支持的资源对象列表，例如pods、deployments、 jobs等
◎ verbs：对资源对象的操作方法列表，例如get、watch、list、delete、replace、patch等
2）集群角色（ClusterRole）
集群角色除了具有和角色一致的命名空间内资源的管理能力，因其 集群级别的范围，还可以用于以下特殊元素的授权
◎ 集群范围的资源，例如Node。
◎ 非资源型的路径，例如“/healthz”。
◎ 包含全部命名空间的资源，例如pods（用于kubectl get pods -- all-namespaces这样的操作授权）。
3）角色绑定（RoleBinding）和集群角色绑定 （ClusterRoleBinding）
角色绑定或集群角色绑定用来把一个角色绑定到一个目标上，绑定 目标可以是User（用户）、Group（组）或者Service Account。使用 RoleBinding为某个命名空间授权，使用ClusterRoleBinding为集群范围内 授权
RoleBinding可以引用Role进行授权。下面的例子中的RoleBinding将 在default命名空间中把pod-reader角色授予用户jane，这一操作可以让
jane读取default命名空间中的Pod：
例如，在下面的例子中，虽然secret-reader是一个集群角色，但是因 为使用了RoleBinding，所以dave只能读取development命名空间中的 secret
在这个例子中，Pod是一个命名空间内的资源，log就是一个下级资 源。要在一个RBAC角色中体现，就需要用斜线“/”来分隔资源和下级资 源。若想授权让某个主体同时能够读取Pod和Pod log，则可以配置 resources为一个数组
资源还可以通过名称（ResourceName）进行引用。在指定 ResourceName后，使用get、delete、update和patch动词的请求，就会被 限制在这个资源实例范围内。例如，下面的声明让一个主体只能对一个 ConFigmap进行get和update操作
3.常用的角色示例.注意，下面的例子只展示了rules部分的内容
（1）允许读取核心API组中的Pod资源：
（2）允许读写extensions和apps两个API组中的deployment资源：
（3）允许读取pods及读写jobs
（4）允许读取一个名为my-config的ConfigMap（必须绑定到一个 RoleBinding来限制到一个Namespace下的ConfigMap）
（5）读取核心组的Node资源（Node属于集群级的资源，所以必须 存在于ClusterRole中，并使用ClusterRoleBinding进行绑定）：
4.常见的角色绑定示例.注意，在下面的例子中只包含subjects部分的内容。
（1）用户名alice@example.com：
（2）组名frontend-admins：
（3）kube-system命名空间中的默认Service Account：
（4）qa命名空间中的所有Service Account：
（5）所有Service Account：
（6）所有认证用户（Kubernetes 1.5以上版本）：
（7）所有未认证用户（Kubernetes 1.5以上版本）：
（8）全部用户（Kubernetes 1.5以上版本）：
对系统角色的说明如表6.1所示
有些默认角色不是以“system:”为前缀的，这部分角色是针对用户的。其中包含超级用户角色（cluster- admin），有的用于集群一级的角色（cluster-status），还有针对 Namespace的角色（admin、edit、view）
RBAC API拒绝用户通过编辑角色或者角色绑定进行提升权限。这 一限制是在API层面做出的，因此即使RBAC没有启用也仍然有效
用户要对角色进行创建或更新操作，需要满足下列至少一个条件:
（1）拥有一个角色的所有权限，且与该角色的生效范围一致（如 果是集群角色，则是集群范围；如果是普通角色，则可能是同一个命名 空间或者整个集群）
（2）为用户显式授予针对该角色或集群角色的提权（escalate）操 作的权限（要求Kubernetes 1.12及以上版本）
对Service Account的授权管理
默认的RBAC策略为控制平台组件、节点和控制器授予有限范围的 权限，但是除kube-system外的Service Account是没有任何权限的（除了 所有认证用户都具有的discovery权限）。
这就要求用户为Service Account赋予所需的权限。细粒度的角色分 配能够提高安全性，但也会提高管理成本。粗放的授权方式可能会给 Service Account多余的权限，但更易于管理
突破了之前所说的认证和鉴权两道关卡之后，客户端的调用请求就 能够得到API Server的真正响应了吗？答案是：不能！这个请求还需要 通过Admission Control（准入控制）所控制的一个准入控制链的层层考 验，才能获得成功的响应。Kubernetes官方标准的“关卡”有30多个，还 允许用户自定义扩展
Admission Control配备了一个准入控制器的插件列表，发送给API Server的任何请求都需要通过列表中每个准入控制器的检查，检查不通 过，则API Server拒绝此调用请求。此外，准入控制器插件能够修改请 求参数以完成一些自动化任务，比如ServiceAccount这个控制器插件。 当前可配置的准入控制器插件如下
◎ AlwaysAdmit：已弃用，允许所有请求
◎ AlwaysPullImages：在启动容器之前总是尝试重新下载镜像。 这对于多租户共享一个集群的场景非常有用，系统在启动容器之前可以 保证总是使用租户的密钥去下载镜像。如果不设置这个控制器，则在 Node上下载的镜像的安全性将被削弱，只要知道该镜像的名称，任何人 便都可以使用它们了
◎ AlwaysDeny：已弃用，禁止所有请求，用于测试。
◎ DefaultStorageClass：会关注PersistentVolumeClaim资源对象的 创建，如果其中没有包含任何针对特定Storage class的请求，则为其指 派指定的Storage class。在这种情况下，用户无须在PVC中设置任何特定 的Storage class就能完成PVC的创建了。如果没有设置默认的Storage class，该控制器就不会进行任何操作；如果设置了超过一个的默认 Storage class，该控制器就会拒绝所有PVC对象的创建申请，并返回错误信息。管理员必须检查StorageClass对象的配置，确保只有一个默认 值。该控制器仅关注PVC的创建过程，对更新过程无效
◎ DefaultTolerationSeconds：针对没有设置容忍 node.kubernetes.io/not-ready:NoExecute或者 node.alpha.kubernetes.io/unreachable:NoExecute的Pod，设置5min的默认 容忍时间。
◎ DenyEscalatingExec：拦截所有exec和attach到具有特权的Pod上 的请求。如果你的集群支持运行有escalated privilege权限的容器，又希 望限制用户在这些容器内执行命令，那么强烈推荐使用它。
◎ EventReateLimit：Alpha版本，用于应对事件密集情况下对API Server造成的洪水攻击。
◎ Initializers：Alpha。用于为动态准入控制提供支持，通过修改 待创建资源的元数据来完成对该资源的修改。
◎ LimitPodHardAntiAffinityTopology：该插件启用了Pod的反亲和性调度策略设置，在设置亲和性策略参数requiredDuringSchedulingRequiredDuringExecution时要求将topologyKey 的值设置为“kubernetes.io/hostname”，否则Pod会被拒绝创建。
◎ LimitRanger：这个插件会监控进入的请求，确保请求的内容符 合在Namespace中定义的LimitRange对象里的资源限制。如果要在 Kubernetes集群中使用LimitRange对象，则必须启用该插件才能实施这 一限制。LimitRanger还能用于为没有设置资源请求的Pod自动设置默认 的资源请求，该插件会为default命名空间中的所有Pod设置0.1CPU的资 源请求
◎ MutatingAdmissionWebhook：Beta。这一插件会变更符合要求 的请求的内容，Webhook以串行的方式顺序执行
◎ NamespaceAutoProvision：这一插件会检测所有进入的具备命 名空间的资源请求，如果其中引用的命名空间不存在，就会自动创建命 名空间。
◎ NamespaceExists：这一插件会检测所有进入的具备命名空间的 资源请求，如果其中引用的命名空间不存在，就会拒绝这一创建过程。
◎ NamespaceLifecycle：如果尝试在一个不存在的Namespace中创 建资源对象，则该创建请求将被拒绝。当删除一个Namespace时，系统 将会删除该Namespace中的所有对象，包括Pod、Service等，并阻止删除 default、kube-system和kube-public这三个命名空间。
◎ NodeRestriction：该插件会限制kubelet对Node和Pod的修改行 为。为了实现这一限制，kubelet必须使用system:nodes组中用户名为 system:node:<nodeName>的Token来运行。符合条件的kubelet只能修改 自己的Node对象，也只能修改分配到各自Node上的Pod对象。在 Kubernetes 1.11以后的版本中，kubelet无法修改或者更新自身Node的 taint属性。在Kubernetes 1.13以后，这一插件还会阻止kubelet删除自己的Node资源，并限制对有kubernetes.io/或k8s.io/前缀的标签的修改。
◎ ResourceQuota：用于资源配额管理目的，作用于Namespace。 该插件拦截所有请求，以确保在Namespace上的资源配额使用不会超 标。推荐在Admission Control参数列表中将这个插件排最后一个，以免 可能被其他插件拒绝的Pod被过早分配资源
◎ ServiceAccount：这个插件将ServiceAccount实现了自动化，如 果想使用ServiceAccount对象，那么强烈推荐使用它
在API Server上设置参数即可定制我们需要的准入控制链，如果启 用多种准入控制选项，则建议设置：在Kubernetes 1.9及之前的版本中使用的参数是--admission-control，并且其中的内容是顺序相关的；在 Kubernetes 1.10及之后的版本中，该参数为--enable-admission-plugins， 并且与顺序无关。
对Kubernetes 1.10及以上版本设置如下
对Kubernetes 1.9及以下版本设置如下：
◎ 这个Token的内容来自Pod里指定路径下的一个文件 （/run/secrets/kubernetes.io/serviceaccount/token），这种Token是动态生 成的，确切地说，是由Kubernetes Controller进程用API Server的私钥（-- service-account-private-key-file指定的私钥）签名生成的一个JWT Secret。◎ 这个Token的内容来自Pod里指定路径下的一个文件 （/run/secrets/kubernetes.io/serviceaccount/token），这种Token是动态生 成的，确切地说，是由Kubernetes Controller进程用API Server的私钥（-- service-account-private-key-file指定的私钥）签名生成的一个JWT Secret。
◎ 在官方提供的客户端REST框架代码里，通过HTTPS方式与API Server建立连接后，会用Pod里指定路径下的一个CA证书 （/run/secrets/kubernetes.io/serviceaccount/ca.crt）验证API Server发来的 证书，验证是否为CA证书签名的合法证书。
◎ API Server在收到这个Token以后，采用自己的私钥（实际上是 使用service-accountkey-file参数指定的私钥，如果没有设置此参数，则 默认采用tls-private-key-file指定的参数，即自己的私钥）对Token进行合 法性验证。
我们接下来继续分析在上面的认证过程中所涉及 的Pod中的以下三个文件。
◎ /run/secrets/kubernetes.io/serviceaccount/token。
◎ /run/secrets/kubernetes.io/serviceaccount/ca.crt。
◎ /run/secrets/kubernetes.io/serviceaccount/namespace（客户端采用 这里指定的namespace作为参数调用Kubernetes API）。
这三个文件由于参与到Pod进程与API Server认证的过程中，起到了 类似secret（私密凭据）的作用，所以它们被称为Kubernetes Secret对 象。Secret从属于Service Account资源对象，属于Service Account的一部 分，在一个Service Account对象里面可以包括多个不同的Secret对象，分 别用于不同目的的认证活动
查看系统中的Service Account对象，看到有一个名为default 的Service Account对象，包含一个名为default-token-77oyg的Secret，这 个Secret同时是Mountable secrets，表明它是需要被挂载到Pod上的
default-token-77oyg包含三个数据 项，分别是token、ca.crt、namespace。联想到Mountable secrets的标记， 以及之前看到的Pod中的三个文件的文件名，我们恍然大悟：在每个 Namespace下都有一个名为default的默认Service Account对象，在这个 Service Account里面有一个名为Tokens的可以当作Volume被挂载到Pod 里的Secret，当Pod启动时，这个Secret会自动被挂载到Pod的指定目录下，用来协助完成Pod中的进程访问API Server时的身份鉴权
其中：
（1）名为Tokens的Secret用于访问API Server的Secret，也被称为 Service Account Secret。
（2）名为imagePullSecrets的Secret用于下载容器镜像时的认证过 程，通常镜像库运行在Insecure模式下，所以这个Secret为空。
（3）用户自定义的其他Secret，用于用户的进程。
如果一个Pod在定义时没有指定spec.serviceAccountName属性，则系 统会自动为其赋值为default，即大家都使用同一个Namespace下的默认 Service Account。如果某个Pod需要使用非default的Service Account，则 需要在定义时指定：
Kubernetes之所以要创建两套独立的账号系统，原因如下。
◎ User账号是给人用的，Service Account是给Pod里的进程使用 的，面向的对象不同。
◎ User账号是全局性的，Service Account则属于某个具体的 Namespace。
◎ 通常来说，User账号是与后端的用户数据库同步的，创建一个 新用户通常要走一套复杂的业务流程才能实现，Service Account的创建 则需要极轻量级的实现方式，集群管理员可以很容易地为某些特定任务 创建一个Service Account。
◎ 对于这两种不同的账号，其审计要求通常不同。
◎ 对于一个复杂的系统来说，多个组件通常拥有各种账号的配置 信息，Service Account是Namespace隔离的，可以针对组件进行一对一 的定义，同时具备很好的“便携性”。
接下来深入分析Service Account与Secret相关的一些运行机制
我们知道Controller manager创建了 ServiceAccount Controller与Token Controller这两个安全相关的控制器。其中ServiceAccount Controller一直监听Service Account和Namespace的事 件，如果在一个 Namespace中没有default Service Account，那么 ServiceAccount Controller会为该Namespace创建一个默认（default）的Service Account，这就是我们之前看到在每个Namespace下都有一个名 为default的Service Account的原因。
Secret的主要作用是保管私密数据，比如密 码、OAuth Tokens、SSH Keys等信息。将这些私密信息放在Secret对象 中比直接放在Pod或Docker Image中更安全，也更便于使用和分发
在上面的例子中，data域的各子域的值必须为BASE64编码值，其 中password域和username域BASE64编码前的值分别为value-1和value-2
一旦Secret被创建，就可以通过下面三种方式使用它
（1）在创建Pod时，通过为Pod指定Service Account来自动使用该 Secret
（2）通过挂载该Secret到Pod来使用它。
（3）在Docker镜像下载时使用，通过指定Pod的 spc.ImagePullSecrets来引用它。
第1种使用方式主要用在API Server鉴权方面.下面的例子展示了第2种使用方式：将一个Secret通过挂载的方式添加到Pod的 Volume中：
每个单独的Secret大小不能超过1MB，Kubernetes不鼓励创建大的 Secret，因为如果使用大的Secret，则将大量占用API Server和kubelet的 内存。当然，创建许多小的Secret也能耗尽API Server和kubelet的内存
我们可以通过Secret保管其他 系统的敏感信息（比如数据库的用户名和密码），并以Mount的方式将 Secret挂载到Container中，然后通过访问目录中文件的方式获取该敏感 信息。当Pod被API Server创建时，API Server不会校验该Pod引用的 Secret是否存在。一旦这个Pod被调度，则kubelet将试着获取Secret的 值。如果Secret不存在或暂时无法连接到API Server，则kubelet按一定的 时间间隔定期重试获取该Secret，并发送一个Event来解释Pod没有启动 的原因一旦Secret被Pod获取，则kubelet将创建并挂载包含Secret的 Volume。只有所有Volume都挂载成功，Pod中的Container才会被启动。 在kubelet启动Pod中的Container后，Container中和Secret相关的Volume将 不会被改变，即使Secret本身被修改。为了使用更新后的Secret，必须删 除旧Pod，并重新创建一个新Pod
若想启用PodSecurityPolicy机制，则需要在kube-apiserver服务的启 动参数--enable-admission-plugins中进行设置
在开启PodSecurityPolicy准入控制器后，Kubernetes默认不允许创建 任何Pod，需要创建PodSecurityPolicy策略和相应的RBAC授权策略 （Authorizing Policies），Pod才能创建成功
创建一个PodSecurityPolicy，配置文件psp-non- privileged.yaml的内容如下
在PodSecurityPolicy对象中可以设置下列字段来控制Pod运行时的各 种安全策略
1.特权模式相关配置.privileged：是否允许Pod以特权模式运行。
2.宿主机资源相关配置
（1）hostPID：是否允许Pod共享宿主机的进程空间。
（2）hostIPC：是否允许Pod共享宿主机的IPC命名空间。
（3）hostNetwork：是否允许Pod使用宿主机网络的命名空间
（4）hostPorts：是否允许Pod使用宿主机的端口号，可以通过 hostPortRange字段设置允许使用的端口号范围，以[min, max]设置最小 端口号和最大端口号。
（5）Volumes：允许Pod使用的存储卷Volume类型，设置为“*”表 示允许使用任意Volume类型，建议至少允许Pod使用下列Volume类型。
◎ configMap ◎ downwardAPI ◎ emptyDir ◎ persistentVolumeClaim ◎ secret ◎ projected
（6）AllowedHostPaths：允许Pod使用宿主机的hostPath路径名称， 可以通过pathPrefix字段设置路径的前缀，并可以设置是否为只读属性
结果为允许Pod访问宿主机上以“/foo”为前缀的路径，包 括“/foo”“/foo/”“/foo/bar”等，但不能访问“/fool”“/etc/foo”等路径，也不允 许通过“/foo/../”表达式访问/foo的上层目录
（7）FSGroup：设置允许访问某些Volume的Group ID范围，可以 将规则（rule字段）设置为MustRunAs、MayRunAs或RunAsAny。
◎ MustRunAs：需要设置Group ID的范围，例如1～65535，要求 Pod的securityContext.fsGroup设置的值必须属于该Group ID的范围
◎ MayRunAs：需要设置Group ID的范围，例如1～65535，不强 制要求Pod设置securityContext.fsGroup。
◎ RunAsAny：不限制Group ID的范围，任何Group都可以访问 Volume。
（8）ReadOnlyRootFilesystem：要求容器运行的根文件系统（root filesystem）必须是只读的。
（9）allowedFlexVolumes：对于类型为flexVolume的存储卷，设置 允许使用的驱动类型，例子如下。
3.用户和组相关配置
（1）RunAsUser：设置运行容器的用户ID（User ID）范围，规则 字段（rule）的值可以被设置为MustRunAs、MustRunAsNonRoot或 RunAsAny。
◎ MustRunAs：需要设置User ID的范围，要求Pod的 securityContext.runAsUser设置的值必须属于该User ID的范围。
◎ MustRunAsNonRoot：必须以非root用户运行容器，要求Pod的 securityContext.runAsUser设置一个非0的用户ID，或者镜像中在USER字 段设置了用户ID，建议同时设置allowPrivilegeEscalation=false以避免不 必要的提升权限操作。
◎ RunAsAny：不限制User ID的范围，任何User都可以运行。
（2）RunAsGroup：设置运行容器的Group ID范围，规则字段的值 可以被设置为MustRunAs、MustRunAsNonRoot或RunAsAny。
◎ MustRunAs：需要设置Group ID的范围，要求Pod的 securityContext.runAsGroup设置的值必须属于该Group ID的范围。
◎ MustRunAsNonRoot：必须以非root组运行容器，要求Pod的 securityContext.runAsUser设置一个非0的用户ID，或者镜像中在USER字 段设置了用户ID，建议同时设置allowPrivilegeEscalation=false以避免不必要的提升权限操作
◎ RunAsAny：不限制Group ID的范围，任何Group的用户都可以 运行
（3）SupplementalGroups：设置容器可以额外添加的Group ID范 围，可以将规则（rule字段）设置为MustRunAs、MayRunAs或 RunAsAny。
◎ MustRunAs：需要设置Group ID的范围，要求Pod的 securityContext.supplementalGroups设置的值必须属于该Group ID范围。
◎ MayRunAs：需要设置Group ID的范围，不强制要求Pod设置 securityContext.supplementalGroups。
◎ RunAsAny：不限制Group ID的范围，任何supplementalGroups 的用户都可以运行。
4.提升权限相关配置
（1）AllowPrivilegeEscalation：设置容器内的子进程是否可以提升 权限，通常在设置非root用户（MustRunAsNonRoot）时进行设置
（2）DefaultAllowPrivilegeEscalation：设置AllowPrivilegeEscalation 的默认值，设置为disallow时，管理员还可以显式设置AllowPrivilegeEscalation来指定是否允许提升权限。
5.Linux能力相关配置
（1）AllowedCapabilities：设置容器可以使用的Linux能力列表，设 置为“*”表示允许使用Linux的所有能力（如NET_ADMIN、SYS_TIME 等）
（2）RequiredDropCapabilities：设置不允许容器使用的Linux能力 列表。
（3）DefaultAddCapabilities：设置默认为容器添加的Linux能力列 表，例如SYS_TIME等
6.SELinux相关配置
seLinux：设置SELinux参数，可以将规则字段（rule）的值设置为 MustRunAs或RunAsAny。
◎ MustRunAs：要求设置seLinuxOptions，系统将对Pod的 securityContext.seLinuxOptions设置的值进行校验。
◎ RunAsAny：不限制seLinuxOptions的设置。
7.其他Linux相关配置
（1）AllowedProcMountTypes：设置允许的ProcMountTypes类型列 表，可以设置allowedProcMountTypes或DefaultProcMount。
（2）AppArmor：设置对容器可执行程序的访问控制权限
（3）Seccomp：设置允许容器使用的系统调用（System Calls）的 profile。
（4）Sysctl：设置允许调整的内核参数
例2：要求Pod运行用户为非特权用户；禁止提升权限；不允许使用 宿主机网络、端口号、IPC等资源；限制可以使用的Volume类型，等 等
此外，Kubernetes建议使用RBAC授权机制来设置针对Pod安全策略 的授权，通常应该对Pod的ServiceAccount进行授权
例如，可以创建如下ClusterRole（也可以创建Role）并将其设置为 允许使用PodSecurityPolicy
然后创建一个ClusterRoleBinding与用户和ServiceAccount进行绑 定
