security-Context

运行 pod 而不配置安全上下文

运行一个 pod:

  1. $ kubectl run pod-with-defaults --image alpine --restart Never -- /bin/sleep 999999

查看用户 ID 和组 ID:

image.png

13.2.1 使用指定用户运行容器

  1. securityContext.runAsUser

image.png

再次查看 id:

$ kubectl exec pod-as-user-guest id

13.2.2 阻止容器以 root 用户运行

image.png

image.png

使用 securityContext 配置 user 时, 是否要求在 Dockerfile 中指定好该 user?

13.2.3 使用特权模式运行 pod

kube-proxy, 修改主机的 iptables 规则

配置特权模式:

image.png

13.2.4 为容器单独添加内核功能

Linux 可以通过内核功能支持更细粒度的权限系统.

使用 capbilities 配置内核功能:

  • 添加修改系统时间内核功能

image.png

注意:

  • 在 Kubernetes 中配置内核功能时要去掉 CAP_ 前缀

13.2.5 在容器中禁用内核功能

有些内核功能是开放给 pod 的.

  • CAP_CHOWN 允许进程修改文件系统中文件的所有者

image.png

13.2.6 阻止对容器根文件系统的写入

securityContext.readOnlyRootFilesystem

image.png

设置 pod 级别的安全上下文

pod.spec.securityContext

会被容器级别的安全上下文覆盖.

13.2.7 容器使用不同用户运行时共享存储卷

一个 pod 中的多个容器可能使用不同 user 运行, 所以在挂载同一个卷时, 访问文件的权限可能会出现问题. 为了解决这个问题, kubernetes 有了 supplemental 组, 允许无论以那个用户 ID 运行都可以共享文件.

  • fsGroup
  • supplementalGroups

使用例子:

image.png
image.png

第一个容器的 user:

image.png

在所挂载的卷上创建文件, 注意组 ID:

image.png

supplementalGroups 定义了某个用户所关联的额外的用户组.