vlambda博客
学习文章列表

为 Kubernetes 集群启用 Pod 安全策略


最近有客户反馈在开启了安全策略的集群中部署产品失败,因此研究了一下 Kubernetes 提供的 pod 安全策略。

文中的演示和示例均在 v1.18.17 集群中通过验证。

Pod Security Policies

Pod Security Policies (下文简称 psp 或 pod 安全策略)是一种集群级别的全局资源,能够对 pod 的创建和更新进行细粒度的授权控制。具体来说,一个 psp 对象定义了一组安全性条件,一个 pod 的 spec 字段必须满足这些条件以及适用相关字段的默认值,其创建或更新请求才会被 apiserver 所接受。

具体的 pod 字段和安全条件可见文档 what-is-a-pod-security-policy[1]

启用 Pod Security Policies

Kubernetes 默认不开启 pod 安全策略功能,在集群中启用 pod 安全策略的步骤大体上分为三步:

  1. 授予用户访问安全策略资源的权限,通常会授权给整个命名空间的 service account。
  2. 在集群中创建指定的安全策略资源。
  3. 启用 apiserver 的 admission-controller 插件。

注意步骤 1、2 的顺序不重要,因为它们不会产生实际影响。

但步骤 3 推荐在最后一步执行,否则一旦启用 admission-controller 插件,如果集群中没有可用的 pod 安全策略或者未对安全策略资源预先授权,所有 pod 的创建都会被拒绝,包括 kube-system 命名空间下的系统管理组件如 apiserver(但由于是受 kubelet 管理的静态 pod 实际上容器依然会运行)。

RBAC 身份认证

  1. 创建可访问所有安全策略资源的 ClusterRole:
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: all-psp
rules:
- apiGroups: ['policy']
  resources: ['podsecuritypolicies']
  verbs:     ['use']
  1. 通过 ClusterRoleBinding 将创建的角色绑定到指定命名空间下的所有 service account(也可以授权给指定的 sa 或者用户):
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: cluster-psp-bind
roleRef:
  kind: ClusterRole
  name: all-psp
  apiGroup: rbac.authorization.k8s.io
subjects:
# 授权给指定命名空间下的所有 service account(推荐做法):
- kind: Group
  apiGroup: rbac.authorization.k8s.io
  name: system:nodes
  namespace: kube-system
- kind: Group
  apiGroup: rbac.authorization.k8s.io
  name: system:serviceaccounts:kube-system
- kind: Group
  apiGroup: rbac.authorization.k8s.io
  name: system:serviceaccounts:security-test
# 也可授权给指定的 service account 或者用户(不推荐):
- kind: ServiceAccount
  name: <authorized service account name>
  namespace: <authorized pod namespace>
- kind: User
  apiGroup: rbac.authorization.k8s.io
  name: <authorized user name>
# 授权给所有的 service accounts:
- kind: Group
  apiGroup: rbac.authorization.k8s.io
  name: system:serviceaccounts
# 授权给所有已认证的用户:
- kind: Group
  apiGroup: rbac.authorization.k8s.io
  name: system:authenticated

创建安全策略资源

  1. 在集群中创建一个 PodSecurityPolicy 资源。宽松权限版本:
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'
  1. 严格权限版本:
apiVersion: policy/v1beta1
kind: PodSecurityPolicy
metadata:
  name: restricted
  annotations:
    seccomp.security.alpha.kubernetes.io/allowedProfileNames: 'docker/default,runtime/default'
    apparmor.security.beta.kubernetes.io/allowedProfileNames: 'runtime/default'
    apparmor.security.beta.kubernetes.io/defaultProfileName:  'runtime/default'
spec:
  privileged: false
  # Required to prevent escalations to root.
  allowPrivilegeEscalation: false
  requiredDropCapabilities:
    - ALL
  # Allow core volume types.
  volumes:
    - 'configMap'
    - 'emptyDir'
    - 'projected'
    - 'secret'
    - 'downwardAPI'
    # Assume that ephemeral CSI drivers & persistentVolumes set up by the cluster admin are safe to use.
    - 'csi'
    - 'persistentVolumeClaim'
    - 'ephemeral'
  hostNetwork: false
  hostIPC: false
  hostPID: false
  runAsUser:
    # Require the container to run without root privileges.
    rule: 'MustRunAsNonRoot'
  seLinux:
    # This policy assumes the nodes are using AppArmor rather than SELinux.
    rule: 'RunAsAny'
  supplementalGroups:
    rule: 'MustRunAs'
    ranges:
      # Forbid adding the root group.
      - min: 1
        max: 65535
  fsGroup:
    rule: 'MustRunAs'
    ranges:
      # Forbid adding the root group.
      - min: 1
        max: 65535
  readOnlyRootFilesystem: false

启用 admission controller 插件

