企业官网建设流程全解析

5、Secret私密凭据

上一节提到Secret对象，Secret的主要作用是保管私密数据，比如密码、OAuth Tokens、SSH Keys等信息。将这些私密信息放在Secret对象中比直接放在Pod或DockerImage中更安全，也更便于使用和分发。

下面的例子用于创建一个Secret：

apiVersion:v1kind:Secretmetadata:name:mysecret# Secret 资源的名称type:Opaque# Secret 类型，Opaque 表示任意用户定义的密码/键值对数据data:password:dmFsdWUtMg0K# Base64 编码的密码值username:dmFsdWUtMQ0K# Base64 编码的用户名值

kubectl create-fsecrets.yaml

在上面的例子中，data域的各子域的值必须为BASE64编码值，其中password域和username域BASE64编码前的值分别为value-1和value-2。

一旦Secret被创建，就可以通过下面三种方式使用它。

• （1）在创建Pod时，通过为Pod指定Service Account来自动使用该Secret。
• （2）通过挂载该Secret到Pod来使用它。
• （3）在Docker镜像下载时使用，通过指定Pod的spc.ImagePullSecrets来引用它。

第1种使用方式主要用在API Server鉴权方面，之前提到过。下面的例子展示了第2种使用方式：将一个Secret通过挂载的方式添加到Pod的Volume中：

apiVersion:v1kind:Podmetadata:name:mypodnamespace:mynsspec:containers:-name:mycontainer# 容器名称image:redis# 镜像名称volumeMounts:-name:foo# 引用下面定义名为 foo 的 volumemountPath:"/etc/foo"# 容器内部的挂载路径readOnly:true# 设置为只读挂载volumes:-name:foo# 定义一个名为 foo 的 Volumesecret:secretName:mysecret# 该 Volume 引用名为 mysecret 的 Kubernetes Secret 资源

其结果如图所示。

第3种使用方式的使用流程如下。

• （1）执行login命令，登录私有Registry：

  # docker login localhost:5000

  输入用户名和密码，如果是第1次登录系统，则会创建新用户，相关信息被会写入～/.dockercfg文件中。
• （2）用BASE64编码dockercfg的内容：

  # cat ～/.dockercfg | base64

• （3）将上一步命令的输出结果作为Secret的data.dockercfg域的内容，由此来创建一个Secret：

  apiVersion:v1kind:Secretmetadata:name:myregistrykey# 镜像拉取凭证的名称（供 Pod 的 imagePullSecrets 引用）data:.dockercfg:eyAiaHR0cHM6Ly9pbmRleC5kb2NrZXIuaW8vdjEvIjogeyAiYXV0aCI6ICJab UZyWlhCaGMzTjNiM0prTVRJSyIsICJlbWFpbCI6ICJqZG9lQGV4YW1wbGUuY29tIiB9IH0K# 修正了折行缩进，确保属于 .dockercfg 的值type:kubernetes.io/dockercfg# Secret 类型，指定为旧版的 Docker 配置文件凭证类型

  # kubectl create -f image-pull-secret.yaml

• （4）在创建Pod时引用该Secret：

  apiVersion:v1kind:Podmetadata:name:mypod2# Pod 的名称spec:containers:-name:foo# 容器名称image:janedoe/awesomeapp:v1# 容器使用的私有镜像及版本imagePullSecrets:-name:myregistrykey# 引用前面创建的用于拉取私有镜像的 Secret 名称

  # kubectl create -f pods.yaml

其结果如图所示。

每个单独的Secret大小不能超过1MB，Kubernetes不鼓励创建大的Secret，因为如果使用大的Secret，则将大量占用API Server和kubelet的内存。当然，创建许多小的Secret也能耗尽API Server和kubelet的内存。

在使用Mount方式挂载Secret时，Container中Secret的data域的各个域的Key值作为目录中的文件，Value值被BASE64编码后存储在相应的文件中。在前面的例子中创建的Secret，被挂载到一个叫作mycontainer的Container中，在该Container中可通过相应的查询命令查看所生成的文件和文件中的内容，如下所示：

