1、Pod 指定 ServiceAccount
Task 1. 在现有 namespace qa 中创建一个名为 backend-sa 的新 ServiceAccount， 确保此
ServiceAccount 不自动挂载 API 凭据。 2. 使用 /cks/sa/pod1.yaml 中的清单文件来创建一个 Pod。
3. 最后，清理 namespace qa 中任何未使用的 ServiceAccount。
2、RBAC - RoleBinding
Context 绑定到 Pod 的 ServiceAccount 的 Role 授予过度宽松的权限。完成以下项目以减少权限集。 Task
一个名为 web-pod 的现有 Pod 已在 namespace db 中运行。 编辑绑定到 Pod 的 ServiceAccount
service-account-web 的现有 Role， 仅允许只对 services 类型的资源 执行 get 操作。 在
namespace db 中创建一个名为 role-2 ，并仅允许只对 namespaces 类型的资源执行 delete 操作的新
Role。 创建一个名为 role-2-binding 的新 RoleBinding，将新创建的 Role 绑定到 Pod 的
ServiceAccount。 注意：请勿删除现有的 RoleBinding。
3、启用 API server 认证
Context 由 kubeadm 创建的 cluster 的 Kubernetes API 服务器，出于测试目的，
临时配置允许未经身份验证和未经授权的访问，授予匿名用户 cluster-admin 的访问权限. Task 重新配置 cluster 的
Kubernetes APl 服务器，以确保只允许经过身份验证和授权的 REST 请求。 使用授权模式 Node,RBAC 和准入控制器
NodeRestriction。 删除用户 system:anonymous 的 ClusterRoleBinding 来进行清理。
注意：所有 kubectl 配置环境/文件也被配置使用未经身份验证和未经授权的访问。 你不必更改它，但请注意，一旦完成 cluster
的安全加固， kubectl 的配置将无法工作。 您可以使用位于 cluster 的 master 节点上，cluster 原本的
kubectl 配置文件 /etc/kubernetes/admin.conf ，以确保经过身份验证的授权的请求仍然被允许。
4、Sysdig & falco
Task： 使用运行时检测工具来检测 Pod tomcat 单个容器中频发生成和执行的异常进程。 有两种工具可供使用： ⚫ sysdig
⚫ falco 注： 这些工具只预装在 cluster 的工作节点，不在 master 节点。 使用工具至少分析 30 秒
，使用过滤器检查生成和执行的进程，将事件写到 /opt/KSR00101/incidents/summary 文 件中，
其中包含检测的事件， 格式如下： [timestamp],[uid],[processName] 保持工具的原始时间戳格式不变。 注：
确保事件文件存储在集群的工作节点上。
5、 容器安全，删除特权 Pod
Task 检查在 namespace production 中运行的 Pod，并删除任何非无状态或非不可变的 Pod。
使用以下对无状态和不可变的严格解释： ⚫ 能够在容器内存储数据的 Pod 的容器必须被视为非无状态的。
注意：你不必担心数据是否实际上已经存储在容器中。 ⚫ 被配置为任何形式的特权 Pod 必须被视为可能是非无状态和非不可变的。
6、沙箱运行容器 gVisor
Context 该 cluster 使用 containerd 作为 CRI 运行时。containerd 的默认运行时处理程序是
runc。 containerd 已准备好支持额外的运行时处理程序 runsc (gVisor)。 Task 使用名为 runsc
的现有运行时处理程序，创建一个名为 untrusted 的 RuntimeClass。 更新 namespace server 中的所有
Pod 以在 gVisor 上运行。 您可以在 /cks/gVisor/rc.yaml 中找到一个模版清单
7、Pod 安全策略-PSP
Context PodSecurityPolicy 应防在特定 namespace 中特权 Pod 的创建。 Task 创建一个名为
restrict-policy 的新的 PodSecurityPolicy，以防止特权 Pod 的创建。 创建一个名为
restrict-access-role 并使用新创建的 PodSecurityPolicy restrict-policy 的
ClusterRole。 在现有的 namespace staging 中创建一个名为 psp-denial-sa 的新
ServiceAccount 。最后，创建一个名为 dany-access-bind 的 ClusterRoleBinding ，
将新创建的 ClusterRole restrict-access-role 绑定到新创建的 ServiceAccount
psp-denial-sa。 你可以在一下位置找到模版清单文件： /cks/psp/psp.yaml
8、创建 Secret
Task 在 namespace istio-system 中获取名为 db1-test 的现有 secret 的内容 将 username
字段存储在名为 /cks/sec/user.txt 的文件中，并将 password 字段存储在名为 /cks/sec/pass.txt
的文件 中。注意：你必须创建以上两个文件，他们还不存在。 注意：不要在以下步骤中使用/修改先前创建的文件，如果需要，可以创建新的临时文件。
在 istio-system namespace 中创建一个名为 db2-test 的新 secret，内容如下： username :
production-instance password : KvLftKgs4aVH 最后，创建一个新的 Pod，它可以通过卷访问
secret db2-test ： Pod 名称 secret-pod Namespace istio-system 容器名
dev-container 镜像 nginx 卷名 secret-volume 挂载路径 /etc/secret
9、AppArmor
Context APPArmor 已在 cluster 的工作节点上被启用。一个 APPArmor 配置文件已存在，但尚未被实施 Task
在 cluster 的工作节点上，实施位于 /etc/apparmor.d/nginx_apparmor 的现有 APPArmor
配置文件。 编辑位于 /home/candidate/KSSH00401/nginx-deploy.yaml 的现有清单文件以应用
AppArmor 配置文件。 最后，应用清单文件并创建其中指定的 Pod 。
10、kube-bench 修复不安全项
Context 针对 kubeadm 创建的 cluster 运行 CIS 基准测试工具时， 发现了多个必须立即解决的问题。 Task
通过配置修复所有问题并重新启动受影响的组件以确保新的设置生效。 修复针对 API 服务器发现的所有以下违规行为： 1.2.7 Ensure
that the --authorization-mode argument is not set to AlwaysAllow 1.2.8
Ensure that the --authorization-mode argument includes Node 1.2.9
Ensure that the --authorization-mode argument includes RBAC 1.2.18
Ensure that the --insecure-bind-address argument is not set 1.2.19
Ensure that the --insecure-port argument is set to 0 FAIL FAIL FAIL
FAIL FAIL 修复针对 kubelet 发现的所有以下违规行为： Fix all of the following
violations that were found against the kubelet: 4.2.1 Ensure that the
anonymous-auth argument is set to false 4.2.2 Ensure that the
–authorization-mode argument is not set to AlwaysAllow FAIL FAIL 注意：尽可能使用 Webhook 身份验证/授权。 修复针对 etcd 发现的所有以下违规行为： Fix all of the
following violations that were found against etcd: 2.2 Ensure that the
–client-cert-auth argument is set to true FAIL
11、网络策略 NetworkPolicy
Task 创建一个名为 pod-restriction 的 NetworkPolicy 来限制对在 namespace dev-team
中运行的 Pod products-service 的访问。 只允许以下 Pod 连接到 Pod products-service ⚫
namespace qa 中的 Pod ⚫ 位于任何 namespace，带有标签 environment: testing 的 Pod
注意：确保应用 NetworkPolicy。 你可以在/cks/net/po.yaml 找到一个模板清单文件。
12、Dockerfile 检测
Task 分析和编辑给定的 Dockerfile /cks/docker/Dockerfile（基于 ubuntu:16.04 镜像），
并修复在文件中拥有的突出的安全/最佳实践问题的两个指令。 分析和编辑给定的清单文件 /cks/docker/deployment.yaml
， 并修复在文件中拥有突出的安全/最佳实践问题的两个字段。
注意：请勿添加或删除配置设置；只需修改现有的配置设置让以上两个配置设置都不再有安全/最佳实践问题。
注意：如果您需要非特权用户来执行任何项目，请使用用户 ID 65535 的用户 nobody 。 答题： 注意，本次的 Dockerfile
和 deployment.yaml 仅修改即可，无需部署。
13、ImagePolicyWebhook 容器镜像扫描
Context cluster 上设置了容器镜像扫描器，但尚未完全集成到 cluster 的配置中。
完成后，容器镜像扫描器应扫描并拒绝易受攻击的镜像的使用。 Task 注意：你必须在 cluster 的 master
节点上完成整个考题，所有服务和文件都已被准备好并放置在该节点上。 给定一个目录 /etc/kubernetes/epconfig
中不完整的配置以及具有 HTTPS 端点 https://acme.local:8082/image_policy 的功能性容器镜像扫描器：
- 启用必要的插件来创建镜像策略 2. 校验控制配置并将其更改为隐式拒绝（implicit deny） 3. 编辑配置以正确指向提供的 HTTPS 端点 最后，通过尝试部署易受攻击的资源 /cks/img/web1.yaml 来测试配置是否有效。 你可以在
/var/log/imagepolicy/roadrunner.log 找到容器镜像扫描仪的日志文件。
14、Trivy 扫描镜像安全漏洞
Task 使用 Trivy 开源容器扫描器检测 namespace kamino 中 Pod 使用的具有严重漏洞的镜像。 查找具有 High
或 Critical 严重性漏洞的镜像，并删除使用这些镜像的 Pod。 注意：Trivy 仅安装在 cluster 的 master
节点上， 在工作节点上不可使用。 你必须切换到 cluster 的 master 节点才能使用 Trivy
15、默认网络策略
Context 一个默认拒绝（default-deny）的 NetworkPolicy 可避免在未定义任何其他 NetworkPolicy
的 namespace 中 意外公开 Pod。 Task 为所有类型为 Ingress+Egress 的流量在 namespace
testing 中创建一个名为 denypolicy 的新默认拒绝 NetworkPolicy。 此新的 NetworkPolicy
必须拒绝 namespace testing 中的所有的 Ingress + Egress 流量。 将新创建的默认拒绝
NetworkPolicy 应用与在 namespace testing 中运行的所有 Pod。 你可以在 /cks/net/p1.yaml
找到一个模板清单文件。
16、日志审计 log audit
Task 在 cluster 中启用审计日志。为此，请启用日志后端，并确保：
⚫ 日志存储在
/var/log/kubernetes/audit-logs.txt
⚫ 日志文件能保留 10 天
⚫ 最多保留 2 个旧审计日志文件
/etc/kubernetes/logpolicy/sample-policy.yaml 提供了基本策略。它仅指定不记录的内容。
注意：基本策略位于 cluster 的 master 节点上。 编辑和扩展基本策略以记录：
⚫ RequestResponse 级别的
cronjobs 更改
⚫ namespace front-apps 中 deployment 更改的请求体
⚫ Metadata
级别的所有 namespace 中的 ConfigMap 和 Secret 的更改 此外，添加一个全方位的规则以在 Metadata
级别记录所有其他请求。 注意：不要忘记应用修改后的策略