目录
前言
查阅官方文档,找答案
解决方案
前言
当我们通过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的用户,所以成功完成的指定用户运行容器的效果。