$ls/etc/foo/ username password $cat/etc/foo/username value-1 $cat/etc/foo/password value-2

通过上面的例子可以得出如下结论：我们可以通过Secret保管其他系统的敏感信息（比如数据库的用户名和密码）​，并以Mount的方式将Secret挂载到Container中，然后通过访问目录中文件的方式获取该敏感信息。当Pod被API Server创建时，API Server不会校验该Pod引用的Secret是否存在。一旦这个Pod被调度，则kubelet将试着获取Secret的值。如果Secret不存在或暂时无法连接到API Server，则kubelet按一定的时间间隔定期重试获取该Secret，并发送一个Event来解释Pod没有启动的原因。一旦Secret被Pod获取，则kubelet将创建并挂载包含Secret的Volume。只有所有Volume都挂载成功，Pod中的Container才会被启动。在kubelet启动Pod中的Container后，Container中和Secret相关的Volume将不会被改变，即使Secret本身被修改。为了使用更新后的Secret，必须删除旧Pod，并重新创建一个新Pod。

6、Pod的安全策略配置

为了更精细地控制Pod对资源的使用方式，Kubernetes从1.4版本开始引入了PodSecurityPolicy资源对象对Pod的安全策略进行管理，并在1.10版本中升级为Beta版，到1.14版本时趋于成熟。目前PodSecurityPolicy资源对象的API版本为extensions/v1beta1，从1.10版本开始更新为policy/v1beta1，并计划于1.16版本时弃用extensions/v1beta1。

6.1、PodSecurityPolicy的工作机制

若想启用PodSecurityPolicy机制，则需要在kube-apiserver服务的启动参数–enable-admission-plugins中进行设置：

--enable-admission-plugins=PodSecurityPolicy

在开启PodSecurityPolicy准入控制器后，Kubernetes默认不允许创建任何Pod，需要创建PodSecurityPolicy策略和相应的RBAC授权策略（Authorizing Policies）​，Pod才能创建成功。

例如，尝试创建如下Pod：

apiVersion:v1kind:Podmetadata:name:nginx# Pod 的名称spec:containers:-name:nginx# 容器名称image:nginx# 容器使用的官方 Nginx 镜像

使用kubectl命令创建时，系统将提示“禁止创建”的报错信息：

# kubectl create -f pod.yamlError from server(Forbidden): error when creating"pod.yaml":pods"nginx"is forbidden: no providers available to validate pod request

接下来创建一个PodSecurityPolicy，配置文件psp-non-privileged.yaml的内容如下：

apiVersion:policy/v1beta1kind:PodSecurityPolicymetadata:name:psp-non-privileged# PSP 策略名称：非特权策略spec:privileged:false# 禁止特权模式（不允许 Pod 具有宿主机的完整特权）seLinux:rule:RunAsAny# 允许使用任何 SELinux 上下文supplementalGroups:rule:RunAsAny# 允许使用任何附加组 IDrunAsUser:rule:RunAsAny# 允许以任何用户 ID 运行容器fsGroup:rule:RunAsAny# 允许任何文件系统组 IDvolumes:-'*'# 允许使用所有类型的存储卷（卷白名单，此处表示不限制）

使用kubectl create命令创建该PodSecurityPolicy：

# kubectl create -f psp-non-privileged.yamlpodsecuritypolicy.policy/psp-non-privileged created

查看PodSecurityPolicy：

# kubectl get psp psp-non-privilegedNAME PRIV CAPS SELINUX RUNASUSER FSGROUP SUPGROUP READONLYROOTFS VOLUMES psp-non-privilegedfalseRunAsAny RunAsAny RunAsAny RunAsAnyfalse*

再次创建Pod就能成功：

# kubectl create -f pod.yamlpod/nginx created

