从零开始学习k8s-04为容器指定操作权限
背景
我们的容器除了正常提供服务之外,排查问题或者调试还经常要进入到容器内部进行一些操作,而如果不做任何处理,默认进入容器的用户就是root
,我们有时候只想开放某些权限给用户,而不是所有。这个行为在官方被称之为:安全性上下文。
开始
这里我们使用官方的实例来练习。
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
command: [ "sh", "-c", "sleep 1h" ]
volumeMounts:
- name: sec-ctx-vol
mountPath: /data/demo
securityContext:
allowPrivilegeEscalation: false
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
在配置文件中,
runAsUser
字段指定 Pod 中的所有容器内的进程都使用用户 ID 1000 来运行。runAsGroup
字段指定所有容器中的进程都以主组 ID 3000 来运行。 如果忽略此字段,则容器的主组 ID 将是 root(0)。 当runAsGroup
被设置时,所有创建的文件也会划归用户 1000 和组 3000。 由于fsGroup
被设置,容器中所有进程也会是附组 ID 2000 的一部分。 卷/data/demo
及在该卷中创建的任何文件的属主都会是组 ID 2000。
执行命令:kubectl apply -f [https://k8s.io/examples/pods/security/security-context.yaml](https://k8s.io/examples/pods/security/security-context.yaml)
kubectl get pods
NAME READY STATUS RESTARTS AGE
security-context-demo 1/1 Running 0 47m
进入容器查看
kubectl exec -it security-context-demo -- sh
/ $ ps
PID USER TIME COMMAND
1 1000 0:00 sleep 1h
13 1000 0:00 sh
19 1000 0:00 ps
2
3
4
5
6
7
8
9
10
11
12
13
这里可以很清楚的看到,我们的所有运行的进程都和配置文件中runAsUser
指定的一样。
cd /data
/data $ ls -lrth
total 4K
drwxrwsrwx 2 root 2000 4.0K Oct 23 05:27 demo
2
3
4
可以看到,/data/demo
目录组的ID就是fsGroup
设置的值。
/data/demo $ touch test.py
/data/demo $ ls -lrt
total 0
-rw-r--r-- 1 1000 2000 0 Oct 23 06:50 test.py
2
3
4
我们创建一个文件,可以看到用户组是fsGroup
的值,而用户则是runAsUser
的1000
.
/data/demo $ id
uid=1000 gid=3000 groups=2000
2
但是当我们执行whoami
命令的时候,输出了以下内容:
/data/demo $ whoami
whoami: unknown uid 1000
2
可以看到,这个是一个未知的uid
,也就是,我们可以通过yaml
文件指定权限,并且可以指定一个不存在的id
。但是这个跟我们正常理解的其实是有点偏差,我们更多的时候,是通过用户的方式来指定,比如我们的镜像在构建的时候,有部分内容是不开放的,我会创建一个用户给使用者使用,但是不希望他来使用root
用户。
指定进入用户
目前笔者已知的比较简单的方式,就是在构建镜像的时候直接做好对应的设定。
在Dockerfile
的最后。CMD
指令之前指定USER
。例如
From nginx:latest
。。。
USER testuser
CMD /data/initscript.sh
2
3
4
通过这种方式指定,在容器启动的时候进入容器,默认就是testuser
用户,而非root
用户。
这样的指定方式,也比较符合我们常规的思维方式。