Kubernetes：创建和分配Kubernetes Pod安全策略

客官°小女子只卖身不卖艺 2023-02-09 14:12 8阅读 0赞

**目录**

Pod Security Policies（PSP）

Pod的安全策略配置

1.PodSecurityPolicy的工作机制

2.PodSecurityPolicy配置详情

2.1.特权模式相关配置

2.2.宿主机资源相关配置

2.3.用户和组相关配置

2.4.提升权限相关配置

2.5.Linux能力相关配置

2.6.SELinux相关配置

2.7.其他Linux相关配置

示例的PodSecurityPolicy安全策略配置

例1：基本没有限制的安全策略，允许创建任意安全设置的Pod。

例2：要求Pod运行用户为非特权用户；禁止提升权限；不允许使用宿主机网络、端口号、IPC等资源；限制可以使用的Volume类型，等等。

分配Kubernetes Pod安全策略

Security Context

Container-level Security Context

Container级别可以设置的安全策略类型

Pod-level Security Context

Pod级别可以设置的安全策略类型

--------------------

# Pod Security Policies（PSP） #

> Pod Security Policies（PSP）是集群级的Pod安全策略，自动为集群内的Pod和Volume设置Security Context。
> 
> 使用PSP需要API Server开启extensions/v1beta1/podsecuritypolicy，并且配置PodSecurityPolicyadmission控制器。

# Pod的安全策略配置 #

*Pod 安全策略* 是集群级别的资源，它能够控制 Pod 运行的行为，以及它具有访问什么的能力。

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

## 1.PodSecurityPolicy的工作机制 ##

若想**启用PodSecurityPolicy机制**，则需要在kube-apiserver服务的启动参数--enable-admission-plugins中进行设置：

如果是高可用，所有apiserver均需要修改

kubectl edit pod -n kube-system kube-apiserver-k8s-master
    --enable-admission-plugins=PodSecurityPolicy

> kube-apiserver-k8s-master，值得是你apiserver组件的pod名称

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2ZseTkxMDkwNQ_size_16_color_FFFFFF_t_70][]

> **在开启PodSecurityPolicy准入控制器后，Kubernetes默认不允许创建任何Pod，需要创建PodSecurityPolicy策略和相应的RBAC授权策略（Authorizing Policies），Pod才能创建成功。**

例如，尝试创建如下Pod：

apiVersion: v1
    kind: Pod
    metadata:
      name: nginx
    spec:
      containers:
      - name: nginx
        image: nginx

使用Kubectl命令创建时，**系统将提示“禁止创建”的报错信息**。

接下来**创建一个PodSecurityPolicy**，配置文件psp-non-privileged.yaml的内容如下：

apiVersion: policy/v1beta1
    kind： PodSecurityPolicy
    metadata:
      name: psp-non-privileged
    spec:
      privileged: false # 不允许特权模式的Pod
      seLinux:
        rule: RunAsAny
      supplementalGroups:
        rule: RunAsAny
      runAsUser:
        rule: RunAsAny
      fsGroup:
        rule: RunAsAny
      volumes:
      - '*'

之后再次创建Pod既可成功。

上面的PodSecurityPolicy“psp-non-privileged”设置了privileged: false，表示不允许创建特权模式的Pod。

在下面的YAML配置文件pod-privileged.yaml中为Pod设置了特权模式：

apiVersion: v1
    kind: Pod
    metadata:
      name: nginx
    spec:
      containers:
      - name: nginx
        image: nginx
        securityContext:
          privileged: true

创建Pod时，**系统将提示“禁止创建特权模式的Pod”的报错信息.**

## 2.PodSecurityPolicy配置详情 ##

> 在PodSecurityPolicy对象中可以设置下列字段来控制Pod运行时的各种安全策略。

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

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

### 2.1.特权模式相关配置 ###

> privileged：是否允许Pod以特权模式运行。

### 2.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字段设置路径的前缀，并可以设置是否为只读属性，例子如下。

apiVersion: policy/v1beta1
    kind: PodSecurityPolicy
    metadata:
      name: allow-hostpath-volumes
    spec:
      volumes:
      - hostPath
      allowedHostPaths:
      - pathPrefix: "/foo"
        readOnly: true

结果为允许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的存储卷，设置允许使用的驱动类型，例子如下。

