华为云用户手册

判断方法 您可以在节点上执行命令查看容器引擎使用的cgroup。 容器引擎为containerd的节点，执行以下命令： crictl info |grep -i systemdCgroup 显示如下： "systemdCgroup": false 容器引擎为docker的节点，执行以下命令： docker info |grep "Cgroup" 显示如下： Cgroup Driver: cgroupfs 表明容器引擎使用的cgroup系统为cgroupfs，并未使用systemd cgroup，不受此漏洞影响。

漏洞详情 runc是一个基于OCI标准实现的一个轻量级容器运行工具，是Docker、Containerd、Kubernetes等容器软件的核心基础组件。近日，runc社区发布最新版本，修复了一处高危级别的容器逃逸漏洞（CVE-2024-21626）。由于内部文件描述符泄漏，攻击者可通过控制容器进程的工作目录，或命令路径，将其设置为文件描述符的父级目录下的路径，读写主机任意文件，实现容器逃逸。 详细信息请参见：runc容器逃逸漏洞预警（CVE-2024-21626）

漏洞影响 Linux系统内核在3.15-6.8中的netfilter: nf_tables组件存在释放后重利用漏洞，nft_verdict_init() 函数允许在钩子判定中使用正值作为丢弃错误，当 NF_DROP 发出类似于 NF_ACCEPT 的丢弃错误时，nf_hook_slow() 函数会导致双重释放漏洞，本地攻击者利用此漏洞可将普通用户权限提升至 root 权限。 该漏洞是一个本地提权漏洞，需要攻击者先渗透到集群的node节点，利用难度较高。

判断方法 对于1.23及以下版本的CCE集群、 CCE Turbo 集群，使用web-terminal、cloudshell或者配置kubectl连接集群，运行以下命令，确认是否运行聚合API Server： kubectl get apiservices.apiregistration.k8s.io -o=jsonpath='{range .items[?(@.spec.service)]}{.metadata.name}{"\n"}{end}'

漏洞详情 业界披露了Linux Kernel openvswitch模块权限提升漏洞（CVE-2022-2639）的漏洞细节。由于 openvswitch模块中reserve_sfa_size()函数在使用过程中存在缺陷，导致本地经过身份认证的攻击者可以利用漏洞提升至root权限。目前漏洞poc已公开，风险较高。 表1 漏洞信息 漏洞类型 CVE-ID 漏洞级别 披露/发现时间 权限提升 CVE-2022-2639 高 2022-09-01

漏洞详情 containerd开源社区中披露了一个安全漏洞，在containerd创建容器的场景，非root容器进程的初始inheritalbe capability不为空，可能会造成在execve执行可执行文件时提升到允许的cap集合。该问题已被收录为CVE-2022-24769。 表1 漏洞信息 漏洞类型 CVE-ID 漏洞级别 披露/发现时间 权限提升 CVE-2022-24769 低 2022-3-24

漏洞影响 containerd创建容器时默认把 Linux Process capabilities配置到 Inheritable 集合上，这会导致在容器内的进程在以 Non-Root 用户 execve() 执行可执行文件时Inheritable和文件的Inheritable集合的交集被添加到执行完execve后的进程的Permited集合中，出现非预期的“越权“行为。需要说明的是，这个越权并没有突破 execve 前的进程权限，仅仅是继承之前的 capabilities。 该漏洞的影响范围如下： 1. CCE Turbo集群，使用了低于1.4.1-98版本的containerd作为kuberentes CRI运行时。 2. CCE集群containerd版本低于1.5.11以下的集群。

漏洞详情 crowdstrike安全团队披露CRI-O 1.19版本中存在一个安全漏洞，攻击者可以利用该漏洞绕过保护措施并在主机上设置任意内核参数。这将导致任何有权在使用CRI-O的Kubernetes集群上部署Pod的用户都可以滥用kernel.core_pattern内核参数，在集群中的任何节点上以root身份实现容器逃逸和执行任意代码。 该问题已被收录为CVE-2022-0811。 表1 漏洞信息 漏洞类型 CVE-ID 漏洞级别 披露/发现时间 容器逃逸 CVE-2022-0811 高 2021-03-16