上面的PodSecurityPolicy“psp-non-privileged”设置了privileged: false，表示不允许创建特权模式的Pod。在下面的YAML配置文件pod-privileged.yaml中为Pod设置了特权模式：

apiVersion:v1kind:Podmetadata:name:nginx# Pod 的名称spec:containers:-name:nginx# 容器名称image:nginx# 容器使用的官方 Nginx 镜像securityContext:privileged:true# 开启特权模式（允许容器访问宿主机上的所有设备，通常用于需要底层系统权限的特殊工作负载）

创建Pod时，系统将提示“禁止创建特权模式的Pod”的报错信息：

# kubectl create -f pod-privileged.yamlError from server(Forbidden): error when creating"pod-pri.yaml":pods"nginx"is forbidden: unable to validate against any pod security policy:[spec.containers[0].securityContext.privileged: Invalid value: true: Privileged containers are not allowed]

6.2、PodSecurityPolicy配置详解

在PodSecurityPolicy对象中可以设置下列字段来控制Pod运行时的各种安全策略。

• 1．特权模式相关配置
  • privileged：是否允许Pod以特权模式运行。
• 2．宿主机资源相关配置
  • hostPID：是否允许Pod共享宿主机的进程空间。
  • hostIPC：是否允许Pod共享宿主机的IPC命名空间。
  • hostNetwork：是否允许Pod使用宿主机网络的命名空间。
  • hostPorts：是否允许Pod使用宿主机的端口号，可以通过hostPortRange字段设置允许使用的端口号范围，以[min, max]设置最小端口号和最大端口号。
  • Volumes：允许Pod使用的存储卷Volume类型，设置为“*”表示允许使用任意Volume类型，建议至少允许Pod使用下列Volume类型。
    • configMap
    • downwardAPI
    • emptyDir
    • persistentVolumeClaim
    • secret
    • projected
  • AllowedHostPaths：允许Pod使用宿主机的hostPath路径名称，可以通过pathPrefix字段设置路径的前缀，并可以设置是否为只读属性，例子如下。

    apiVersion:policy/v1beta1kind:PodSecurityPolicymetadata:name:allow-hostpath-volumes# PSP 策略名称：允许使用主机路径卷spec:volumes:-hostPath# 允许在卷类型中使用宿主机路径 (hostPath)allowedHostPaths:-pathPrefix:"/foo"# 严格限制：只允许挂载以 /foo 开头的宿主机目录readOnly:true# 设置为只读属性，防止容器内篡改宿主机对应路径的文件

    结果为允许Pod访问宿主机上以“/foo”为前缀的路径，包括“/foo”​“/foo/”​“/foo/bar”等，但不能访问“/fool”​“/etc/foo”等路径，也不允许通过“/foo/…/”表达式访问/foo的上层目录。
  • （7）FSGroup：设置允许访问某些Volume的Group ID范围，可以将规则（rule字段）设置为MustRunAs、MayRunAs或RunAsAny。
    • MustRunAs ：需要设置Group ID的范围，例如1～65535，要求Pod的securityContext.fsGroup设置的值必须属于该Group ID的范围。
    • MayRunAs：需要设置Group ID的范围，例如1～65535，不强制要求Pod设置securityContext.fsGroup。
    • RunAsAny：不限制Group ID的范围，任何Group都可以访问Volume。
  • （8）ReadOnlyRootFilesystem：要求容器运行的根文件系统（root filesystem）必须是只读的。
  • （9）allowedFlexVolumes：对于类型为flexVolume的存储卷，设置允许使用的驱动类型，例子如下。

    apiVersion:policy/v1beta1kind:PodSecurityPolicymetadata:name:allow-flex-volumes# PSP 策略名称：允许使用 FlexVolume 类型的存储卷spec:volumes:-flexVolume# 允许在卷类型中使用 FlexVolume 插件allowedFlexVolumes:-driver:example/lvm# 允许使用的 FlexVolume 驱动白名单 1：逻辑卷管理器 (LVM)-driver:example/cifs# 允许使用的 FlexVolume 驱动白名单 2：通用互联网文件系统 (CIFS)