apiVersion: policy/v1beta1
    kind: PodSecurityPolicy
    metadata:
      name: allow-flex-volumes
    spec:
      volumes:
      - flexVolume
      allowedFlexVolumes:
      - driver: example/lvm
      - driver: example/cifs

### 2.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的用户都可以运行。

## 2.4.提升权限相关配置 ##

（1）**AllowPrivilegeEscalation：**设置容器内的子进程是否可以提升权限，通常在设置非root用户（MustRunAsNonRoot）时进行设置。  
（2）**DefaultAllowPrivilegeEscalation：**设置AllowPrivilegeEscalation的默认值，设置为disallow时，管理员还可以显式设置AllowPrivilegeEscalation来指定是否允许提升权限。

## 2.5.Linux能力相关配置 ##

（1）**AllowedCapabilities：**设置容器可以使用的Linux能力列表，设置为“\*”表示允许使用Linux的所有能力（如NET\_ADMIN、SYS\_TIME等）。  
（2）**RequiredDropCapabilities：**设置不允许容器使用的Linux能力列表。  
（3）**DefaultAddCapabilities：**设置默认为容器添加的Linux能力列表，例如SYS\_TIME等，Docker建议默认设置的Linux能力请查看https://docs.docker.com/engine/reference/run/\#runtime-privilege-and-linux-capabilities。

## 2.6.SELinux相关配置 ##

**seLinux：**设置SELinux参数，可以将规则字段（rule）的值设置为MustRunAs或RunAsAny。

>  *  MustRunAs：要求设置seLinuxOptions，系统将对Pod的securityContext.seLinuxOptions设置的值进行校验。
>  *  RunAsAny：不限制seLinuxOptions的设置。

## 2.7.其他Linux相关配置 ##

（1）**AllowedProcMountTypes：**设置允许的ProcMountTypes类型列表，可以设置allowedProcMountTypes或DefaultProcMount。  
（2）**AppArmor：**设置对容器可执行程序的访问控制权限，详情请参考https://kubernetes.io/docs/tutorials/clusters/apparmor/\#podsecuritypolicy-annotations  
（3）**Seccomp：**设置允许容器使用的系统调用（System Calls）的profile。  
（4）**Sysctl：**设置允许调整的内核参数，详情请参考https://kubernetes.io/docs/concepts/cluster-administration/sysctl-cluster/\#podsecuritypolicy

# 示例的PodSecurityPolicy安全策略配置 #

## 例1：基本没有限制的安全策略，允许创建任意安全设置的Pod。 ##

apiVersion: policy/v1beta1
    kind: PodSecurityPolicy
    metadata:
      name: privileged
      annotations:
        seccomp.security.alpha.kubernetes.io/allowedProfileNames: '*'
    spec:
      privileged: true
      allowPrivilegeEscalation: true
      allowedCapabilities:
      - '*'
      volumes:
      - '*'
      hostNetwork: true
      hostPorts:
      - min: 0
        max: 65535
      hostIPC: true
      hostPID: true
      runAsUser:
        rule: 'RunAsAny'
      seLinux:
        rule: 'RunAsAny'
      supplementalGroups:
        rule: 'RunAsAny'
      fsGroup:
        rule: 'RunAsAny'

## 例2：要求Pod运行用户为非特权用户；禁止提升权限；不允许使用宿主机网络、端口号、IPC等资源；限制可以使用的Volume类型，等等。 ##

apiVersion: policy/v1beta1
    kind: PodSecurityPolicy
    metadata:
      name: restricted
      annotations:
        seccomp.security.alpha.kubernetes.io/allowedProfileNames: 'docker/default'
        apparmor.security.beta.kubernetes.io/allowedProfileNames: 'runtime/default'
        seccomp.security.alpha.kubernetes.io/defaultProfileName: 'docker/default'
        apparmor.security.beta.kubernetes.io/dafaultProfileName: 'runtime/default'
    spec:
      privileged: false
      allowPrivilegeEscalation: false
      requiredDropCapabilities:
      - ALL
      volumes:
      - 'configMap'
      - 'emptyDir'
      - 'projected'
      - 'secret'
      - 'downwardAPI'
      - 'persistentVolumeClaim'
      hostNetwork: false
      hostIPC: false
      hostPID: false
      runAsUser:
        rule: 'MustRunAsNonRoot'
      seLinux:
        rule: 'MustRunAs'
        ranges:
        - min: 1
          max: 65535
      fsGroup:
        rule: 'MustRunAs'
        ranges:
        - min: 1
          max: 65535
      readOnlyRootFilesystem: false

