kubernetes笔记-Pod&Container安全上下文

安全上下文定义POD&容器的权限和访问控制，包括以下几种：

自主访问控制(DAC)：基于用户ID(uid)和组ID(gid)的访问控制

安全增强型Linux（SELinux）：分配安全标签

作为特权或非特权运行

Linux功能：给进程部分特权

Apparmor：使用程序配置文件来限制单个程序的功能

seccomp：过滤进程的系统调用

AllowPrivilegeEscalization：控制进程是否可以获得比其父进程更多的权限

下载案例使用的image

docker pull gcr.io/google-samples/node-hello:1.0

pod.spec.securityContext. runAsUser

    运行容器进程的uid

    默认为在image metadata中指定的用户

    可在SecurityContext中设置

pod.spec.securityContext. fsGroup

    用户附加组及挂载volume中文件的属组

新建pod定义文件security-context.yaml

apiVersion: v1

kind: Pod

metadata:

  name: security-context-demo

spec:

  securityContext:

    runAsUser: 2001

    fsGroup: 2000

  volumes:

  - name: sec-ctx-vol

    emptyDir: {}

  containers:

  - name: sec-ctx-demo

    image: gcr.io/google-samples/node-hello:1.0

    volumeMounts:

    - name: sec-ctx-vol

      mountPath: /data/demo

    securityContext:

      allowPrivilegeEscalation: false

kubectl apply -f security-context.yaml

查看Pod的状态

可以看到进程的userid是2001，与runAsUser: 2001一致

可以看到用户2001的gid为0，附件组为2000，与fsGroup: 2000一致

挂载目录属组为2000，权限为rws，目录中的文件属组都为2000，与fsGroup: 2000一致

在Node中查看相关进程，与在pod中查看一致，而2001用户的组ID为2001

增加container中的securityContext配置runAsUser：3000

由于container中的安全上下文配置优先于pod中的配置，所以这里runAsUser: 3000

* runAsGroup 貌似没有用；

* entrypoint 表示程序的启动，与docker中的entrypoint不是一个意思；

新建两个pod，pod.spec.containers.securityContext.capabilities存在区别，这个字段用于添加和删除linux功能

查看两个容器中的CpuCap

从右向左数，bit位从0开始。第12bit代表CAP_NET_ADMIN，第25bit代表CAP_SYS_TIME