• 3．用户和组相关配置
  • （1）RunAsUser：设置运行容器的用户ID（User ID）范围，规则字段（rule）的值可以被设置为MustRunAs、MustRunAsNonRoot或RunAsAny。
    • MustRunAs：需要设置User ID的范围，要求Pod的securityContext.runAsUser设置的值必须属于该User ID的范围。
    • MustRunAsNonRoot ：必须以非root用户运行容器，要求Pod的securityContext.runAsUser设置一个非0的用户ID，或者镜像中在USER字段设置了用户ID，建议同时设置allowPrivilegeEscalation=false以避免不必要的提升权限操作。
    • RunAsAny：不限制User ID的范围，任何User都可以运行。
  • （2）RunAsGroup：设置运行容器的Group ID范围，规则字段的值可以被设置为MustRunAs、MustRunAsNonRoot或RunAsAny。
    • MustRunAs：需要设置Group ID的范围，要求Pod的securityContext.runAsGroup设置的值必须属于该Group ID的范围。
    • MustRunAsNonRoot ：必须以非root组运行容器，要求Pod的securityContext.runAsUser设置一个非0的用户ID，或者镜像中在USER字段设置了用户ID，建议同时设置allowPrivilegeEscalation=false以避免不必要的提升权限操作。
    • RunAsAny：不限制Group ID的范围，任何Group的用户都可以运行。
  • （3）SupplementalGroups：设置容器可以额外添加的Group ID范围，可以将规则（rule字段）设置为MustRunAs、MayRunAs或RunAsAny。
    • MustRunAs ：需要设置Group ID的范围，要求Pod的securityContext. supplementalGroups设置的值必须属于该Group ID范围。
    • MayRunAs：需要设置Group ID的范围，不强制要求Pod设置securityContext.supplementalGroups。
    • RunAsAny：不限制Group ID的范围，任何supplementalGroups的用户都可以运行。
• 4．提升权限相关配置
  • （1）AllowPrivilegeEscalation：设置容器内的子进程是否可以提升权限，通常在设置非root用户（MustRunAsNonRoot）时进行设置。
  • （2）DefaultAllowPrivilegeEscalation：设置AllowPrivilegeEscalation的默认值，设置为disallow时，管理员还可以显式设置AllowPrivilegeEscalation来指定是否允许提升权限。
• 5．Linux能力相关配置
  • （1）AllowedCapabilities：设置容器可以使用的Linux能力列表，设置为“*”表示允许使用Linux的所有能力（如NET_ADMIN、SYS_TIME等）​。
  • （2）RequiredDropCapabilities：设置不允许容器使用的Linux能力列表。
  • （3）DefaultAddCapabilities：设置默认为容器添加的Linux能力列表，例如SYS_TIME等，Docker建议默认设置的Linux能力请查看https://docs.docker.com/engine/reference/run/#runtime-privilege-and-linux-capabilities。
• 6．SELinux相关配置
  seLinux：设置SELinux参数，可以将规则字段（rule）的值设置为MustRunAs或RunAsAny。
  • MustRunAs ：要求设置seLinuxOptions，系统将对Pod的securityContext. seLinuxOptions设置的值进行校验。
  • RunAsAny：不限制seLinuxOptions的设置。
• 7．其他Linux相关配置
  • （1）AllowedProcMountTypes ：设置允许的ProcMountTypes类型列表，可以设置allowedProcMountTypes或DefaultProcMount。
  • （2）AppArmor ：设置对容器可执行程序的访问控制权限，详情请参考https://kubernetes.io/docs/tutorials/clusters/apparmor/#podsecuritypolicy-annotations。
  • （3）Seccomp：设置允许容器使用的系统调用（SystemCalls）的profile。
  • （4）Sysctl：设置允许调整的内核参数，详情请参考https://kubernetes.io/docs/concepts/cluster-administration/sysctl-cluster/#podsecuritypolicy。

