• Pod 安全策略
    • 什么是 Pod 安全策略?
      • RunAsUser
      • SELinux
      • SupplementalGroups
      • FSGroup
      • 控制卷
      • 主机网络
      • 允许的主机路径
    • 许可
      • 创建一个策略和一个 Pod
    • 获取 Pod 安全策略列表
    • 修改 Pod 安全策略
    • 删除 Pod 安全策略
    • 启用 Pod 安全策略
    • 使用 RBAC
    • 反馈

    Pod 安全策略

    PodSecurityPolicy 类型的对象能够控制,是否可以向 Pod 发送请求,该 Pod 能够影响被应用到 Pod 和容器的 SecurityContext。查看 Pod 安全策略建议 获取更多信息。

    什么是 Pod 安全策略?

    Pod 安全策略 是集群级别的资源,它能够控制 Pod 运行的行为,以及它具有访问什么的能力。PodSecurityPolicy 对象定义了一组条件,指示 Pod 必须按系统所能接受的顺序运行。它们允许管理员控制如下方面:

    控制面字段名称
    已授权容器的运行privileged
    为容器添加默认的一组能力defaultAddCapabilities
    为容器去掉某些能力requiredDropCapabilities
    容器能够请求添加某些能力allowedCapabilities
    控制卷类型的使用volumes
    主机网络的使用hostNetwork
    主机端口的使用hostPorts
    主机 PID namespace 的使用hostPID
    主机 IPC namespace 的使用hostIPC
    主机路径的使用allowedHostPaths
    容器的 SELinux 上下文seLinux
    用户 IDrunAsUser
    配置允许的补充组supplementalGroups
    分配拥有 Pod 数据卷的 FSGroupfsGroup
    必须使用一个只读的 root 文件系统readOnlyRootFilesystem

    Pod 安全策略 由设置和策略组成,它们能够控制 Pod 访问的安全特征。这些设置分为如下三类:

    • 基于布尔值控制 :这种类型的字段默认为最严格限制的值。
    • 基于被允许的值集合控制 :这种类型的字段会与这组值进行对比,以确认值被允许。
    • 基于策略控制 :设置项通过一种策略提供的机制来生成该值,这种机制能够确保指定的值落在被允许的这组值中。

    RunAsUser

    • MustRunAs - 必须配置一个 range。使用该范围内的第一个值作为默认值。验证是否不在配置的该范围内。
    • MustRunAsNonRoot - 要求提交的 Pod 具有非零 runAsUser 值,或在镜像中定义了 USER 环境变量。不提供默认值。
    • RunAsAny - 没有提供默认值。允许指定任何 runAsUser

    SELinux

    • MustRunAs - 如果没有使用预分配的值,必须配置 seLinuxOptions。默认使用 seLinuxOptions。验证 seLinuxOptions
    • RunAsAny - 没有提供默认值。允许任意指定的 seLinuxOptions ID。

    SupplementalGroups

    • MustRunAs - 至少需要指定一个范围。默认使用第一个范围的最小值。验证所有范围的值。
    • RunAsAny - 没有提供默认值。允许任意指定的 supplementalGroups ID。

    FSGroup

    • MustRunAs - 至少需要指定一个范围。默认使用第一个范围的最小值。验证在第一个范围内的第一个 ID。
    • RunAsAny - 没有提供默认值。允许任意指定的 fsGroup ID。

    控制卷

    通过设置 PSP 卷字段,能够控制具体卷类型的使用。当创建一个卷的时候,与该字段相关的已定义卷可以允许设置如下值:

    • azureFile
    • azureDisk
    • flocker
    • flexVolume
    • hostPath
    • emptyDir
    • gcePersistentDisk
    • awsElasticBlockStore
    • gitRepo
    • secret
    • nfs
    • iscsi
    • glusterfs
    • persistentVolumeClaim
    • rbd
    • cinder
    • cephFS
    • downwardAPI
    • fc
    • configMap
    • vsphereVolume
    • quobyte
    • projected
    • portworxVolume
    • scaleIO
    • storageos
      • (allow all volumes) 对新的 PSP,推荐允许的卷的最小集合包括:configMap、downwardAPI、emptyDir、persistentVolumeClaim、secret 和 projected。

    主机网络

    • HostPorts , 默认为 emptyHostPortRange 列表通过 min(包含) and max(包含) 来定义,指定了被允许的主机端口。

    允许的主机路径

    • AllowedHostPaths 是一个被允许的主机路径前缀的白名单。空值表示所有的主机路径都可以使用。

    许可

    包含 PodSecurityPolicy许可控制,允许控制集群资源的创建和修改,基于这些资源在集群范围内被许可的能力。

    许可使用如下的方式为 Pod 创建最终的安全上下文:1. 检索所有可用的 PSP。1. 生成在请求中没有指定的安全上下文设置的字段值。1. 基于可用的策略,验证最终的设置。

    如果某个策略能够匹配上,该 Pod 就被接受。如果请求与 PSP 不匹配,则 Pod 被拒绝。

    Pod 必须基于 PSP 验证每个字段。

    创建一个策略和一个 Pod

    在一个文件中定义 PodSecurityPolicy 对象实例。这里的策略只是用来禁止创建有特权要求的 Pods。

    policy/example-psp.yamlPod 安全策略 - 图1
    1. apiVersion: policy/v1beta1
    2. kind: PodSecurityPolicy
    3. metadata:
    4. name: example
    5. spec:
    6. privileged: false # Don't allow privileged pods!
    7. # The rest fills in some required fields.
    8. seLinux:
    9. rule: RunAsAny
    10. supplementalGroups:
    11. rule: RunAsAny
    12. runAsUser:
    13. rule: RunAsAny
    14. fsGroup:
    15. rule: RunAsAny
    16. volumes:
    17. - '*'

    使用 kubectl 执行创建操作:

    1. kubectl-admin create -f example-psp.yaml

    获取 Pod 安全策略列表

    获取已存在策略列表,使用 kubectl get

    1. $ kubectl get psp
    2. NAME PRIV CAPS SELINUX RUNASUSER FSGROUP SUPGROUP READONLYROOTFS VOLUMES
    3. permissive false [] RunAsAny RunAsAny RunAsAny RunAsAny false [*]
    4. privileged true [] RunAsAny RunAsAny RunAsAny RunAsAny false [*]
    5. restricted false [] RunAsAny MustRunAsNonRoot RunAsAny RunAsAny false [emptyDir secret downwardAPI configMap persistentVolumeClaim projected]

    修改 Pod 安全策略

    通过交互方式修改策略,使用 kubectl edit

    1. $ kubectl edit psp permissive

    该命令将打开一个默认文本编辑器,在这里能够修改策略。

    删除 Pod 安全策略

    一旦不再需要一个策略,很容易通过 kubectl 删除它:

    1. $ kubectl delete psp permissive
    2. podsecuritypolicy "permissive" deleted

    启用 Pod 安全策略

    为了能够在集群中使用 Pod 安全策略,必须确保满足如下条件:

    • 已经启用 API 类型 extensions/v1beta1/podsecuritypolicy(仅对 1.6 之前的版本)
    • 已经启用许可控制器 PodSecurityPolicy
    • 已经定义了自己的策略

    使用 RBAC

    在 Kubernetes 1.5 或更新版本,可以使用 PodSecurityPolicy 来控制,对基于用户角色和组的已授权容器的访问。访问不同的 PodSecurityPolicy 对象,可以基于认证来控制。基于 Deployment、ReplicaSet 等创建的 Pod,限制访问 PodSecurityPolicy 对象,Controller Manager 必须基于安全 API 端口运行,并且不能够具有超级用户权限。

    PodSecurityPolicy 认证使用所有可用的策略,包括创建 Pod 的用户,Pod 上指定的服务账户(Service Account)。当 Pod 基于 Deployment、ReplicaSet 创建时,它是创建 Pod 的 Controller Manager,所以如果基于非安全 API 端口运行,允许所有的 PodSecurityPolicy 对象,并且不能够有效地实现细分权限。用户访问给定的 PSP 策略有效,仅当是直接部署 Pod 的情况。更多详情,查看 PodSecurityPolicy RBAC 示例,当直接部署 Pod 时,应用 PodSecurityPolicy 控制基于角色和组的已授权容器的访问 。

    反馈

    此页是否对您有帮助?

    感谢反馈。如果您有一个关于如何使用 Kubernetes 的特定的、需要答案的问题,可以访问Stack Overflow.在 GitHub 仓库上登记新的问题报告问题或者提出改进建议.