容器安全上下文介绍

kubernetes为安全运行pod及容器运行设计了安全上下文机制，该机制允许用户和管理员定义pod或容器的特权与访问控制，已配置容器与主机以及主机之上的其它容器间的隔离级别。安全上下文就是一组用来决定容器时如何创建和运行的约束条件，这些条件代表创建和运行容器时使用的运行时参数。需要提升容器权限时，用户通常只应授予容器执行其工作所需的访问权限，以最小权限法则来抑制容器对基础架构及其它容器产生的负面影响。

kubernetes支持用户在pod及容器级别配置安全上下文，并允许管理员通过pod安全策略在集群全局级别限制用户在创建和运行pod时可设定安全上下文。

安全上下文（Security Context）定义 Pod 或 Container 的特权与访问控制设置。 安全上下文包括但不限于：

  自主访问控制（DAC）：传统UNIX的访问控制机制，它允许对象的所有者基于UUID和GID设定对象的访问权限。
  Linux功能：Linux为突破系统上传统的两级用户（root和普通用户）授权模型，而将内核管理权限打散成多个不同维度或级别的权限子集，每个子集称为一种功能或能力，例如CAP_NET_ADMIN、CAP_SYS_TIME、CAP_SYS_PTRACE和CAP_SYS_ADMIN等，从而允许进程仅具有一部分内核管理功能就能完成必要的管理任务。
  seccomp：全称为secure computing mode，是linux内核的安全模型，用于为默认可发起的任何系统调用进程施加控制机制，人为地禁止它能够发起的系统调用，有效降低了程序被劫持的危害级别。
  AppArmor:全称为Application Armor，意为应用盔甲，是linux内核的一个安全模块，通过加载带内核的配置文件来定义对程序的约束与控制。
  SELinux：全称为Security-Enhanced Linux，意为安全加强的Linux，是linux内核的一个安全模块，提供了包括强制访问控制在内的访问控制安全策略机制。
  Privileged模式：即特权模式容器，该模式下容器中的root用户拥有所有的内核功能，即具有真正的管理员权限，它能看到主机上的所有设备，能够挂载文件系统，甚至可以在容器中运行容器；容器默认运行于非特权模式。
  AllowPrivilegeEscalation：控制是否允许特权升级，及进程是否能够获取比父进程更多的特权；运行于特权模式或具有CAP_SYS_ADMIN能力的容器默认允许特权升级。

这些安全上下文相关的特性多数嵌套定义在pod或容器的securityContext字段中，而且有些特性对应的嵌套字段还不止一个。而seccomp和AppArmor的安全上下文则需要以资源注解的方式进行定义，而且技能由管理员在集群级别进行pod安全策略配置。

配置格式

kubernetes默认以非特权模式创建并允许容器，同时禁用了其他与管理功能相关的内核能力，但未额外设定其他上下文参数。

apiVersion: v1
kind: Pod
metadata:
  name: securitycontext-capabilities-demo
  namespace: default
spec:
  securityContext:            #pod级别的安全上下文，对内部多有容器均有效
    runAsUer <integer>        #以指定的用户身份运行容器进程，默认由镜像中的USER指定
    runAsGroup <integer>      #以指定的用户组运行容器进程，默认使用的组随容器运行时设定
    supplementalGroups <[] integer>  #为容器中1号进程的用户添加的附加组
    fsGroup <integer>         #为容器中的1号进程附加一个专用组，其功能类似于sgid
    runAsNonRoot <boolean>    #是否以非root身份运行
    seLinuxOptions <object>   #SELINUX的相关配置
    sysctl <[] object>        #应用到当前pod名称空间级别的sysctl参数设置列表
    windowsOptions <object>   #windows容器专用配置
  containers：
  - name: ...
    image: ...
    securityContext:      #容器级别的安全上下文，仅在当前容器生效
      runAsUer <integer>        #以指定的用户身份运行容器进程，默认由镜像中的USER指定
      runAsGroup <integer>      #以指定的用户组运行容器进程，默认使用的组随容器运行时设定
      runAsNonRoot <boolean>    #是否以非root身份运行
      allowPrivilegeEscalation <boolean> #是否允许特权升级
      capabilities <object>     #为当前容器添加或删除内核能力
        add <[] string>         #添加由列表定义的各项内核能力
        drop <[] string>        #移除由列表定义的各项内核能力
      privileged <boolean>      #是否允许为特权容器
      procMount <string>        #设置容器procMount类型，默认为DefaultProcMount
      readOnlyRootFilesystem <boolean>  #是否将根文件系统设置为只读模式
      seLinuxOptions <object>   #selinux相关配置
      windowsOptions <object>   #windows相关配置