# 分配Kubernetes Pod安全策略 #

> **Kubernetes建议使用RBAC授权机制来设置针对Pod安全策略的授权，通常应该对Pod的ServiceAccount进行授权。**
> 
> **角色的访问控制（RBAC）是kubernetes标准的授权模式，并且很容应用于Pod安全策略。**借助RBAC，你可以将Pod安全策略分配给应用。
> 
> 为此，我们将创建一个新的YAML文件，该文件不仅会创建集群范围的角色（使用ClusterRole定义），还将创建集群绑定（使用ClusterRoleBinding定义），以向每个经过身份验证的用户授予访问权限。

例如，可以创建如下ClusterRole（也可以创建Role）并将其设置为允许使用PodSecurityPolicy：

kind: ClusterRole
    apiVersion: rbac.authorization.k8s.io/v1
    metadata:
      name: <role name>
    rules:
    - apiGroup: ['policy']
      resources: ['podsecuritypolicies']
      verbs: ['use']
      resourceNames:
      - <list of policies to authorize>  # 允许使用的PodSecurityPolicy列表

然后创建一个ClusterRoleBinding与用户和ServiceAccount进行绑定：

kind: ClusterRoleBinding
    apiVersion: rbac.authorization.k8s.io/v1
    metadata:
      name: <binding name>
    roleRef:
      kind: ClusterRole
      name: <roke name>  # 之前创建的ClusterRole名称
      apiGroup: rbac.authorization.k8s.io
    subjects:
    # 对特定Namespace中的ServiceAccount进行授权
    - kind: ServiceAccount
      name: <authorized servie account name> # ServiceAccount 的名称
      namespace: <authorized pod namespace> # Namespace的名称
    # 对特定用户进行授权（不推荐）
    - kind: User
      apiGroup: rbac.authorization.k8s.io
      name: <authorized user name>  # 用户名

**也可以创建RoleBinding对与该RoleBinding相同的Namespace中的Pod进行授权**，通常可以与某个系统级别的Group关联配置，例如：

kind: RoleBinding
    apiVersion: rbac.authorization.k8s.io/v1
    metadata:
      name: <binding name>
      namespace: <binding namespace>  # 该RoleBinding 所属的Namespace
    roleRef:
      kind: Role
      name: <role name>
      apiGroup: rbac.authorization.k8s.io
    subjects:
    # 授权该Namespace中的全部ServiceAccount
    - kind: Group
      apiGroup: rbac.authorization.k8s.io
      name: system:serviceaccounts
    # 授权该Namespace中的全部哦用户
    - kind: Group
      apiGroup: rbac.authorization.k8s.io
      name: system:authenticated

# Security Context #

> 通过上文，我们了解了**PodSecurityPolicy策略，知道了**
> 
>  *  **在系统管理员对Kubernetes集群中设置了PodSecurityPolicy策略之后**，系统将对Pod和Container级别的安全设置进行校验，对于不满足PodSecurityPolicy安全策略的Pod，系统将拒绝创建。
> 
> 但除此之外还有个，**securityContext**
> 
>  *  **Pod和容器的安全策略可以在Pod或Container的securityContext字段中进行设置**，如果在Pod和Container级别都设置了相同的安全类型字段，容器将使用Container级别的设置。

Security Context的目的是限制不可信容器的行为，保护系统和其他容器不受其影响。

要为Pod指定安全设置，请`securityContext`在Pod规范中包括该字段。该`securityContext`字段是 [PodSecurityContext][]对象。

Kubernetes提供了三种配置Security Context的方法：

>  *  Container-level Security Context：仅应用到指定的容器
>  *  Pod-level Security Context：应用到Pod内所有容器以及Volume
>  *  Pod Security Policies（PSP）：应用到集群内部所有Pod以及Volume

## Container-level Security Context ##

> Container-level Security Context仅应用到指定的容器上，并且不会影响Volume。

### Container级别可以设置的安全策略类型 ###

>  *  runAsUser：容器内运行程序的用户ID。
>  *  runAsGroup：容器内运行程序的用户组ID。
>  *  runAsNonRoot：是否必须以非root用户运行程序。
>  *  privileged：是否以特权模式运行。
>  *  allowPrivilegeEscalation：是否允许提升权限。
>  *  readOnlyRootFilesystem：根文件系统是否为只读属性。
>  *  capabilities：Linux能力列表。
>  *  seLinuxOptions：SELinux相关设置。

