CKS 认证考试核心题型实战解析与避坑指南

kubectl create role role-2 --verb=update --resource=persistentvolumeclaims -n monitoring
kubectl create rolebinding role-2-binding --role=role-2 --serviceaccount=monitoring:sa-dev-1 -n monitoring

4. AppArmor 强制实施

场景： 在 Worker 节点加载 AppArmor 配置文件，并在 Pod Manifest 中应用该 Profile。

操作思路：

1. 加载 Profile： 在 Worker 节点使用 apparmor_parser 加载 /etc/apparmor.d/nginx_apparmor。
2. 修改 Pod YAML： 在 Pod 的 annotations 中添加 container.apparmor.security.beta.kubernetes.io/<container_name>: localhost/<profile_name>。
3. 应用配置： kubectl apply -f <pod_manifest>。

5. PodSecurityPolicy (PSP)

场景： 防止特定 Namespace 中创建特权 Pod。

操作思路：

1. 启用 PSP 插件： 检查 kube-apiserver.yaml 是否包含 PodSecurityPolicy 插件，必要时重启 Kubelet。
2. 创建 Policy： 定义 prevent-psp-policy，设置 privileged: false。
3. 创建 ClusterRole： 授予 use 权限给该 PSP。
4. 创建 ServiceAccount 与 Binding： 在 development 命名空间创建 SA，并建立 ClusterRoleBinding 关联。

6. 网络策略 (NetworkPolicy)

场景： 限制 products-service 的访问来源，仅允许 testing 命名空间的 Pod 或带有 environment: staging 标签的 Pod。

操作思路：

1. 检查标签： 确认相关 Pod 和命名空间的标签是否正确。
2. 编写策略： 使用 namespaceSelector 和 podSelector 组合匹配来源。
3. 应用策略： 确保 policyTypes 包含 Ingress。

7. Dockerfile 与 YAML 安全加固

场景： 修复 Dockerfile 中的安全风险（如 root 用户运行）及 Deployment YAML 中的最佳实践问题（如特权模式、镜像版本）。

建议：

• Dockerfile 中应使用非 root 用户（如 USER appuser）。
• YAML 中避免 privileged: true，指定具体的镜像版本号而非 latest。

8. Pod 无状态与不可变性检查

场景： 删除不符合'无状态'或'不可变'定义的 Pod。

判断标准：

• 存储数据（有 Volume）视为非无状态。
• 配置为 privileged 视为潜在非不可变。

操作： 通过 JSONPath 或 YAML 检查 volumes 和 securityContext.privileged，删除不合规 Pod。

9. 创建受限 ServiceAccount

场景： 创建 SA 且禁止自动挂载 Secret Token。

操作思路：

1. 创建 SA： 使用 --dry-run 获取模板。
2. 修改 Pod： 在 Pod Spec 中设置 automountServiceAccountToken: false，并指定新的 serviceAccountName。

10. Trivy 镜像漏洞扫描

场景： 使用 Trivy 扫描 yavin 命名空间中 Pod 使用的镜像，找出 High/Critical 漏洞并删除 Pod。

操作思路：

1. 连接 Master 节点： Trivy 预装在 Master 上。
2. 扫描镜像： 提取 Pod 镜像列表，使用 Trivy 扫描。
3. 清理： 删除使用高危镜像的 Pod。

11. Secret 管理与挂载

场景： 导出旧 Secret 字段，创建新 Secret，并将新 Secret 挂载到 Pod 卷中。

操作思路：

1. 导出： kubectl get secret ... -o yaml，解码 base64 内容保存至文件。
2. 创建： kubectl create secret generic ... --from-literal=...。
3. 挂载： 在 Pod 定义中使用 volumeMounts 和 volumes 引用 Secret。

12. Kube-bench 安全基线修复

场景： 根据 ACIS Benchmark 报告修复 API Server 和 Kubelet 的配置违规项。

常见修复点：

• authorization-mode 必须包含 Node,RBAC，不能是 AlwaysAllow。
• insecure-port 应设为 0。
• anonymous-auth 应设为 false。

操作： 修改 /etc/kubernetes/manifests/kube-apiserver.yaml 和 Kubelet 配置，重启组件使配置生效。

13. gVisor RuntimeClass

场景： 配置 Containerd 支持 gVisor (runsc)，并创建 RuntimeClass 供 Pod 使用。

操作思路：

1. 创建 RuntimeClass： 定义 handler: runsc。
2. 更新 Pod： 在 Pod Spec 中添加 runtimeClassName: untrusted。

14. 审计日志配置

场景： 启用审计日志后端，保留 5 天，最多 10 个文件，并配置策略记录特定资源变更。

操作思路：

1. 修改 API Server 参数： 添加 --audit-policy-file, --audit-log-path, --audit-log-maxage, --audit-log-maxbackup。
2. 配置策略： 编辑 YAML，定义 namespaces, pods, secrets 等资源的 level（RequestResponse/Metadata）。
3. 挂载卷： 确保日志路径在 Pod 内可写。

15. 默认拒绝网络策略

场景： 创建 default-deny NetworkPolicy 阻断所有 Ingress 流量。

操作思路： 使用空的 podSelector: {} 配合 policyTypes: [Ingress]，即可实现该命名空间下所有入站流量的默认拒绝。

16. Falco 规则自定义

场景： 修改 Falco 输出格式，使其符合特定要求（如时间戳、用户名、容器名等）。

操作思路：

1. 编辑规则： 修改 /etc/falco/falco_rules.local.yaml。
2. 调整 Output： 在 output 字段中定义格式化字符串，例如 %evt.time,%user.name,%container.name。
3. 重启服务： systemctl restart falco 使配置生效。

总结： CKS 考试重在实操细节，尤其是配置文件的路径、参数名称以及命令行的精确执行。建议在练习环境中反复验证每个步骤，特别是涉及静态 Pod 修改和组件重启的场景。