下面列举两种常用的PodSecurityPolicy安全策略配置。

例1：基本没有限制的安全策略，允许创建任意安全设置的Pod。

apiVersion:policy/v1beta1kind:PodSecurityPolicymetadata:name:privileged# PSP 策略名称：特权策略（最高权限）annotations:seccomp.security.alpha.kubernetes.io/allowedProfileNames:'*'# 允许使用所有的 seccomp 安全配置文件spec:privileged:true# 允许特权容器（容器内可直接访问宿主机所有内核资源）allowPrivilegeEscalation:true# 允许进程提升权限（例如通过 setuid 二进制文件）allowedCapabilities:-'*'# 允许容器获取所有的 Linux Capabilities 内核权限volumes:-'*'# 允许使用所有类型的存储卷hostNetwork:true# 允许共享宿主机的网络命名空间（可直接监听宿主机端口）hostPorts:-min:0max:65535# 允许绑定宿主机上的任意端口（0-65535）hostIPC:true# 允许共享宿主机的 IPC 命名空间hostPID:true# 允许共享宿主机的 PID 进程命名空间（可查看和管理宿主机上的所有进程）runAsUser:rule:'RunAsAny'# 允许以任意用户身份运行seLinux:rule:'RunAsAny'# 允许使用任意 SELinux 上下文supplementalGroups:rule:'RunAsAny'# 允许使用任意附加组fsGroup:rule:'RunAsAny'# 允许使用任意文件系统组

例2：要求Pod运行用户为非特权用户；禁止提升权限；不允许使用宿主机网络、端口号、IPC等资源；限制可以使用的Volume类型，等等。

apiVersion:policy/v1beta1kind:PodSecurityPolicymetadata:name:restricted# PSP 策略名称：受限策略（高安全性，强制非特权与最小权限）annotations:seccomp.security.alpha.kubernetes.io/allowedProfileNames:'docker/default'# 允许使用的 seccomp 配置文件白名单apparmor.security.beta.kubernetes.io/allowedProfileNames:'runtime/default'# 允许使用的 AppArmor 配置文件白名单seccomp.security.alpha.kubernetes.io/defaultProfileName:'docker/default'# 默认应用的 seccomp 配置文件apparmor.security.beta.kubernetes.io/defaultProfileName:'runtime/default'# 默认应用的 AppArmor 配置文件spec:privileged:false# 禁止特权模式allowPrivilegeEscalation:false# 禁止进程提升权限requiredDropCapabilities:-ALL# 强制剥夺容器默认获得的所有 Linux 权限（Capabilities）volumes:-'configMap'# 允许挂载的存储卷白名单：ConfigMap-'emptyDir'# 允许挂载的存储卷白名单：EmptyDir-'projected'# 允许挂载的存储卷白名单：Projected-'secret'# 允许挂载的存储卷白名单：Secret-'downwardAPI'# 允许挂载的存储卷白名单：DownwardAPI-'persistentVolumeClaim'# 允许挂载的存储卷白名单：PVChostNetwork:false# 禁止共享宿主机网络命名空间hostIPC:false# 禁止共享宿主机 IPC 命名空间hostPID:false# 禁止共享宿主机进程命名空间runAsUser:rule:'MustRunAsNonRoot'# 强制要求：必须以非 root 用户运行容器seLinux:rule:'RunAsAny'# 允许使用任意 SELinux 上下文supplementalGroups:rule:'MustRunAs'# 强制限制附加组范围ranges:-min:1max:65535# 附加组 ID 必须在 1 到 65535 之间（排除 root 组 0）fsGroup:rule:'MustRunAs'# 强制限制文件系统组范围ranges:-min:1max:65535# 文件系统组 ID 必须在 1 到 65535 之间readOnlyRootFilesystem:false# 允许根文件系统可写（注：若追求极致安全，通常会设为 true）

