K8s: root用户和非root用户在运行Pod时的安全相关配置

关于 root 用户。

1 ）概述。

• docker 容器运行，默认是 root 用户。
• 这样运行后，与权限有关的问题基本上不会出现
• 问题是： 太大的权限󿀌被攻击后会遇到严重挑战。
• 基于这个问题，K8s提出了特权用户的概念。在容器启动时，虽然是开始的 root 用户，但不具备所有root功能。
• 只是一个映射root用户，如果不开启 privilege 试着修改系统的关键信息。是会报错的，加上 --privilege 之后，特权用户，可以修改。
• 2 ）正常场景。
• $。

docker run -it busybox sh。

• $。 whoami。
• 这里显示 root。 $。id -u。
• 0 $。hostname。
• db3437d25c87。 $sysctl kernel.hostname=wwwwwwww。
• sysctl: error setting key ‘kernel.hostname’: Read-only file system。 3 ）启用 privileged。$。

docker run -it --privileged busybox sh。

• $。 sysctl kernel.hostname=wwwwwwww。
• kernel.hostname = wwwwwwww。 $。hostname。
• wwwwwwww。 4 ）在 yaml 中配置 securityContext 和 privileged。apiVersion。

:。

v1。kind。:。Pod。metadata。:。name。:。nginx。spec。:。containers。:。-。name。:。nginx。image。:。    nginx。securityContext。:。    privileged。:。true。非 root 用户容器越权访问控制，K8s 提供 securityContext 这个概念。

它提供了非root用户操作容器的能力。

• 容器对root用户本身有一定的自我保护能力。
• root权限太大，更安全的方法是设置用户和组来运行
• 1 ）
• 无权限处理。

默认为root权限，但是root权限本身是有限的。但是root总是不安全的。

• security.yaml。
• apiVersion。
• :。

  v1。kind。:。  Pod。metadata。:。  name。:。security。-。context。labels。:。    name。:。security。-。context。spec。:。  volumes。:。-。name。:。security。emptyDir。:。        { 。}。# 这是一个 Pod 内部临时目录。containers。:。  -。name。:。busybox。image。:。        busybox。command。:。        [。"sh","-c","sleep 1h"]。resources。:。limits。:。memory。:。"64Mi"cpu。:。"500m"volumeMounts。:。-。name。:。security。# 注意，这个名字需要定义在与卷的定义中 name 匹配。mountPath。 :。  /data/demo。securityContext。:。        privileged。:。false。# 容器是否以特权模式运行。allowPrivilegeEscalation。:。  false。# 是否允许提高权限？$。kubectl apply -f security.yaml。

• 创建 pod。 pod/security-context created。$。

  kubectl get pod -w | grep secu。

• 查询 pod 状态。 security-context 1/1 Running 0 21s。$。

  kubectl exec -it security-context -- sh。

• 进入容器(pod中的容器不需要-c指定)。 $。id。
• 查看 id 信息。 uid=0(root) gid=0(root) groups=0(root),10(wheel)。$。

  ps。

• 查看进程。 PID USER TIME COMMAND 1 root 0:00 sh -c sleep 1h 12 root 0:00 sh 19 root 0:00 ps。$。

  cd /data/demo && ls -la。

• total xrwxrwx00drwx 2 root root 6 Apr 19 04:25 .drwxr-xr-x 3 root root 18 Apr 19 04:26 ..。 好，从上面可以看出，都是 root 权限，现在我们来修改一下。

  2 ）

• 添加 securityContext 配置。

要为 Pod 设置安全性设置，可在 Pod 规约中包含 securityContext 字段。为 Pod 设置的安全配置将应用于 Pod 中所有 Container 上。

• 清理刚才的pod， 并对之前 yaml 编辑文件。
• 在 security.yaml 中添加 securityContext 配置更多。
• 注意这个配置的位置，在 spec 下面是第一个位置。
• spec。
• :。

  securityContext。:。runAsUser。:。1000。runAsGroup。:。3000。fsGroup。:。2000。在配置文件中， runAsUser 字段指定 Pod 所有容器中的过程都使用用户 ID 1000 来运行。runAsGroup 所有容器中的过程都由主组指定 ID 3000 来运行。

  • 如果忽略此字段󿀌容器的主组 ID 将是 root（0）
  • 当 runAsGroup 设置时󿀌所有创建的文件也将被归类为用户 1000 和组3000。
  • 由于 设置fsGroup󿼌容器中的所有过程也将是附组 ID 2000 的一部分。
  • 卷 /data/demo 本卷创建的任何文件的所有者都将是一个小组 ID 2000。
  • 重新运行后，进入容器。
  • $。
• kc exec -it security-context -- sh。
• $。 id。
• uid=1000 gid=3000 groups=2000,3000。 你会看到 gid 值为 3000，也就是 runAsGroup 字段的值。

  如果 runAsGroup ࿰被忽略c;则 gid 会取值 0（root）

  • 而且过程可以和 root 用户组拥有和要求 root 用户组访问权限的文件交互。
  • $。
  • ps。
• PID USER TIME COMMAND 1 1000 0:00 sh -c sleep 1h 7 1000 0:00 sh 15 1000 0:00 ps。 $。

  cd /data/demo && ls -la。

• total wxrwx00drwx 2 root 2000 6 Apr 19 04:42 .drwxr-xr-x 3 root root 18 Apr 19 04:42 ..。 从上面可以看到用户权限的变化，这样，在受到攻击时，损失将尽可能减少。