配置容器级别的安全控制
使用宿主机的网络模式
可以通过设置pod的spec的hostNetwork参数为true开启容器的“host”network模式
spec:
hostNetwork: true
containers:
- name: name
image: Enter containers image
绑定宿主机的端口
这种方式不需要创建service来做port映射，相当于docker中的-p映射端口的操作
spec:
containers:
- name: name
image: Enter containers image
ports:
# 容器内部的端口
- containerPort: 8080
# 映射在宿主机上的端口
hostPort: 9000
protocol: TCP
使用宿主机的PID和IPC命名空间
通过开启pod的spec.hostPID使用宿主机的pid，同样通过开始hostIPC使用宿主机的ipc
spec:
hostPID: true
hostIPC: true
containers:
- name: name
image: Enter containers image
将hostPID设置为true，pod内就可以看到宿主机上的所有进程pid，同时自己的进程也会有宿主机管理。
将hostIPC设置为true，pod中的进程就可以与宿主机上的其他所有进程进行通信。
配置pod的安全上下文
针对于container级别的控制
指定运行容器的用户
spec:
containers:
- name: name
image: Enter containers image
securityContext:
# 405为容器中用户的id，这里仅可以通过id指定运行容器的用户
runAsUser: 405
阻止容器以root用户运行
有的应用在容器中设置了运行用户，然后可能会有黑客上传一个以root用户运行的镜像到我们的镜像仓库。然后在容器中利用root用户
的权限，这样是很危险的，所以我们可以禁用容器中的root用户，让他不能以root用户启动容器
spec:
containers:
- name: name
image: Enter containers image
securityContext:
runAsNonRoot: true
使用特权模式启动容器
使容器具有宿主机上的所有操作权限,这样容器中就可以使用宿主机上的设备了
spec:
containers:
- name: name
image: Enter containers image
securityContext:
privileged: true
为容器添加linux内核的功能
使用特权模式启动的容器被赋予了过大的权限，我们可以根据需求给予容器所需的linux内核的能力。
spec:
containers:
- name: name
image: Enter containers image
securityContext:
# 通过capabilities开启或者禁用linux的内核功能
capabilities:
# 授予容器能力
add:
- SYS_TIME
# 禁用容器能力
drop:
- CHOWN
注意：在linux中内核功能通常以CAP_开头，这里需要省略掉
阻止容器对根目录的写入
spec:
containers:
- name: test-container
image: test-container
imagePullPolicy: IfNotPresent
securityContext:
# 这个容器的根目录不允许写入操作
readOnlyRootFilesystem: true
volumeMounts:
# 但是允许向volume目录写入，这个目录是一个挂载卷
- mountPath: /volume
name: test-volume
readOnly: false
volumes:
- name: test-volume
emptyDir: {}
问题：如果不采用挂载的方式，可否将一个目录释放出来允许写入呢？
pod级别的安全上下文
容器使用不同用户运行时共享存储卷
当一个pod中的两个容器都使用root用户运行时，他们之前可以互相读取对方的挂载卷。但是，当我们为每个容器配置其他的启动用户时，
可以会出现一些访问权限的问题。
在kubernetes中，可以为pod中的容器指定一个supplemental组，以允许他们无论通过哪个用户启动容器都可以共享文件。
spec:
securityContext:
# 用户组id设置为555，则创建存储卷时存储卷属于用户ID为555的用户组
fsGroup: 555
# 定义了某个用户所关联的额外的用户组
supplementalGroups:
- 666
- 777
containers:
- name: test-A
image: test-container
imagePullPolicy: IfNotPresent
securityContext:
runAsUser: 01
volumeMounts:
- mountPath: /volume
name: test-volume
readOnly: false
- name: test-B
image: test-container
imagePullPolicy: IfNotPresent
securityContext:
runAsUser: 02
volumeMounts:
- mountPath: /volume
name: test-volume
readOnly: false
volumes:
- name: test-volume
emptyDir: {}
在pod级别指定fsGroup与supplementalGroups属性，然后分别指定两个容器的启动用户为01、02。然后在启动容器，在容器中执行id命令
可以查看容器的用户和用户组，然后就可以看到两个容器虽然用户不同，但是都属于“555、666、777”这三个组中。
统一限制pod的安全相关特性 PodSecurityPolicy
PodSecurityPolicy在kubernetes中简称为psp，主要定义了用户能否在pod中使用各种安全相关的特性。
当有人调用api server创建pod时，PodSecurityPolicy会拿到这个pod的信息与自己个规则做比较。如果符合规则，就运行其存入etcd；否则会被拒绝。
因为是在创建pod时校验的，所以修改psp，不会对已创建的pod采取措施。也可以设置默认值，就是用psp中配置的默认值替换掉pod中的值。
主要提供了以下能力：
- 是否允许pod使用宿主节点的PID、IPC、网络命名空间
- pod允许绑定的宿主节点端口
- 容器运行时允许使用的用户ID
- 是否允许拥有特权模式容器的pod
- 允许添加哪些内核功能， 默认添加哪些内核功能， 总是禁用哪些内核功能
- 允许容器使用哪些 SELinux 选项
- 容器是否允许使用可写的根文件系统
- 允许容器在哪些文件系统组下运行
- 允许pod使用哪些类型的存储卷
以下为demo：
apiVersion: policy/v1beta1
kind: PodSecurityPolicy
metadata:
name: exporter-node-cluster-monitoring
spec:
allowPrivilegeEscalation: false
# 强制使用只读的根文件系统
readOnlyRootFilesystem: true
# 不允许使用特权方式运行容器
privileged: false
allowedHostPaths:
- pathPrefix: /
readOnly: true
# 指定容器可以使用的用户组id范围
fsGroup:
ranges:
- max: 65535
min: 1
rule: MustRunAs
supplementalGroups:
ranges:
- max: 65535
min: 1
rule: MustRunAs
# 允许使用宿主机的网络命名空间
hostNetwork: true
# 允许使用宿主机的PID
hostPID: true
# 允许使用宿主机的IPC
hostIPC: true
# 只允许绑定宿主机的9796端口，和1000~1080的端口
hostPorts:
- max: 9796
min: 9796
- max: 1000
min: 1080
# 可以使用任意用户运行
runAsUser:
rule: RunAsAny
# 可以使用seLinux的任意规则
seLinux:
rule: RunAsAny
# 支持的挂载方式
volumes:
- configMap
- emptyDir
- projected
- secret
- downwardAPI
- persistentVolumeClaim
- hostPath
配置允许、默认添加、禁用内核功能
apiVersion: policy/v1beta1
kind: PodSecurityPolicy
metadata:
name: exporter-node-cluster-monitoring
spec:
# 允许容器添加SYS_TIME功能
allowedCapabilities:
- SYS_TIME
# 为每个容器添加CHOWN能力
defaultAddCapabilities:
- CHOWN
# 要求容器禁用SYS_ADMIN和SYS_MODULE
requiredDropCapabilities:
- SYS_ADMIN
- SYS_MODULE
利用RBAC分配PodSecurityPolicy
psp属于集群级别的资源，所以默认是作用于整个集群的。但是我们有时候只需要针对某些应用采用这些设置。可以通过创建一个ClusterRole然后将其
指向一个psp，再通过使用ClusterRoleBinding到不同的用户，这样的话这个psp的规则就只作用于这个用户创建的pod了。
kubectl create clusterrole psp -privileged --verb=use --resource=podsecuritypolicies --resource-name=privileged
注意：这里的verb采用的是use
然后再将这个clusterrole绑定到用户或者用户组上就可以了
pod间的访问隔离
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: networkPolicy-demo
spec:
# 允许可以访问哪些pod
# 当标签中为空时，表示不允许任何pod访问
podSelector:
配置同一命名空间(foo)下的相互访问权限
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: networkPolicy-demo
namespace: foo
spec:
# 允许哪些pod可以访问当前命名空间中的pod
podSelector:
matchLabels:
app: mysql
ingress:
- from:
# 允许哪个pod可以访问
- podSelector:
matchLabels:
app: service-a
# 允许被访问的pod
- ports:
- 3306
配置跨命名空间的访问权限
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: networkPolicy-demo
namespace: foo
spec:
# 允许哪些pod可以访问当前命名空间中的pod
podSelector:
matchLabels:
app: service-b
ingress:
- from:
# 允许带有标签为（tenant=service-a）的命名空间中的pod访问
- namespaceSelector:
matchLabels:
tenant: service-a
- ports:
- 80
可以通过网段限制进入的流量
ingress:
- from:
# 值允许来自ip端为192.168.1.0/24的流量
- ipBlock:
cidr: 192.168.1.0/24
- ports:
- 3306
限制pod流出流量
spec:
podSelector:
matchLabels:
app: service-b
egress:
- to:
# 只允许流量流出到标签为（app=service-c）的pod
- podSelector:
matchLabels:
app: service-c