云原生|kubernetes|pod或容器的安全上下文配置解析_pod ping: permission denied (are you root?)

前言：

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

• 自主访问控制（Discretionary Access Control）： 基于用户 ID（UID）和组 ID（GID） 来判定对对象（例如文件）的访问权限。
• 安全性增强的 Linux（SELinux）： 为对象赋予安全性标签。
• 以特权模式或者非特权模式运行。
• Linux 权能: 为进程赋予 root 用户的部分特权而非全部特权。

• AppArmor：使用程序配置来限制个别程序的权能。

• Seccomp：过滤进程的系统调用。

• allowPrivilegeEscalation：控制进程是否可以获得超出其父进程的特权。 此布尔值直接控制是否为容器进程设置 no_new_privs标志。 当容器满足一下条件之一时，allowPrivilegeEscalation 总是为 true（一般是false的）：

  • 以特权模式运行，或者
  • 具有 CAP_SYS_ADMIN 权能

• readOnlyRootFilesystem：以只读方式加载容器的根文件系统（一般是true的，true时，exec进容器不能更改文件系统，例如，在容器内touch文件，删除文件，新建文件夹等等操作都会被禁止）

一，

安全上下文的示例

没有配置安全上下文的pod：

[root@k8s-master ~]# cat nosecurity_pod.yaml 
apiVersion: v1
kind: Pod
metadata:
  creationTimestamp: null
  labels:
  name: busybox-nosecurity
spec:
  volumes:
  - name: sec-ctx-vol
    emptyDir: {}
  containers:
  - image: busybox
    name: busybox-nosecurity
    command: [ "sh","-c","sleep 1h" ]
    volumeMounts:
    - name: sec-ctx-vol
      mountPath: /data/demo
  dnsPolicy: ClusterFirst
  restartPolicy: Always
status: {}

配置了安全上下文的pod：

 cat security_pod.yaml 
apiVersion: v1
kind: Pod
metadata:
  creationTimestamp: null
  labels:
  name: busybox-security
spec:
  securityContext:
    runAsUser: 1000
    runAsGroup: 3000
    fsGroup: 2000
  volumes:
  - name: sec-ctx-vol
    emptyDir: {}
  containers:
  - image: busybox
    name: busybox-security
    command: [ "sh","-c","sleep 1h" ]
    volumeMounts:
    - name: sec-ctx-vol
      mountPath: /data/demo2
    resources: {}
    securityContext:
      allowPrivilegeEscalation: false
      readOnlyRootFilesystem: true
  dnsPolicy: ClusterFirst
  restartPolicy: Always
status: {}

 若要为 Container 设置安全性配置，可以在 Container 清单中包含 securityContext 字段。securityContext 字段的取值是一个 SecurityContext 对象。你为 Container 设置的安全性配置仅适用于该容器本身，并且所指定的设置在与 Pod 层面设置的内容发生重叠时，会重写 Pod 层面的设置。Container 层面的设置不会影响到 Pod 的卷。说人话就是pod和容器两个层面都可以设置securitycontext，如果是多容器，比如，某个pod内有A和B两个容器，pod和容器B分别设置了securitycontext，那么，A容器使用pod的securitycontext，B容器使用它自己设置的securitycontext（这一段比较绕口，是需要仔细阅读理解的哦）

上面这个示例就仅仅设置了pod的securitycontext，但容器是继承了pod的securitycontext

进入没有配置安全上下文的pod：

可以看到是使用的root权限，可以任意做手脚

[root@k8s-master ~]# kubectl exec -it busybox-nosecurity -- /bin/sh
/ # id
uid=0(root) gid=0(root) groups=10(wheel)
/ # 
/ # ps
PID   USER     TIME  COMMAND
    1 root      0:00 sleep 1h
   28 root      0:00 /bin/sh
   35 root      0:00 ps
/ # rm -rf 
.dockerenv  bin/        data/       dev/        etc/        proc/       root/       sys/        tmp/        usr/        var/
/ # rm -rf .dockerenv 
/ # 

进入配置了安全上下文的容器

可以看到无法使用root权限，安全性大大的提高了 

[root@k8s-master ~]# kubectl exec -it busybox-security -- /bin/sh
/ $ id
uid=1000 gid=3000 groups=2000
/ $ ps
PID   USER     TIME  COMMAND
    1 1000      0:00 sleep 1h
   25 1000      0:00 /bin/sh
   33 1000      0:00 ps
/ $ rm -rf home/
rm: can't remove 'home': Read-only file system
/ $ ls -al /data/demo2/
total 0
drwxrwsrwx    2 root     2000             6 Jan  8 20:00 .
drwxr-xr-x    3 root     root            19 Jan  8 20:00 ..
/ $ touch aaa
touch: aaa: Read-only file system