相关链接 Red Hat社区漏洞公告：https://access.redhat.com/security/cve/cve-2022-0811 cr8escape: New Vulnerability in CRI-O Container Engine Discovered by CrowdStrike：https://www.crowdstrike.com/blog/cr8escape-new-vulnerability-discovered-in-cri-o-container-engine-cve-2022-0811/

相关链接 内核修复commit：https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=24f6008564183aa120d07c03d9289519c2fe02af Red Hat社区漏洞公告：https://access.redhat.com/security/cve/cve-2022-0492

漏洞影响 该漏洞为Linux内核权限校验漏洞，根因为没有针对性的检查设置release_agent文件的进程是否具有正确的权限。在受影响的OS节点上，工作负载使用了root用户运行进程（或者具有CAP_SYS_ADMIN权限），并且未配置seccomp时将受到漏洞影响。 CCE集群受该漏洞影响的范围如下： x86场景EulerOS 2.5和CentOS镜像不受该漏洞影响。 内核版本小于4.19.36-vhulk1907.1.0.h962.eulerosv2r8.aarch64的EulerOS arm版本。 内核版本小于4.18.0-147.5.1.6.h541.eulerosv2r9.x86_64的EulerOS x86版本。 内核版本为4.15.0-136-generic以及以下内核版本的Ubuntu节点。

漏洞详情 国外安全研究人员William Liu和Jamie Hill-Daniel发现Linux内核中包含一个整数溢出漏洞，可导致写操作越界。本地攻击者可以使用这一点导致拒绝服务(系统崩溃)或执行任意代码，在容器场景下拥有CAP_SYS_ADMIN权限的用户可导致容器逃逸到宿主机。目前已存在poc，但尚未发现已公开的利用代码。 表1 漏洞信息 漏洞类型 CVE-ID 漏洞级别 披露/发现时间 资源管理错误 CVE-2022-0185 高 2022-01-27

相关链接 https://blog.aquasec.com/cve-2022-0185-linux-kernel-container-escape-in-kubernetes https://ubuntu.com/security/CVE-2022-0185 https://access.redhat.com/security/cve/CVE-2022-0185 https://www.openwall.com/lists/oss-security/2022/01/18/7

漏洞处理方案 目前RedHat、Ubuntu、Debian、SUSE等各大Linux厂商均已发布补丁版本修复了该漏洞，请受影响的用户升级到安全版本，若无法及时升级，可参考厂商官方提供的建议进行缓解。 RedHat；Ubuntu：USN-5252-1、USN-5252-2；Debian、SUSE EulerOS已发布补丁，升级polkit rpm包即可。 升级方法如下 yum clean all yum makecache yum update polkit rpm -qa | grep polkit 检查是否已经修复为对应版本 EulerOS 2.10 修复版本为polkit-0.116-6.h4 EulerOS 2.9 修复版本为polkit-0.116-5.h7 EulerOS 2.8 修复版本为polkit-0.115-2.h14 EulerOS 2.5 修复版本为polkit-0.112-14.h15 若系统没有可用的补丁，可通过将pkexec中的SUID-bit删除进行临时规避，命令如：# chmod 0755 /usr/bin/pkexec 注：修复漏洞前请将资料备份，并进行充分测试。

漏洞详情 国外安全研究团队披露在polkit的pkexec程序中存在一处权限提升漏洞（CVE-2021-4034，亦称PwnKit），攻击者通过在其默认配置中利用此漏洞实现用任何非特权用户获取易受攻击主机的完全root权限，目前漏洞POC/EXP已公开，风险较高。 Polkit（PolicyKit）是一个用于在类Unix操作系统中控制系统范围权限的组件。pkexec是Plokit框架中的一部分，执行具有提升权限的命令，是sudo的替代方案。请使用Polkit的用户及时安排自检并做好安全加固。 参考链接：https://www.qualys.com/2022/01/25/cve-2021-4034/pwnkit.txt 表1 漏洞信息 漏洞类型 CVE-ID 漏洞级别 披露/发现时间 权限提升 CVE-2021-4034 高 2022-01-28