此外，Kubernetes建议使用RBAC授权机制来设置针对Pod安全策略的授权，通常应该对Pod的ServiceAccount进行授权。

例如，可以创建如下ClusterRole（也可以创建Role）并将其设置为允许使用PodSecurityPolicy：

apiVersion:rbac.authorization.k8s.io/v1kind:ClusterRolemetadata:name:<role name># 集群角色的名称（例如：use-restricted-psp）rules:-apiGroups:['policy']resources:['podsecuritypolicies']# 资源类型为 PodSecurityPolicyverbs:['use']# 核心动词：use（允许主体使用指定的策略）resourceNames:-<list of policies to authorize># 严格限定：允许使用的 PSP 列表（例如：['restricted', 'non-privileged']）

然后创建一个ClusterRoleBinding与用户和ServiceAccount进行绑定：

apiVersion:rbac.authorization.k8s.io/v1kind:ClusterRoleBindingmetadata:name:<binding name># 集群角色绑定的名称roleRef:kind:ClusterRolename:<role name># 之前创建的 ClusterRole 名称（例如：use-restricted-psp）apiGroup:rbac.authorization.k8s.iosubjects:# 对特定 Namespace 中的 ServiceAccount 进行授权-kind:ServiceAccountname:<authorized service account name># ServiceAccount 的名称namespace:<authorized pod namespace># ServiceAccount 所在的命名空间# 对特定用户进行授权（注：生产环境中通常不推荐直接绑定普通 User，更建议使用 ServiceAccount 或 Group）-kind:UserapiGroup:rbac.authorization.k8s.ioname:<authorized user name># 被授权的具体用户名

也可以创建RoleBinding对与该RoleBinding相同的Namespace中的Pod进行授权，通常可以与某个系统级别的Group关联配置，例如：

apiVersion:rbac.authorization.k8s.io/v1kind:RoleBindingmetadata:name:<binding name># RoleBinding 的名称namespace:<binding namespace># 该 RoleBinding 生效及所属的 NamespaceroleRef:kind:Role# 引用命名空间级别的 Role（如果是跨命名空间引用集群级权限，请使用 ClusterRole）name:<role name># 被引用的角色名称apiGroup:rbac.authorization.k8s.iosubjects:# 授权该 Namespace 中的全部 ServiceAccount（通过 Kubernetes 内置的系统组名实现）-kind:GroupapiGroup:rbac.authorization.k8s.ioname:system:serviceaccounts# 对应当前 Namespace 内的所有 ServiceAccount# 授权该 Namespace 中的全部已认证用户（通过内置系统组名实现）-kind:GroupapiGroup:rbac.authorization.k8s.ioname:system:authenticated# 对应当前 Namespace 内的所有已认证（Authenticated）用户

6.3、Pod的安全设置详解

在系统管理员对Kubernetes集群中设置了PodSecurityPolicy策略之后，系统将对Pod和Container级别的安全设置进行校验，对于不满足PodSecurityPolicy安全策略的Pod，系统将拒绝创建。

Pod和容器的安全策略可以在Pod或Container的securityContext字段中进行设置，如果在Pod和Container级别都设置了相同的安全类型字段，容器将使用Container级别的设置。

在Pod级别可以设置的安全策略类型如下。

• runAsUser：容器内运行程序的用户ID。
• runAsGroup：容器内运行程序的用户组ID。
• runAsNonRoot：是否必须以非root用户运行程序。
• fsGroup：SELinux相关设置。
• seLinuxOptions：SELinux相关设置。
• supplementalGroups：允许容器使用的其他用户组ID。
• sysctls：设置允许调整的内核参数。

在Container级别可以设置的安全策略类型如下。

