测验：系统加固

什么最准确地解释了为什么 securityContext 中的privileged: true 是危险的？

• 容器按原样使用主机的网络命名空间并到达节点端口。
• 容器以 root UID 运行
• 根文件系统变得可写。
• 授予所有功能、允许访问所有设备以及禁用 AppArmor、SELinux 和 seccomp 全部同时发生。

seccompProfile 的类型指定为 Localhost，但 Pod 未启动。最可能的原因是什么？

• seccomp 只能在容器级别设置
• 必须与 RuntimeDefault 一起使用
• PodSecurity 的基线配置文件禁止 Localhost
• 节点上不存在 localhostProfile 中指定的配置文件。

如何创建一个具有最小权限且需要打开 80 端口的 Web 服务器容器？

• 设置privileged: true 并将 runAsUser 设置为 1000。
• 将 NET_ADMIN 添加到 features.add
• 将 ALL 放入 features.drop 中，仅将 NET_BIND_SERVICE 放入 add 中
• hostNetwork: true 直接使用节点端口

具有 hostPID: true 的容器如何从其他工作负载读取机密？

• 直接读取节点的etcd数据目录
• 使用 kubelet 的只读端口调用 Secret API。
• 从另一个进程的 /proc//environ 读取环境变量
• 转储 CNI 的 eBPF 图

在 Kubernetes 1.30 及更高版本中指定 AppArmor 配置文件的规范方法是什么？

• securityContext.appArmorProfile 字段
• container.apparmor.security.beta.kubernetes.io/ 注解
• RuntimeClass 处理程序值
• PodSecurity 命名空间标签

应用 readOnlyRootFilesystem: true 的容器无法写入临时文件。正确的反应是什么？

• 将 readOnlyRootFilesystem 设置回 false
• 在节点上挂载 /tmp 作为 hostPath 卷。
• 将emptyDir卷挂载到需要写入的路径上。
• 将allowPrivilegeEscalation 设置为true