漏洞详情 Kubernetes开源社区中披露了1个ingress-nginx漏洞，用户通过Ingress 对象的“spec.rules[].http.paths[].path”字段可以获取ingress-controller使用的credentials。这个credentials可以获取集群中所有namespace的secrets。该漏洞被收录为CVE-2021-25748。 表1 漏洞信息 漏洞类型 CVE-ID 漏洞级别 披露/发现时间 权限提升 CVE-2021-25748 中 2022-6-10

相关链接 CVE-2021-25745社区漏洞issue：https://github.com/kubernetes/ingress-nginx/issues/8502 CVE-2021-25746社区漏洞issue：https://github.com/kubernetes/ingress-nginx/issues/8503 社区已经发布版本修复: https://github.com/kubernetes/ingress-nginx/releases/tag/controller-v1.2.0

漏洞详情 Kubernetes开源社区中披露了2个nginx-ingress漏洞： 1. 漏洞CVE-2021-25745：用户有权限可以在创建/更新ingress时，利用‘spec.rules[].http.paths[].path’字段，获取到ingress-controller使用的凭证，这个凭证可以获取集群中所有命名空间的密钥。 2. 漏洞CVE-2021-25746：用户有权限可以在创建/更新ingress时，利用‘.metadata.annotations’字段，获取到ingress-controller使用的凭证，这个凭证可以获取集群中所有命名空间的密钥。 表1 漏洞信息 漏洞类型 CVE-ID 漏洞级别 披露/发现时间 权限提升 CVE-2021-25745 中 2022-4-16 权限提升 CVE-2021-25746 中 2022-4-16

漏洞修复方案 1. 漏洞CVE-2021-25745消减措施：通过实施准入策略，将'networking.k8s.io/Ingress'中的'spec.rules[].http.paths[].path'限制在已知安全字符中（参考社区最新规则，或者采用annotation-value-word-blocklist中的建议值）。 2. 漏洞CVE-2021-25746消减措施：通过实施准入策略，将'metadata.annotations'的值限制在已知的安全字符中（参考社区最新规则，或者采用annotation-value-word-blocklist中的建议值）。

漏洞详情 社区在 Kubernetes 中发现了一个安全问题，用户可以创建一个带有subPath volume挂载的容器，访问卷外的文件和目录，包括主机文件系统上的文件和目录。 容器使用subPath去挂载一些文件或者目录时，攻击者可能利用Symlink Exchange 访问除挂载目录之外的目录或者主机上的文件，造成越权。 表1 漏洞信息 漏洞类型 CVE-ID 漏洞级别 披露/发现时间 资源管理错误 CVE-2021-25741 中 2021-09-15

漏洞影响 该漏洞涉及VolumeSubpath特性开关开启场景（默认开启），可能造成以下影响： 若恶意用户可以创建一个带有子路径卷挂载的容器，则可以访问卷外的文件和目录，包括主机文件系统上的文件和目录。 集群管理员已限制创建 hostPath 挂载的能力的集群受到的影响最严重。利用该漏洞可以在不使用 hostPath 功能的情况下进行类似 hostPath 的访问，从而绕过限制。 在默认的 Kubernetes 环境中，漏洞利用可用于掩盖对已授予特权的滥用。

漏洞处理方案 您可以禁用 kubelet 上的VolumeSubpath feature gate，并删除任何使用subPath功能的现有 Pod。 以root用户登录CCE Node节点。 修改kubelet配置参数，关闭VolumeSubpath特性。 vi /opt/cloud/cce/kubernetes/kubelet/kubelet_config.yaml 添加VolumeSubpath: false字段 重启kubelet。 systemctl restart kubelet 确认kubelet新进程已启动，且已关闭VolumeSubpath。 vi /var/paas/sys/log/kubernetes/kubelet.log 搜索VolumeSubpath=false，如果能搜到说明关闭成功。 删除任何使用subPath功能的Pod。

