k8s 容器内操作报Permission defined,以root运行容器，定义Pod的特权和访问控制权限

目录

前言

查阅官方文档，找答案

解决方案

---

前言

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

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

我们可以看到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的效果了。

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

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

参考文档

为 Pod 或容器配置安全上下文 | Kubernetes