• runAsUser：容器内运行程序的用户ID。
• runAsGroup：容器内运行程序的用户组ID。
• runAsNonRoot：是否必须以非root用户运行程序。
• privileged：是否以特权模式运行。
• allowPrivilegeEscalation：是否允许提升权限。
• readOnlyRootFilesystem：根文件系统是否为只读属性。
• capabilities：Linux能力列表。
• seLinuxOptions：SELinux相关设置。

下面通过几个例子对Pod的安全设置进行说明。

例1：Pod级别的安全设置，作用于该Pod内的全部容器。

apiVersion:v1kind:Podmetadata:name:security-context-demo# Pod 的名称spec:securityContext:runAsUser:1000# 强制指定 Pod 内所有容器默认以 UID 1000（非 root 用户）运行runAsGroup:3000# 强制指定容器进程的主 GID 为 3000fsGroup:2000# 配置卷的文件系统组 ID（当卷被挂载时，其所有权将变更为 GID 2000）volumes:-name:sec-ctx-vol# 定义一个名为 sec-ctx-vol 的存储卷（类型为 emptyDir）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# 禁止该容器内的进程获取比父进程更多的特权（常用于防止提权攻击）

在spec.securityContext中设置了如下参数。

• runAsUser=1000：所有容器都将以User ID 1000运行程序，所有新生成文件的User ID也被设置为1000。
• runAsGroup=3000：所有容器都将以Group ID3000运行程序，所有新生成文件的Group ID也被设置为3000。
• fsGroup=2000：挂载的卷“/data/demo”及其中创建的文件都将属于Group ID 2000。

创建该Pod之后进入容器环境，查看到运行进程的用户ID为1000：

# ps auxUSERPID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND100010.00.04336724? Ss18:160:00 /bin/sh-cnodeserver.js100050.20.677212422768? Sl18:160:00nodeserver.js......

查看从Volume挂载到容器的/data/demo目录，其GroupID为2000：

# ls -l /datadrwxrwsrwx2root20004096Jun620:08 demo

在该目录下创建一个新文件，可见其用户ID为1000，组ID 为2000：

# cd demo# touch hello# ls -l-rw-r--r--1100020006Mar610:10 hello

例2：Container级别的安全设置，作用于特定的容器。

apiVersion:v1kind:Podmetadata:name:security-context-demo-2# Pod 的名称spec:securityContext:runAsUser:1000# Pod 级别的默认安全上下文：指定默认以 UID 1000 运行containers:-name:sec-ctx-demo-2# 容器名称image:gcr.io/google-samples/node-hello:1.0# 容器镜像securityContext:runAsUser:2000# 容器级别的安全上下文：覆盖 Pod 级别的设置，强制该特定容器以 UID 2000 运行allowPrivilegeEscalation:false# 禁止该容器进程进行权限提升

创建该Pod之后进入容器环境，查看到运行进程的用户ID为2000：

# ps auxUSERPID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND200010.00.04336764? Ss20:360:00 /bin/sh-cnodeserver.js200080.10.577212422604? Sl20:360:00nodeserver.js......

例3：为Container设置可用的Linux能力，为容器设置允许使用的Linux能力包括NET_ADMIN和SYS_TIME。

apiVersion:v1kind:Podmetadata:name:security-context-demo-4# Pod 的名称spec:containers:-name:sec-ctx-4# 容器名称image:gcr.io/google-samples/node-hello:1.0# 容器镜像securityContext:capabilities:add:# 为容器单独添加额外的 Linux 内核 Capabilities-NET_ADMIN# 允许进行网络配置管理（如修改路由表、防火墙规则等）-SYS_TIME# 允许调整系统时钟

创建该Pod之后进入容器环境，查看1号进程的Linux能力设置：

# cd /proc/1# cat status... CapPrm: 00000000aa0435fb CapEff: 00000000aa0435fb

未设置这两个能力的配置为：

CapPrm: 00000000a80425fb CapEff: 00000000a80425fb

可以看到系统在第12位和第25位添加了CAP_NET_ADMIN和CAP_SYS_TIME这两个Linux能力。