— 自动化运维 Leaning—
cks
cluster 上设置了容器镜像扫描器，但尚未完全集成到 cluster 的配置中。
完成后，容器镜像扫描器应扫描并拒绝易受攻击的镜像的使用。
注意：你必须在 cluster 的 master 节点上完成整个考题，所有服务和文件都已被准备好并放置在该节点上。
给定一个目录 /etc/kubernetes/epconfig 中不完整的配置，
以及具有 HTTPS 端点 https://image-bouncer-webhook.default.svc:1323/image_policy 的功能性容器镜像扫描器：
最后，通过尝试部署易受攻击的资源 /cks/img/web1.yaml 来测试配置是否有效。
通过TLS加强kube-apiserver安全配置，要求
通过TLS加强ETCD安全配置，要求
由 kubeadm 创建的 cluster 的 Kubernetes API 服务器，出于测试目的，
临时配置允许未经身份验证和未经授权的访问，授予匿名用户 cluster-admin 的访问权限.
重新配置 cluster 的 Kubernetes APl 服务器，以确保只允许经过身份验证和授权的 REST 请求。
使用授权模式 Node , RBAC 和准入控制器 NodeRestriction 。
删除用户 system:anonymous 的 ClusterRoleBinding 来进行清理。
注意：所有 kubectl 配置环境/文件也被配置使用未经身份验证和未经授权的访问。
你不必更改它，但请注意，一旦完成 cluster 的安全加固， kubectl 的配置将无法工作。
您可以使用位于 cluster 的 master 节点上，cluster 原本的 kubectl 配置文件
/etc/kubernetes/admin.conf ，以确保经过身份验证的授权的请求仍然被允许。
模拟环境里，初始化这道题的脚本为b.sh
Container Security Context应在特定namespace中修改Deployment。
按照如下要求修改 sec-ns 命名空间里的 Deployment secdep
Task：
使用运行时检测工具来检测 Pod tomcat123 单个容器中频发生成和执行的异常进程。
有两种工具可供使用：
注： 这些工具只预装在 cluster 的工作节点 node02 上，不在 master 节点。
使用工具至少分析 30 秒 ，使用过滤器检查生成和执行的进程，将事件写到 /opt/KSR00101/incidents/summary 文件中，
其中包含检测的事件， 格式如下：
timestamp , uid/username , processName
保持工具的原始时间戳格式不变。
注： 确保事件文件存储在集群的工作节点上。
请注意，考试时，考题里已表明sysdig在工作节点上，所以你需要ssh到开头写的工作节点上。但在模拟环境，你需要ssh到node02这个工作节点。
APPArmor 已在 cluster 的工作节点node02上被启用。一个 APPArmor 配置文件已存在，但尚未被实施。
在 cluster 的工作节点node02上，实施位于 /etc/apparmor.d/nginx_apparmor 的现有APPArmor 配置文件。
编辑位于 /cks/KSSH00401/nginx-deploy.yaml 的现有清单文件以应用 AppArmor 配置文件。
最后，应用清单文件并创建其中指定的 Pod 。
请注意，考试时，考题里已表明APPArmor在工作节点上，所以你需要ssh到开头写的工作节点上。
在模拟环境，你需要ssh到node02这个工作节点。
使用 Trivy 开源容器扫描器检测 namespace kamino 中 具有严重漏洞的镜像 的 Pod。
查找具有 High 或 Critical 严重性漏洞的镜像，并删除使用这些镜像的 Pod 。
注意：Trivy 仅安装在 cluster 的 master 节点上，
在工作节点上不可使用。
你必须切换到 cluster 的 master 节点才能使用 Trivy
创建一个名为 pod-restriction 的 NetworkPolicy 来限制对在 namespace dev-team 中运行的 Pod products-service 的访问。
只允许以下 Pod 连接到 Pod products-service
你可以在 /cks/net/po.yaml 找到一个模板清单文件。
分析和编辑给定的Dockerfile /cks/docker/Dockerfile（基于ubuntu:16.04 镜像），
并修复在文件中拥有的突出的安全/最佳实践问题的两个指令。
分析和编辑给定的清单文件 /cks/docker/deployment.yaml ，
并修复在文件中拥有突出的安全/最佳实践问题的两个字段。
注意：请勿添加或删除配置设置；只需修改现有的配置设置让以上两个配置设置都不再有安全/最佳实践问题。
注意：如果您需要非特权用户来执行任何项目，请使用用户ID 65535 的用户 nobody 。
只修改即可，不需要创建。
在 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