比如

**例1：Container级别的安全设置，作用于特定的容器。**

apiVersion: v1
    kind: Pod
    metadata:
      name: security-context-demo-2
    spec:
      securityContext:
        runAsUser: 1000
      containers:
      - name: sec-ctx-demo-2
        image: tomcat
        securityContext:
          runAsUser: 2000
          allowPrivilegeEscalation: false

创建该Pod之后进入容器环境，查看到运行进程的用户ID为2000：

**例2：为Container设置可用的Linux能力，为容器设置允许使用的Linux能力包括NET\_ADMIN和SYS\_TIME。**

apiVersion: v1
    kind: Pod
    metadata:
      name: security-context-demo-3
    spec:
      containers:
      - name: sec-ctx-3
        image: tomcat
        securityContext:
          capabilities:
            add: ["NET_ADMIN","SYS_TIME"]

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2ZseTkxMDkwNQ_size_16_color_FFFFFF_t_70 1][]

创建该Pod之后进入容器环境，查看1号进程的Linux能力设置：

## Pod-level Security Context ##

> Pod-level Security Context应用到Pod内所有容器，并且还会影响Volume（包括fsGroup和selinuxOptions）。

apiVersion: v1
    kind: Pod
    metadata:
      name: security-context-demo
    spec:
      securityContext:
        runAsUser: 1000
        runAsGroup: 3000
        fsGroup: 2000
      volumes:
      - name: sec-ctx-vol
        emptyDir: {}
      containers:
      - name: sec-ctx-demo
        image: tomcat
        volumeMounts:
        - name: sec-ctx-vol
          mountPath: /data/demo
        securityContext:
          allowPrivilegeEscalation: false

在spec.securityContext中设置了如下参数。

>  *  runAsUser=1000：所有容器都将以User ID 1000运行程序，所有新生成文件的User ID也被设置为1000。
>  *  runAsGroup=3000：所有容器都将以Group ID 3000运行程序，所有新生成文件的Group ID也被设置为3000。
>  *  fsGroup=2000：挂载的卷“/data/demo”及其中创建的文件都将属于Group ID 2000。

*  创建该Pod之后进入容器环境，查看到运行进程的用户ID为1000：
 *  查看从Volume挂载到容器的/data/demo目录，其Group ID为2000
 *  在该目录下创建一个新文件，可见其用户ID为1000，组ID为2000：

### Pod级别可以设置的安全策略类型 ###

>  *  runAsUser：容器内运行程序的用户ID。
>  *  runAsGroup：容器内运行程序的用户组ID。
>  *  runAsNonRoot：是否必须以非root用户运行程序。
>  *  fsGroup：SELinux相关设置。
>  *  seLinuxOptions：SELinux相关设置。
>  *  supplementalGroups：允许容器使用的其他用户组ID。
>  *  sysctls：设置允许调整的内核参数。

参考链接：

[https://kubernetes.io/docs/tasks/configure-pod-container/security-context/][https_kubernetes.io_docs_tasks_configure-pod-container_security-context]

[https://kubernetes.io/zh/docs/concepts/policy/pod-security-policy/][https_kubernetes.io_zh_docs_concepts_policy_pod-security-policy]

[https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.18/\#securitycontext-v1-core][https_kubernetes.io_docs_reference_generated_kubernetes-api_v1.18_securitycontext-v1-core]

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2ZseTkxMDkwNQ_size_16_color_FFFFFF_t_70]: https://img-blog.csdnimg.cn/20200519151121653.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2ZseTkxMDkwNQ==,size_16,color_FFFFFF,t_70
[PodSecurityContext]: https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.18/#podsecuritycontext-v1-core
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2ZseTkxMDkwNQ_size_16_color_FFFFFF_t_70 1]: https://img-blog.csdnimg.cn/20200519163519448.png?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2ZseTkxMDkwNQ==,size_16,color_FFFFFF,t_70
[https_kubernetes.io_docs_tasks_configure-pod-container_security-context]: https://kubernetes.io/docs/tasks/configure-pod-container/security-context/
[https_kubernetes.io_zh_docs_concepts_policy_pod-security-policy]: https://kubernetes.io/zh/docs/concepts/policy/pod-security-policy/
[https_kubernetes.io_docs_reference_generated_kubernetes-api_v1.18_securitycontext-v1-core]: https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.18/#securitycontext-v1-core