前面讲了如何在部署pod时在任一宿主节点上做任何想做的事，比如部署一个特权模式的pod，但是需要一个机制阻止用户使用其中的部分功能，集群管理人员可以通过创建PodSecurityPolicy资源来限制对以上以上提到的安全相关特性使用
1、PodSecurityPolicy资源介绍
PodSecurityPolicy是一种集群级别（无命名空间）的资源，它定义了用户能否在pod中使用各种安全相关的特性。维护PodSecueityPolicy资源配置策略的工作由集成在api服务器中的PodSecurityPolicy准入控制插件完成
注意：你的集群中不一定启用了PodSecurityPolicy准入控制插件。在运行之前确保它已被启动
当向api服务器发送pod资源时，PodSecurityPolicy准入控制插件会将这个pod与已经配置的PodSecurityPolixy进行校验。如果这个pod符合集群中已有安全策略，它会被接收并存入etcd；否则它会立即被拒绝。这个插件也会根据安全策略中配置的默认值对pos进行修改
了解PodSecurityPolicy可以做的事
一个PodSecurityPolicy资源可以定义以下事项：
2、了解runASUser、fsGroup和supplemenntalGroup
如果需要限制容器可以使用的用户和用户组id，可以设置MustRunAS，并指定允许使用的ID范围
使用MustRunAs规则
需要在PodSecurityPolicy资源中设置
如果pod spec试图将其中任一字段设置为指定范围之外的值，可以通过删除之前的PodSecurityContextPolicy，并创建一个新的yaml来实现
注意：修改策略对已经存在的pod无效，因为PodSecurityPolicy资源仅在创建和升级pod时起作用
在runAsUser字段中使用mustRunAsNonRoot规则
runAsUser字段还可以使用一种规则：mustRunAsNonRoot。它将阻止用户部署以root用户运行的容器。在此情况下，spec容器中必须指定runAsUser字段，并且不能为0（0为root用户的id），或容器镜像本身指定一个非0的用户id运行。
3）配置允许、默认添加、禁止使用的内核功能
容器可以运行在特权模式下，也可以对每个容器添加或禁用linux内核功能来定义更细粒度的权限配置。以下三个字段会影响容器可以使用的内核功能：
allowedCapabilities
defaultAddCapabilities
requiredDropXapabilities
指定容器中可以添加的内核功能
allowedCapabilities字段用于指定spec容器的securityContrxt.capabilities中可以添加哪些内核功能。
4、限制pod可以使用的存储卷类型
podSecurity资源可以做到定义用户可以在pod中使用哪些类型存储卷。在最低限度上，一个podSecurity需要允许pod使用以下类型的存储卷：emptyDir、configMap、secret、downwardAPI、persistentVolumeClaim。
如果有多个PodSecurityPolicy资源，pod可以使用PodSecurityPolicy中允许使用的任何一个存储卷类型（实际生效的是所有volume列表的并集）
5、对不同的用户与组分配不同的podSecurityPolicy
PodSecurityPolicy是集群级别的资源，不能存储和应用在某一特定命名空间上。
对不同用户分配不同PodSecurityPolicy。创建你需要的PodSecurityPolicy资源，然后创建ClusterRole资源并通过名称将他们指向不同策略，以此使PodSecurityPolicy资源中的策略对不同的用户或组生效。通过ClusterRoleBinding资源将特定的用户或组绑定到ClusterRole上，当PodSecurityPolicy访问控制插件需要决定是否接纳一个pod时，他只会考虑创建pod的用户可以访问到的PodSecurityPolicy中的策略。
psp：podSecurityPolicy的缩写
使用RBAC将不同的PodSecurityPolicy分配给不同的用户
之前学过，使用RBAC机制来给用户授予特定类型的资源访问权限，RBAC机制也可以通过使用引用其名字来授予对特定资源实例的访问权限，这是为了让不同用户使用不同PodSecurityPolicy的方法。
创建两个ClusterRole，分别允许使用其中一个策略。将第一个ClusterRole命名为psp-default并允许其使用default PodSecurityPolicy资源。可以使用kubectl creat clusterrole来操作：
$kubectl create clusterrole psp-default - -verb=use
注意：使用的动词是use，而非get、list、watch或类似动词
如上，通过- -resource-name 选项引用了一个PodSecurityPolicy资源的实例。
现在创建另一个名为psp-privileged ClusterRole，指向privilege策略：
$kubectl create clusterrole psp-priviledge - -verb =use
现在把这两个策略绑定到用户上。为了绑定一个ClusterRole资源以授予对集群级别资源（PodSecurityPolicy资源就是集群级别资源）的访问权限，需要使用ClusterRoleBinding资源而非（有命名空间的）RoleBinding
将psp-default Cluster绑定到所有已认证用户上，这是必需的，否则没有用户可以创建pod，因为PodSecurityPolicy访问控制插件会因为没有找到任何策略而拒绝创建pod。所有已认证用户都属于system：authenticated组，因此需要将该ClusterRole绑定到该组：
$kubectl create clusterrolebinding psp-all-users
将psp-privileged ClusteeRole绑带到用户Bob：
$kubectl create clusterrolebinding ps-bob
为kubectl 创建不同用户
有kubectl 的config子命令创建两个新用户：
$kubectl config set-credentials alice - -usename=alice - -password=password
$kubectl config set-credentials bob - -username=bob - -password=password
这些命令对这两个用户使用基础http认证进行认证
使用不同用户创建pod
$kubectl - -user alice create -f pod-privileged.yaml