目录

前言

查阅官方文档,找答案

解决方案


前言

当我们通过Pods、Daemon Sets、Deployments等方式运行pod时,大部分镜像容器默认是无特权的运行,独立用户运行的,以elastic/filebeat为例,查看用户和用户组:

k8s hostPath 目录权限 k8s挂载目录权限_filebeat

可以看到默认是使用uid=1000的filebeat用户,当我们想在容器中创建文件、或者修改文件就会提示Permission defined,如下图所示:

k8s hostPath 目录权限 k8s挂载目录权限_filebeat_02

我们可以看到filebeat用户没有写的权限,如果要解决这个问题我们可以通过指定Pod运行时使用的用户,或者修改对应目录的权限,或者其他方式,这里我介绍一下如何Pod如何指定用户启动。

查阅官方文档,找答案

通过k8s官网文档我们可以查阅到通过spec.securityContext为 Pod 设置安全性上下文,该Pod定义如下:

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。

 因此我们可以知道:通过runAsUser、fsGroup、runAsGroup三个配置项可以为Pod指定用户,那么我们可以通过将uid、gid、groups都指定为0这样就达到以root用户启动容器的效果了。

解决方案

完整配置如下:

apiVersion: v1
kind: Pod
metadata:
  name: security-context-demo
spec:
  securityContext:
    runAsUser: 0
    runAsGroup: 0
    fsGroup: 0
  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

这里我们只需要将spec.securityContext的三个配置子项配置到我们自己的容器yaml文件中重启就实现通过root运行pod的效果了。

基于前言的示例,我们修改配置后再次查看容器运行的用户,结果如下:

k8s hostPath 目录权限 k8s挂载目录权限_linux_03

 可以看到当前Pod默认就以root用户运行,通过cat /etc/group查看发现依然有filebeat的用户,所以成功完成的指定用户运行容器的效果。