管理容器的内核功能

传统linux仅实现了特权和非特权两类进程，前者是指以0号UID身份运行的进程，而后者则是从属非0号UID用户的进程。linux内核从2.2版本开始将附加在超级用户的权限分割为多个独立单元，这些单元是线程级别的，它们可配置在每个线程之上为其赋予特定的管理能力。linux内核常用的功能包括但不限于如下这些：

  CAP_CHOWN：改变文件的UID和GID。
  CAP_MKNOD：借助系统调用mknod()创建设备文件。
  CAP_NET_ADMIN：网络管理相关的操作，可用于管理网络接口、netfilter上的iptables规则、路由表、透明代理、TOS、清空驱动统计数据、设计混杂模式和启动多播功能等。
  CAP_NET_BIND_SERVICE：绑定小于1024的特权端口，但该功能在重新映射用户后可能会失效。
  CAP_NET_RAW：使用RAW或PACKET类型的套接字，并可绑定任何地址进行透明代理。
  CAP_SYS_ADMIN：支持内核上的很大一部分管理功能。
  CAP_SYS_BOOT：重启系统
  CAP_SYS_CHROOT：使用chroot()进行根文件系统切换，并能够调用setns()修改Mount名称空间
  CAP_SYS_MODULE：转载内核模块
  CAP_SYS_TIME：设定系统时钟和硬件时钟
  CAP_SYSLOG：调用syslog()执行日志相关的特权操作。

系统管理员可以通过get命令获取程序文件上的内核功能，并可使用setcap为程序文件设定内核功能或取消其已有的内核功能。而kubernetes上运行的进程设定内核功能则需要在pod容器的安全上下文中嵌套capabilities字段，添加和移除内核能力还需要分别在下一级嵌套中使用add或drop字段。这两个字段可接收以内核能力名称为列表项，但引用个内核能力名称时序移除CAP_前缀，例如可使用NET_ADMIN等。

apiVersion: v1
kind: Pod
metadata:
  name: securitycontext-capabilities-demo
  namespace: default
spec:
  containers:
  - name: demo
    image: 192.168.174.120/baseimages/tomcat-app1:v1.0
    imagePullPolicy: IfNotPresent
    securityContext:
      capabilities:
        add: ['NET_ADMIN']
        drop: ['CHOWN']

特权模式容器

kubernetes集群中，kube-proxy中的容器就运行在特权模式。

# kubectl get pods calico-node-pbfcs -n kube-system -o yaml

apiVersion: v1
kind: Pod
metadata:
    ...
  - image: 192.168.174.120/baseimages/calico-pod2daemon-flexvol:v3.19.2
    imagePullPolicy: IfNotPresent
    name: flexvol-driver
    resources: {}
    securityContext:
      privileged: true   #运行在特权模式
    ....

在pod中使用sysctl

kubernetes允许在pod中独立安全地设置支持名称空间级别的内核参数，它们默认处于启动状态，而节点级别内核参数则被认为是不安全地，它们默认处于禁用状态。kernel.shm_rmid_force、net.ipv4.ip_local_range和net.ipv4.tcp_sysncookies这3个内核参数被kubernetes视为安全参数，它们在pod安全上下文的sysctl参数内嵌套使用，而余下的绝大多数的内核参数都是非安全参数，需要管理员手动在每个节点上通过kubelet选项逐个启用后才能配置到pod上。例如在各工作节点上编辑/etc/default/kubelet文件，添加以下内容允许在pod上使用指定的两个非安全地内核参数，并重启kubelet服务使之生效。

KUBELET_EXTRA_ARGS='--allowed-unsafe-sysctls=net.core.somaxconn,net.ipv4.ip_unprivileged_port_start'

配置样例

apiVersion: v1
kind: Pod
metadata:
  name: securitycontext-sysctls-demo
  namespace: default
spec:
  securityContext:
    sysctls:
    - name: kernel.shm_rmid_forced
      value: "0"
    - name: net.ipv4.ip_unprivileged_port_start
      value: "0"
  containers:
  - name: demo
    image: 192.168.174.120/baseimages/tomcat-app1:v1.0
    imagePullPolicy: IfNotPresent
    securityContext:
      runAsUser: 1001
      runAsGroup: 1001

为 Pod 设置安全性上下文

