加强 Pod 安全
如何在Pod级别为应用定义安全上下文环境?例如,以非特权进程运行该应用,或者限制该应用可以访问的卷的类别
在Pod的spec中使用securityContext字段。
例如以非root用户运行一个应用:
kind: Pod apiVersion: v1 metadata: name: secpod spec: containers: - name: shell image: centos:7 command: - "sh" - "-c" - "whatever" securityContext: runAsUser: 5000
spec.securityContext
Configure a Security Context for a Pod or Container | Kubernetes
Kubernetes API Reference Docs/SecurityContext v1 core
runAsUser:指定运行进程的用户(UID);
runAsGroup:指定运行进程的组(GID,Primary);如果未指定该参数,则默认属于 root 组(GID==0);
fsGroup:指定运行进程的附属组(GID,Supplementary);在 Volume 中已创建的文件也将属于该组,同时组内用户具有 rw 权限;
cat > security-context-demo.yaml <<EOF --- apiVersion: v1 kind: PersistentVolumeClaim metadata: name: security-context-demo spec: accessModes: - ReadWriteOnce resources: requests: storage: 10Gi storageClassName: nfs-client --- apiVersion: apps/v1 kind: Deployment metadata: name: security-context-demo labels: app: security-context-demo spec: replicas: 1 selector: matchLabels: app: security-context-demo template: metadata: labels: app: security-context-demo spec: securityContext: runAsUser: 1000 runAsGroup: 1000 fsGroup: 1000 volumes: - name: sec-ctx-vol persistentVolumeClaim: claimName: security-context-demo containers: - name: sec-ctx-demo image: busybox:1.28 command: [ "sh", "-c", "sleep 1h" ] volumeMounts: - name: sec-ctx-vol mountPath: /data/demo EOF kubectl apply -f security-context-demo.yaml
SecurityContext vs. PodSecurityContext
虽然 container 也能够配置 securityContext 属性,但是其为 SecurityContext 对象,而非 PodSecurityContext 对象;
并且 SecurityContext 属性并不能对 Volume 进行修改;
已知问题及限制
部分文件系统无法支持 SecurityContext 特性,例如:
1)在 NFS 中,fsGroup 无法修改文件系统的属组;
2)在 Ceph 中,SecurityContext 能够正常工作;
PodSecurityPolicy
另外一个加强安全级别的方法是使用更强大的「Pod安全策略」(PSP, Pod Security Policies)。可以定义一系列策略,包括一些与上述类似的操作,以及与存储和网络相关的限制。
Removed feature: PodSecurityPolicy was deprecated in Kubernetes v1.21, and removed from Kubernetes in v1.25.
相关链接
Secure A Kubernetes Cluster With Pod Security Policies
Kubernetes/Concepts/Pod Security Policies