启用 admission controller 的 psp 插件有两种方式:

  1. 在已存在的集群中通过修改 apiserver 的静态 manifest 文件,为 apiserver 增加启动参数 enable-admission-plugins=PodSecurityPolicy。kubelet 会自动检测到变更并重启 apiserver。下面的示例使用 sed 对原有参数进行了替换:
$ sed -i 's/enable-admission-plugins=NodeRestriction/enable-admission-plugins=NodeRestriction,PodSecurityPolicy/' /etc/kubernetes/manifests/kube-apiserver.yaml
  1. 或者在初始化集群时,在 kubeadm 配置文件中添加额外参数。
apiVersion: kubeadm.k8s.io/v1beta2
kind: ClusterConfiguration
apiServer:
 extraArgs:
    enable-admission-plugins: "PodSecurityPolicy"

验证 psp 的安全限制

我们在上文授权过的 security-test 命名空间进行测试,验证 psp 对 pod 的限制条件。

首先确保在集群中应用了严格版本的 psp 资源,然后尝试通过 deployment 创建一个需要使用 hostNetwork 的 pod:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-hostnetwork
spec:
  selector:
    matchLabels:
      run: nginx
  template:
    metadata:
      labels:
        run: nginx
    spec:
      hostNetwork: true
      containers:
      - image: nginx
        imagePullPolicy: Always
        name: nginx-privileged

创建并查看结果:

$ kubectl create -f hostnetwork-pod.yaml -n security-test
deployment.apps/nginx-hostnetwork created
$ kubectl get deploy -n security-test nginx-hostnetwork
NAME                READY   UP-TO-DATE   AVAILABLE   AGE
nginx-hostnetwork   0/1     0            0           17s
$ kubectl -n security-test get event | grep "pod security policy"
103s        Warning   FailedCreate             deployment/nginx-hostnetwork                                Error creating: pods "nginx-hostnetwork-" is forbidden: unable to validate against any pod security policy: [spec.securityContext.hostNetwork: Invalid value: true: Host network is not allowed to be used]

局限性

如果有 pod 违反了安全策略,解决方案是要么调整 pod 的规格,要么修改 pod 安全策略资源。psp 资源是全局生效的,不能针对不同的命名空间设置不同的安全策略级别,这是一个很明显的局限性。

另外对 psp 的授权机制也比较复杂。如果没有授权或者未创建安全策略,结果是所有 pod 被拒绝,这也导致在集群中默认开启该功能的操作难度很大。

从 Kubernetes v1.21 开始,Pod Security Policy 将被弃用,并将在 v1.25 中删除。Kubernetes 引入了 Pod Security Admission 作为其替代者,我们将在下文中详细解析。

Pod Security Admission

为什么要替换 psp

KEP-2579[2] 详细阐述了使用 Pod Security Admission 替代 Pod Security Policy 的三点主要理由:

  1. 将策略与用户或 service account 绑定的模型削弱了安全性。
  2. 功能无法流畅切换,在没有安全策略的情况下无法关闭。
  3. API 不一致且缺乏灵活性。

新的 Pod Security Admission 机制在易用性和灵活性上都有了很大提升,从使用角度有以下四点显着不同:

  1. 可以在集群中默认开启,只要不添加约束条件就不会触发对 pod 的校验。
  2. 只在命名空间级别生效,可以为不同命名空间通过添加标签的方式设置不同的安全限制。
  3. 可以为特定的用户、命名空间或者运行时设置豁免规则。
  4. 根据实践预设了三种安全等级,不需要由用户单独去设置每一个安全条件。

工作方式

Pod Security Admission 将原来 Pod Security Policy 的安全条件划分成三种预设的安全等级:

  • privileged: 不受限,向 pod 提供所有可用的权限。
  • baseline:最低限度的限制策略,防止已知的特权升级。
  • restricted:严格限制策略,遵循当前 Pod 加固的最佳实践。

三种等级从宽松到严格递增,各自包含了不同限度的安全条件[3],适用于不同的 pod 工作场景。此外还可以将安全等级设置为固定的 Kubernetes 版本,这样即使集群升级到了新的版本且新版本的安全等级定义发生变化,依然可以按旧版本的安全条件对 pod 进行约束。

当 pod 与安全等级冲突时,我们可通过三种模式来选择不同的处理方式:

  • enforce:只允许符合安全等级要求的 pod,拒绝与安全等级冲突的 pod。
  • audit:只将安全等级冲突记录在集群 event 中,不会拒绝 pod。
  • warn:与安全等级冲突时会向用户返回一个警告信息,但不会拒绝 pod。

audit 和 warn 模式是独立的,如果同时需要两者的功能必须分别设置两种模式。

应用安全策略不再需要创建单独的集群资源,只需要为命名空间设置控制标签:

pod-security.kubernetes.io/<mode>: <level>
pod-security.kubernetes.io/<mode>-version: <version>

下文会有更完整的示例。

在旧版本启用 psa

虽然 Pod Security Admission 是一个在 Kubernetes v1.22 引入的功能,但旧版本可以通过安装 PodSecurity admission webhook 来启用该功能,具体步骤如下:

$ git clone https://github.com/kubernetes/pod-security-admission.git
cd pod-security-admission/webhook
$ make certs
$ kubectl apply -k .

以上来自官方文档的步骤在 v1.18.17 会有两个兼容性问题,具体问题和解决方案如下:

  1. kubectl 内置的 kustomize 版本不支持 "replacements" 字段:

    $ kubectl apply -k .
    error: json: unknown field "replacements"

    解决方案:安装最新版本的 kusomize 然后在同一目录执行

$ kustomize build . | kubectl apply -f -
  1. manifest/50-deployment.yaml 文件中定义的 Deployment.spec.template.spec.containers[0].securityContext 字段在 v1.19 版本才开始引入,因此 v1.18 需要将该字段修改为对应的 annotation 版本,详见 Seccomp [4]
error: error validating "STDIN": error validating data: ValidationError(Deployment.spec.template.spec.containers[0].securityContext): unknown field "seccompProfile" in io.k8s.api.core.v1.SecurityContext; if you choose to ignore these errors, turn validation off with --validate=false

验证 psa 的安全限制

首先创建一个新的命名空间 psa-test 用于测试,并将其定义强制应用 baseline 安全等级,并对 restricted 等级进行警告和审计:

apiVersion: v1
kind: Namespace
metadata:
  name: psa-test
  labels:
    pod-security.kubernetes.io/enforce: baseline
    pod-security.kubernetes.io/enforce-version: v1.18

    # We are setting these to our _desired_ `enforce` level.
    pod-security.kubernetes.io/audit: restricted
    pod-security.kubernetes.io/audit-version: v1.18
    pod-security.kubernetes.io/warn: restricted
    pod-security.kubernetes.io/warn-version: v1.18

接着在该命名空间中创建上文示例中用过的 deployment:

$ kubectl create -f hostnetwork-pod.yaml -n psa-test
deployment.apps/nginx-hostnetwork created
$ kubectl get deploy -n psa-test nginx-hostnetwork
NAME                READY   UP-TO-DATE   AVAILABLE   AGE
nginx-hostnetwork   0/1     0            0           17s
$ kubectl -n psa-test get event | grep PodSecurity
104s        Warning   FailedCreate        replicaset/nginx-hostnetwork-644cdd6598   Error creating: admission webhook "pod-security-webhook.kubernetes.io" denied the request: pods "nginx-hostnetwork-644cdd6598-7rb5m" is forbidden: violates PodSecurity "baseline:v1.23": host namespaces (hostNetwork=true)

参考链接

  • KEP-2579: Pod Security Admission Control [5]
  • Pod Security Admission | Kubernetes [6]
  • Pod Security Standards | Kubernetes [7]

引用链接

[1]

what-is-a-pod-security-policy: https://kubernetes.io/docs/concepts/policy/pod-security-policy/#what-is-a-pod-security-policy

[2]

KEP-2579: https://github.com/kubernetes/enhancements/tree/master/keps/sig-auth/2579-psp-replacement

[3]

不同限度的安全条件: https://kubernetes.io/docs/concepts/security/pod-security-standards/#profile-details

[4]

0].securityContext` 字段在 v1.19 版本才开始引入,因此 v1.18 需要将该字段修改为对应的 annotation 版本,详见 [Seccomp: https://kubernetes.io/docs/concepts/policy/pod-security-policy/#seccomp

[5]

KEP-2579: Pod Security Admission Control: https://github.com/kubernetes/enhancements/tree/master/keps/sig-auth/2579-psp-replacement

[6]

Pod Security Admission | Kubernetes: https://kubernetes.io/docs/concepts/security/pod-security-admission/

[7]

Pod Security Standards | Kubernetes: https://kubernetes.io/docs/concepts/security/pod-security-standards/#profile-details


原文链接:https://www.waynerv.com/posts/enable-pod-security-policy-for-cluster/


为 Kubernetes 集群启用 Pod 安全策略

为 Kubernetes 集群启用 Pod 安全策略


你可能还喜欢

eBPF 完全入门指南.pdf(万字长文)

为 Kubernetes 集群启用 Pod 安全策略

云原生是一种信仰 🤘

后台回复◉k8s◉获取史上最方便快捷的 Kubernetes 高可用部署工具,只需一条命令,连 ssh 都不需要!



为 Kubernetes 集群启用 Pod 安全策略

点击 "阅读原文" 获取更好的阅读体验!