4、安全上下文
安全上下文
目录
[toc]
本节实战
实战名称 |
---|
💘 实战:为 Pod 设置 Security Context-2023.2.9(测试成功) |
💘 实战:为容器设置 Security Context-2023.2.9(测试成功) |
💘 实战:Linux中如何使用 Capabilities-2023.2.9(测试成功) |
💘 实战:如何使用Capabilities-2023.2.10(测试成功) |
💘 实战:Kubernetes 配置 Capabilities-2023.2.10(测试成功) |
前言
Kubernetes Pod/容器的安全管控
我们有时候在运行一个容器的时候,可能需要使用 sysctl
命令来修改内核参数,比如 net
、vm
、kernel
等参数,但是 systcl
需要容器拥有超级权限,才可以使用,在 Docker 容器启动的时候我们可以加上 --privileged
参数来使用特权模式。那么在 Kubernetes 中应该如何来使用呢?
这个时候我们就需要使用到 Kubernetes 中的 Security Context
,也就是常说的安全上下文,主要是来限制容器非法操作宿主节点的系统级别的内容,使得节点的系统或者节点上其他容器组受到影响。
Kubernetes 提供了三种配置安全上下文级别的方法:
-
Container-level Security Context
:仅应用到指定的容器 -
Pod-level Security Context
:应用到 Pod 内所有容器以及Volume -
Pod Security Policies(PSP,在Kubernetes v1.21 中被弃用,在v1.25 中被移除)
:应用到集群内部所有 Pod 以及 Volume
我们可以用如下几种方式来设置 Security Context
:
-
访问权限控制:根据用户 ID(UID)和组 ID(GID)来限制对资源(比如:文件)的访问权限
-
Security Enhanced Linux (SELinux):为对象分配
SELinux
标签 -
以 privileged(特权)模式运行
-
Linux Capabilities:给某个特定的进程超级权限,而不用给 root 用户所有的 privileged 权限
-
AppArmor:使用程序文件来限制单个程序的权限
-
Seccomp:过滤容器中进程的系统调用(system call)
-
AllowPrivilegeEscalation(允许特权扩大):此项配置是一个布尔值,定义了一个进程是否可以比其父进程获得更多的特权,直接效果是,容器的进程上是否被设置
no_new_privs
标记。当出现如下情况时,AllowPrivilegeEscalation 的值始终为 true: -
- 容器以
privileged
模式运行
- 容器以
-
- 容器拥有
CAP_SYS_ADMIN
的 Linux Capability
- 容器拥有
1、为 Pod 设置 Security Context
==💘 实战:为 Pod 设置 Security Context-2023.2.9(测试成功)==
- 实验环境
实验环境:
1、win10,vmwrokstation虚机;
2、k8s集群:3台centos7.6 1810虚机,1个master节点,2个node节点
k8s version:v1.25.4
containerd://1.6.10
-
实验软件(无)
-
我们只需要在 Pod 定义的资源清单文件中添加
securityContext
字段,就可以为 Pod 指定安全上下文相关的设定,通过该字段指定的内容将会对当前 Pod 中的所有容器生效。
#security-context-pod-demo.yaml
apiVersion: v1
kind: Pod
metadata:
name: security-context-pod-demo
spec:
volumes:
- name: sec-ctx-vol
emptyDir: {}
securityContext: #pod级别的安全上下文
runAsUser: 1000 #容器进程的用户ID
runAsGroup: 3000 #容器进程的组ID
fsGroup: 2000 #数据卷的组ID
containers:
- name: sec-ctx-demo
image: busybox
command: ["sh", "-c", "sleep 60m"]
volumeMounts:
- name: sec-ctx-vol
mountPath: /pod/demo
在当前资源清单文件中我们在 Pod 下面添加了 securityContext
字段,其中:
runAsUser
字段指定了该 Pod 中所有容器的进程都以 UID 1000 的身份运行runAsGroup
字段指定了该 Pod 中所有容器的进程都以 GID 3000 的身份运行- **如果省略该字段,容器进程的 GID 为 **
root(0)
- 容器中创建的文件,其所有者为 userID 1000,groupID 3000
- **如果省略该字段,容器进程的 GID 为 **
fsGroup
字段指定了该 Pod 的 fsGroup 为 2000- **数据卷 (对应挂载点 **
/pod/demo
的数据卷为sec-ctx-demo
) 的所有者以及在该数据卷下创建的任何文件,其 GID 都为 2000
- **数据卷 (对应挂载点 **
下表是我们常用的一些 securityContext
字段设置内容介绍:
- 直接创建上面的 Pod 对象:
[root@master1 ~]#kubectl apply -f security-context-pod-demo.yaml
pod/security-context-pod-demo created
[root@master1 ~]#kubectl get po
NAME READY STATUS RESTARTS AGE
security-context-pod-demo 1/1 Running 0 40s
- 运行完成后,我们可以验证下容器中的进程运行的 ownership:
[root@master1 ~]#kubectl exec security-context-pod-demo -- top
Mem: 1702304K used, 160948K free, 45552K shrd, 1036K buff, 1147564K cached
CPU: 4.7% usr 52.3% sys 0.0% nic 42.8% idle 0.0% io 0.0% irq 0.0% sirq
Load average: 1.08 1.10 1.13 4/230 66
PID PPID USER STAT VSZ %VSZ CPU %CPU COMMAND
60 0 1000 R 1312 0.0 0 0.0 top
1 0 1000 S 1300 0.0 1 0.0 sleep 60m
我们直接运行一个 top
进程,查看容器中的所有正在执行的进程,我们可以看到 USER ID 都为 1000(runAsUser
指定的)。
- 然后查看下挂载的数据卷的 ownership:
[root@master1 ~]#kubectl exec security-context-pod-demo -- ls -al /pod
total 0
drwxr-xr-x 3 root root 18 Dec 1 14:37 .
drwxr-xr-x 1 root root 62 Dec 1 14:37 ..
drwxrwsrwx 2 root 2000 6 Dec 1 14:37 demo
因为上面我们指定了 fsGroup=2000
,所以声明挂载的数据卷 /pod/demo
的 GID 也变成了 2000。
- 直接调用容器中的 id 命令:
[root@master1 ~]#kubectl exec security-context-pod-demo -- id
uid=1000 gid=3000 groups=2000