要为 Pod 设置安全性设置，可在 Pod 规约中包含 securityContext 字段。securityContext 字段值是一个 PodSecurityContext 对象。你为 Pod 所设置的安全性配置会应用到 Pod 中所有 Container 上。 下面是一个 Pod 的配置文件，该 Pod 定义了 securityContext 和一个 emptyDir 卷：

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: busybox:1.28
    command: [ "sh", "-c", "sleep 1h" ]
    volumeMounts:
    - name: sec-ctx-vol
      mountPath: /data/demo
    securityContext:
      allowPrivilegeEscalation: false

在配置文件中，runAsUser 字段指定 Pod 中的所有容器内的进程都使用用户 ID 1000 来运行。runAsGroup 字段指定所有容器中的进程都以主组 ID 3000 来运行。 如果忽略此字段，则容器的主组 ID 将是 root（0）。 当 runAsGroup 被设置时，所有创建的文件也会划归用户 1000 和组 3000。 由于 fsGroup 被设置，容器中所有进程也会是附组 ID 2000 的一部分。 卷 /data/demo 及在该卷中创建的任何文件的属主都会是组 ID 2000。

为 Pod 配置卷访问权限和属主变更策略

默认情况下，Kubernetes 在挂载一个卷时，会递归地更改每个卷中的内容的属主和访问权限， 使之与 Pod 的 securityContext 中指定的 fsGroup 匹配。 对于较大的数据卷，检查和变更属主与访问权限可能会花费很长时间，降低 Pod 启动速度。 你可以在 securityContext 中使用 fsGroupChangePolicy 字段来控制 Kubernetes 检查和管理卷属主和访问权限的方式。

fsGroupChangePolicy - fsGroupChangePolicy 定义在卷被暴露给 Pod 内部之前对其 内容的属主和访问许可进行变更的行为。此字段仅适用于那些支持使用 fsGroup 来 控制属主与访问权限的卷类型。此字段的取值可以是：

  OnRootMismatch：只有根目录的属主与访问权限与卷所期望的权限不一致时， 才改变其中内容的属主和访问权限。这一设置有助于缩短更改卷的属主与访问 权限所需要的时间。
  Always：在挂载卷时总是更改卷中内容的属主和访问权限。

例如：

securityContext:
  runAsUser: 1000
  runAsGroup: 3000
  fsGroup: 2000
  fsGroupChangePolicy: "OnRootMismatch"

说明： 此字段对于 secret、 configMap 和 emptydir 这类临时性存储无效。

将卷权限和所有权更改委派给 CSI 驱动程序

特性状态： Kubernetes v1.26 [stable]
如果你部署了一个容器存储接口 (CSI) 驱动，而该驱动支持 VOLUME_MOUNT_GROUP NodeServiceCapability， 在 securityContext 中指定 fsGroup 来设置文件所有权和权限的过程将由 CSI 驱动而不是 Kubernetes 来执行。在这种情况下，由于 Kubernetes 不执行任何所有权和权限更改， fsGroupChangePolicy 不会生效，并且按照 CSI 的规定，CSI 驱动应该使用所指定的 fsGroup 来挂载卷，从而生成了一个对 fsGroup 可读/可写的卷.

为 Container 设置安全性上下文

若要为 Container 设置安全性配置，可以在 Container 清单中包含 securityContext 字段。securityContext 字段的取值是一个 SecurityContext 对象。你为 Container 设置的安全性配置仅适用于该容器本身，并且所指定的设置在与 Pod 层面设置的内容发生重叠时，会重写 Pod 层面的设置。Container 层面的设置不会影响到 Pod 的卷。

下面是一个 Pod 的配置文件，其中包含一个 Container。Pod 和 Container 都有 securityContext 字段：

apiVersion: v1
kind: Pod
metadata:
  name: security-context-demo-2
spec:
  securityContext:
    runAsUser: 1000
  containers:
  - name: sec-ctx-demo-2
    image: gcr.io/google-samples/node-hello:1.0
    securityContext:
      runAsUser: 2000
      allowPrivilegeEscalation: false

进程以用户 2000 运行。该值是在 Container 的 runAsUser 中设置的。 该设置值重写了 Pod 层面所设置的值 1000。

USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
2000         1  0.0  0.0   4336   764 ?        Ss   20:36   0:00 /bin/sh -c node server.js
2000         8  0.1  0.5 772124 22604 ?        Sl   20:36   0:00 node server.js

为容器设置 Seccomp 配置