VolumeSubpath特性开启或回退 修改kubelet配置文件，删除VolumeSubpath相关字段。 vi /opt/cloud/cce/kubernetes/kubelet/kubelet_config.yaml 重启kubelet。 systemctl restart kubelet 确认kubelet新进程已启动，且重启后的kubelet.log日志中无VolumeSubpath=false相关字段。

容器组（Pod） 容器组（Pod）是Kubernetes创建或部署的最小单位。一个Pod封装一个或多个容器（container）、存储资源（volume）、一个独立的网络IP以及管理控制容器运行方式的策略选项。 Pod使用主要分为两种方式： Pod中运行一个容器。这是Kubernetes最常见的用法，您可以将Pod视为单个封装的容器，但是Kubernetes是直接管理Pod而不是容器。 Pod中运行多个需要耦合在一起工作、需要共享资源的容器。通常这种场景下应用包含一个主容器和几个辅助容器（SideCar Container），如图1所示，例如主容器为一个web服务器，从一个固定目录下对外提供文件服务，而辅助容器周期性的从外部下载文件存到这个固定目录下。 图1 Pod 实际使用中很少直接创建Pod，而是使用Kubernetes中称为Controller的抽象层来管理Pod实例，例如Deployment和Job。Controller可以创建和管理多个Pod，提供副本管理、滚动升级和自愈能力。通常，Controller会使用Pod Template来创建相应的Pod。

使用环境变量 环境变量是容器运行环境中设定的一个变量。 环境变量为应用提供极大的灵活性，您可以在应用程序中使用环境变量，在创建容器时为环境变量赋值，容器运行时读取环境变量的值，从而做到灵活的配置，而不是每次都重新编写应用程序制作镜像。 环境变量的使用方法如下所示，配置spec.containers.env字段即可。 apiVersion: v1 kind: Pod metadata: name: nginx spec: containers: - image: nginx:alpine name: container-0 resources: limits: cpu: 100m memory: 200Mi requests: cpu: 100m memory: 200Mi env: # 环境变量 - name: env_key value: env_value imagePullSecrets: - name: default-secret 执行如下命令查看容器中的环境变量，可以看到env_key这个环境变量，其值为env_value。 $ kubectl exec -it nginx -- env PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin HOSTNAME=nginx TERM=xterm env_key=env_value 环境变量还可以引用ConfigMap和Secret，具体使用方法请参见在环境变量中引用ConfigMap和在环境变量中引用Secret。

创建Pod kubernetes中资源可以使用YAML描述（如果您对YAML格式不了解，可以参考YAML语法），也可以使用JSON，如下示例描述了一个名为nginx的Pod，这个Pod中包含一个名为container-0的容器，使用nginx:alpine镜像，使用的资源为100m CPU、200Mi内存。 apiVersion: v1 # Kubernetes的API Version kind: Pod # Kubernetes的资源类型 metadata: name: nginx # Pod的名称 spec: # Pod的具体规格（specification） containers: - image: nginx:alpine # 使用的镜像为 nginx:alpine name: container-0 # 容器的名称 resources: # 申请容器所需的资源 limits: cpu: 100m memory: 200Mi requests: cpu: 100m memory: 200Mi imagePullSecrets: # 拉取镜像使用的证书，在CCE上必须为default-secret - name: default-secret 如上面YAML的注释，YAML描述文件主要为如下部分： metadata：一些名称/标签/namespace等信息。 spec：Pod实际的配置信息，包括使用什么镜像，volume等。 如果去查询Kubernetes的资源，您会看到还有一个status字段，status描述kubernetes资源的实际状态，创建时不需要配置。这个示例是一个最小集，其他参数定义后面会逐步介绍。 Pod定义好后就可以使用kubectl创建，如果上面YAML文件名称为nginx.yaml，则创建命令如下所示，-f表示使用文件方式创建。 $ kubectl create -f nginx.yaml pod/nginx created

