kubernetes权威指南第4版第6章节读书笔记

　　　　　　　　　　　　　　　　　　　　深入分析集群安全机制

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 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授权模式详解

　　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）

对核心Master组件角色的说明如表6.3所示

　　RBAC API拒绝用户通过编辑角色或者角色绑定进行提升权限。这一限制是在API层面做出的，因此即使RBAC没有启用也仍然有效

　　用户要对角色进行创建或更新操作，需要满足下列至少一个条件:

　　　　（1）拥有一个角色的所有权限，且与该角色的生效范围一致（如果是集群角色，则是集群范围；如果是普通角色，则可能是同一个命名空间或者整个集群）
　　　　（2）为用户显式授予针对该角色或集群角色的提权（escalate）操作的权限（要求Kubernetes 1.12及以上版本）

对Service Account的授权管理

　　默认的RBAC策略为控制平台组件、节点和控制器授予有限范围的权限，但是除kube-system外的Service Account是没有任何权限的（除了所有认证用户都具有的discovery权限）。
　　这就要求用户为Service Account赋予所需的权限。细粒度的角色分配能够提高安全性，但也会提高管理成本。粗放的授权方式可能会给 Service Account多余的权限，但更易于管理

Admission Control

　　突破了之前所说的认证和鉴权两道关卡之后，客户端的调用请求就能够得到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及以下版本设置如下：

Service Account

　　Service Account也是一种账号，但它并不是给Kubernetes集群的用户（系统管理员、运维人员、租户用户等）用的，而是给运行在Pod里的进程用的，它为Pod里的进程提供了必要的身份证明

　　在正常情况下，为了确保Kubernetes集群的安全，API Server都会对客户端进行身份认证，认证失败的客户端无法进行API调用。此外，在 Pod中访问Kubernetes API Server服务时，是以Service方式访问名为 Kubernetes的这个服务的，而Kubernetes服务又只在HTTPS安全端口443 上提供，那么如何进行身份认证呢.通过查看官方源码，我们发现这是在用一种类似HTTP Token的新认证方式—Service Account Auth，Pod中的客户端调用Kubernetes API 时，在HTTP Header中传递了一个Token字符串，这类似于之前提到的 HTTP Token认证方式，但有以下几个不同之处　　

　　◎ 这个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私密凭据

　　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

Pod的安全策略配置

　　为了更精细地控制Pod对资源的使用方式，Kubernetes从1.4版本开始引入了PodSecurityPolicy资源对象对Pod的安全策略进行管理，并在 1.10版本中升级为Beta版，到1.14版本时趋于成熟。目前 PodSecurityPolicy资源对象的API版本为extensions/v1beta1，从1.10版本开始更新为policy/v1beta1，并计划于1.16版本时弃用 extensions/v1beta1

PodSecurityPolicy的工作机制

　　若想启用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：设置允许调整的内核参数