若要为容器设置 Seccomp 配置（Profile），可在你的 Pod 或 Container 清单的 securityContext 节中包含 seccompProfile 字段。该字段是一个 SeccompProfile 对象，包含 type 和 localhostProfile 属性。 type 的合法选项包括 RuntimeDefault、Unconfined 和 Localhost。 localhostProfile 只能在 type: Localhost 配置下才可以设置。 该字段标明节点上预先设定的配置的路径，路径是相对于 kubelet 所配置的 Seccomp 配置路径（使用 --root-dir 设置）而言的。

下面是一个例子，设置容器使用节点上容器运行时的默认配置作为 Seccomp 配置：

...
securityContext:
  seccompProfile:
    type: RuntimeDefault

下面是另一个例子，将 Seccomp 的样板设置为位于 <kubelet-根目录>/seccomp/my-profiles/profile-allow.json 的一个预先配置的文件。

...
securityContext:
  seccompProfile:
    type: Localhost
    localhostProfile: my-profiles/profile-allow.json

为 Container 赋予 SELinux 标签

若要给 Container 设置 SELinux 标签，可以在 Pod 或 Container 清单的 securityContext 节包含 seLinuxOptions 字段。 seLinuxOptions 字段的取值是一个 SELinuxOptions 对象。
下面是一个应用 SELinux 标签的例子：

...
securityContext:
  seLinuxOptions:
    level: "s0:c123,c456"

说明： 要指定 SELinux，需要在宿主操作系统中装载 SELinux 安全性模块。

高效重打 SELinux 卷标签

特性状态： Kubernetes v1.27 [beta]
默认情况下，容器运行时递归地将 SELinux 标签赋予所有 Pod 卷上的所有文件。 为了加快该过程，Kubernetes 使用挂载可选项 -o context=<label> 可以立即改变卷的 SELinux 标签。

要使用这项加速功能，必须满足下列条件：

  必须启用 ReadWriteOncePod 和 SELinuxMountReadWriteOncePod 特性门控。
  Pod 必须以 accessModes: ["ReadWriteOncePod"] 模式使用 PersistentVolumeClaim。
  Pod（或其中使用 PersistentVolumeClaim 的所有容器）必须设置 seLinuxOptions。
  对应的 PersistentVolume 必须是：
    使用传统树内（In-Tree） iscsi、rbd 或 fs 卷类型的卷。
    或者是使用 {< glossary_tooltip text="CSI" term_id="csi" >}} 驱动程序的卷 CSI 驱动程序必须能够通过在 CSIDriver 实例中设置 spec.seLinuxMount: true 以支持 -o context 挂载。

对于所有其他卷类型，重打 SELinux 标签的方式有所不同： 容器运行时为卷中的所有节点（文件和目录）递归地修改 SELinux 标签。 卷中的文件和目录越多，重打标签需要耗费的时间就越长。

特殊说明

Pod 的安全上下文适用于 Pod 中的容器，也适用于 Pod 所挂载的卷（如果有的话）。 尤其是，fsGroup 和 seLinuxOptions 按下面的方式应用到挂载卷上：

  fsGroup：支持属主管理的卷会被修改，将其属主变更为 fsGroup 所指定的 GID， 并且对该 GID 可写。

  seLinuxOptions：支持 SELinux 标签的卷会被重新打标签，以便可被 seLinuxOptions 下所设置的标签访问。通常你只需要设置 level 部分。 该部分设置的是赋予 Pod 中所有容器及卷的 多类别安全性（Multi-Category Security，MCS)标签。

警告： 在为 Pod 设置 MCS 标签之后，所有带有相同标签的 Pod 可以访问该卷。 如果你需要跨 Pod 的保护，你必须为每个 Pod 赋予独特的 MCS 标签。

参考文档

https://kubernetes.io/docs/tasks/configure-pod-container/security-context/

本栏目推荐文章
• k8s核心组件介绍
• 2d物理引擎学习 - 斜坡上下滑的物体
• k8s安装
• Ubuntu 20.04版本安装k8s控制节点
• k8s 将 cri 从 docker 切换到 containerd
• 十分钟教你在 k8s 中部署一个前后端应用
• Prometheus监控k8s集群节点主机内存/CPU使用率
• Prometheus监控容器内pod节点内存/CPU使用率
• k8s 1.26.3 部署（containerd+centos 7.9）
• YAML示例：创建单幅本nginx容器到指定节点及其service

上下文 容器 上下 k8s k8上下文 容器 上下k8s 上下文 容器 上下pod 上下文 容器 上下spring 容器longhorn问题k8s 容器 方法k8s k8 容器kubernetes引擎k8s 探针 容器 机制k8s 集群 容器k8s k8 容器k8s k8 8s 容器 工具k8s k8