容器启动命令 启动容器就是启动主进程，但有些时候，启动主进程前，需要一些准备工作。比如MySQL类的数据库，可能需要一些数据库配置、初始化的工作，这些工作要在最终的MySQL服务器运行之前做完。这些操作，可以在制作镜像时通过在Dockerfile文件中设置ENTRYPOINT或CMD来完成，如下所示的Dockerfile中设置了ENTRYPOINT ["top", "-b"]命令，其将会在容器启动时执行。 FROM ubuntu ENTRYPOINT ["top", "-b"] 实际使用时，只需配置Pod的containers.command参数，该参数是list类型，第一个参数为执行命令，后面均为命令的参数。 apiVersion: v1 kind: Pod metadata: name: nginx spec: containers: - image: nginx:alpine name: container-0 resources: limits: cpu: 100m memory: 200Mi requests: cpu: 100m memory: 200Mi command: # 启动命令 - top - "-b" imagePullSecrets: - name: default-secret

容器的生命周期 Kubernetes提供了容器生命周期钩子，在容器的生命周期的特定阶段执行调用，比如容器在停止前希望执行某项操作，就可以注册相应的钩子函数。目前提供的生命周期钩子函数如下所示。 启动后处理（PostStart）：容器启动后触发。 停止前处理（PreStop）：容器停止前触发。 实际使用时，只需配置Pod的lifecycle.postStart或lifecycle.preStop参数，如下所示。 apiVersion: v1 kind: Pod metadata: name: nginx spec: containers: - image: nginx:alpine name: container-0 resources: limits: cpu: 100m memory: 200Mi requests: cpu: 100m memory: 200Mi lifecycle: postStart: # 启动后处理 exec: command: - "/postStart.sh" preStop: # 停止前处理 exec: command: - "/preStop.sh" imagePullSecrets: - name: default-secret

创建Role Role的定义非常简单，指定namespace，然后就是rules规则。如下面示例中的规则就是允许对default命名空间下的Pod进行GET、LIST操作。 kind: Role apiVersion: rbac.authorization.k8s.io/v1 metadata: namespace: default # 命名空间 name: role-example rules: - apiGroups: [""] resources: ["pods"] # 可以访问pod verbs: ["get", "list"] # 可以执行GET、LIST操作

ClusterRole和ClusterRoleBinding 相比Role和RoleBinding，ClusterRole和ClusterRoleBinding有如下几点不同： ClusterRole和ClusterRoleBinding不用定义namespace字段 ClusterRole可以定义集群级别的资源 可以看出ClusterRole和ClusterRoleBinding控制的是集群级别的权限。 在Kubernetes中，默认定义了非常多的ClusterRole和ClusterRoleBinding，如下所示。 $ kubectl get clusterroles NAME AGE admin 30d cceaddon-prometheus-kube-state-metrics 6d3h cluster-admin 30d coredns 30d custom-metrics-resource-reader 6d3h custom-metrics-server-resources 6d3h edit 30d prometheus 6d3h system:aggregate-customedhorizontalpodautoscalers-admin 6d2h system:aggregate-customedhorizontalpodautoscalers-edit 6d2h system:aggregate-customedhorizontalpodautoscalers-view 6d2h .... view 30d $ kubectl get clusterrolebindings NAME AGE authenticated-access-network 30d authenticated-packageversion 30d auto-approve-csrs-for-group 30d auto-approve-renewals-for-nodes 30d auto-approve-renewals-for-nodes-server 30d cceaddon-prometheus-kube-state-metrics 6d3h cluster-admin 30d cluster-creator 30d coredns 30d csrs-for-bootstrapping 30d system:basic-user 30d system:ccehpa-rolebinding 6d2h system:cluster-autoscaler 6d1h ... 其中，最重要最常用的是如下四个ClusterRole。 view：拥有查看命名空间资源的权限 edit：拥有修改命名空间资源的权限 admin：拥有命名空间全部权限 cluster-admin：拥有集群的全部权限 使用kubectl describe clusterrole命令能够查看到各个规则的具体权限。 通常情况下，使用这四个ClusterRole与用户做绑定，就可以很好的做到权限隔离。这里的关键一点是理解到Role（规则、权限）与用户是分开的，只要通过Rolebinding来对这两者进行组合就能做到灵活的权限控制。