二，

精细化的安全上下文权限分配     capabilities

默认情况下 Docker 会删除必须的 capabilities 之外的所有 capabilities，因为在容器中我们经常会以 root 用户来运行，使用 capabilities 后，容器中的使用的 root 用户权限就比我们平时在宿主机上使用的 root 用户权限要少很多了，这样即使出现了安全漏洞，也很难破坏或者获取宿主机的 root 权限，所以 Docker 支持 Capabilities 对于容器的安全性来说是非常有必要的，当然，kubernetes的底层是docker，所以kubernetes也是支持capabilities的

在说到这个capabilities之前，需要说一下特权容器，一般的容器是无法获取宿主机的内核参数的，但某些情况下，有和宿主机的内核交互的需求，容器中有些应用程序可能需要访问宿主机设备、修改内核等需求，在默认情况下， 容器没这个有这个能力，这个时候，就需要特权容器了，但这个特权容器是非常不安全的：

containers:
- image: lizhenliang/flask-demo:root
  name: web
  securityContext:
    privileged: true

启用特权模式就意味着为容器提供了访问Linux内核的所有能力，这是很危险的，为了减少系统调用的供给，可以使用Capabilities为容器赋予仅所需的能力。 

这个capabilities不是特别常见，coredns的部署里可以看到：

 
        securityContext:
          allowPrivilegeEscalation: false
          capabilities:
            add:
            - NET_BIND_SERVICE
            drop:
            - all
          readOnlyRootFilesystem: true

具体的capabilities有哪些呢？capabilities(7) - Linux manual page  这个网站有比较详细的介绍，下图是一个简略的介绍：

 例如下面这个示例，容器虽然是root用户，但只给了一个无关紧要的kill 进程权限，因此，这个pod是无法ping其它的pod的

cat security_pod.yaml 
apiVersion: v1
kind: Pod
metadata:
  creationTimestamp: null
  labels:
  name: busybox-security
spec:
  volumes:
  - name: sec-ctx-vol
    emptyDir: {}
  containers:
  - image: busybox
    name: busybox-security
    command: [ "sh","-c","sleep 1h" ]
    volumeMounts:
    - name: sec-ctx-vol
      mountPath: /data/demo2
    resources: {}
    securityContext:
      capabilities:
        drop:
          - ALL
        add: ["KILL"]
      allowPrivilegeEscalation: false
      readOnlyRootFilesystem: true
  dnsPolicy: ClusterFirst
  restartPolicy: Always
status: {}

进入容器后，虽然是root用户，但是是无法执行需要高网络权限的命令的（ping命令需要网络权限）

[root@k8s-master ~]# kubectl exec -it busybox-security -- /bin/sh
/ # id
uid=0(root) gid=0(root) groups=10(wheel)
/ # ping 10.244.0.13
PING 10.244.0.13 (10.244.0.13): 56 data bytes
ping: permission denied (are you root?)

上述文件修改成如下：

apiVersion: v1
kind: Pod
metadata:
  creationTimestamp: null
  labels:
  name: busybox-security
spec:
  volumes:
  - name: sec-ctx-vol
    emptyDir: {}
  containers:
  - image: busybox
    name: busybox-security
    command: [ "sh","-c","sleep 1h" ]
    volumeMounts:
    - name: sec-ctx-vol
      mountPath: /data/demo2
    resources: {}
    securityContext:
      capabilities:
        drop:
          - ALL
        add: ["NET_ADMIN","NET_RAW"]
      allowPrivilegeEscalation: false
      readOnlyRootFilesystem: true
  dnsPolicy: ClusterFirst
  restartPolicy: Always
status: {}

执行此文件后，就可以愉快的在容器内使用ping命令了：

[root@k8s-master ~]# kubectl exec -it busybox-security -- /bin/sh
/ # id
uid=0(root) gid=0(root) groups=10(wheel)
/ # ping 10.244.0.13
PING 10.244.0.13 (10.244.0.13): 56 data bytes
64 bytes from 10.244.0.13: seq=0 ttl=62 time=1.142 ms
64 bytes from 10.244.0.13: seq=1 ttl=62 time=0.889 ms
^C
--- 10.244.0.13 ping statistics ---
2 packets transmitted, 2 packets received, 0% packet loss
round-trip min/avg/max = 0.889/1.015/1.142 ms

小结：

securitycontext是对于pod和容器的安全性提升有非常大帮助的一个选项，因此，如果没有测试的需求，最好还是启用securitycontext，并且禁用privileged特权容器，以免对宿主机造成破坏。