Hao DevSecOps

ContextContainer Security Context应在特定namespace中修改Deployment。 Task按照如下要求修改 sec-ns 命名空间里的 Deployment secdep 用ID为 30000 的用户启动容器（设置用户ID为: 30000） 不允许进程获得超出其父进程的特权（禁止allowPrivilegeEscalation） 以只读方式加载容器的根文件系统（对根文件的只读权限） 参考https://kubernetes.io/zh-cn/docs/tasks/configure-pod-container/security-context/ 解答w切换集群 kubectl config use-context KSMV00102 修改 deployment secdep kubectl -n sec-ns edit deployment secdep 在template字段下面的spec里面，添加或修改如下红字内容，并保存（考试中也是在Deployment下有两个image的） 请注意，考试和模拟环境中，先检查s...

Task： 使用运行时检测工具来检测 Pod tomcat123 单个容器中频发生成和执行的异常进程。 有两种工具可供使用： sysdig falco 注： 这些工具只预装在 cluster 的工作节点 node02 上，不在 master 节点。 使用工具至少分析 30 秒 ，使用过滤器检查生成和执行的进程，将事件写到 /opt/KSR00101/incidents/summary 文件中， 其中包含检测的事件， 格式如下： timestamp , uid/username , processName 保持工具的原始时间戳格式不变。 注： 确保事件文件存储在集群的工作节点上。 请注意，考试时，考题里已表明sysdig在工作节点上，所以你需要ssh到开头写的工作节点上。但在模拟环境，你需要ssh到node02这个工作节点。 解答切换集群 kubectl config use-context KSSC00401 切换到 node02 节点 使用root ssh node02sudo -i 找到containerd的socket crictl info...

ContextAPPArmor 已在 cluster 的工作节点node02上被启用。一个 APPArmor 配置文件已存在，但尚未被实施。 Task在 cluster 的工作节点node02上，实施位于 /etc/apparmor.d/nginx_apparmor 的现有APPArmor 配置文件。 编辑位于 /cks/KSSH00401/nginx-deploy.yaml 的现有清单文件以应用 AppArmor 配置文件。 最后，应用清单文件并创建其中指定的 Pod 。 请注意，考试时，考题里已表明APPArmor在工作节点上，所以你需要ssh到开头写的工作节点上。 在模拟环境，你需要ssh到node02这个工作节点。 参考https://kubernetes.io/zh/docs/tutorials/security/apparmor/#example 解答切换集群 kubectl config use-context KSSH00401 连接到 node02 并切换到 root ssh node02sudo -i 切换到 apparmor 目录, 并检查...

Task使用 Trivy 开源容器扫描器检测 namespace kamino 中 具有严重漏洞的镜像 的 Pod。 查找具有 High 或 Critical 严重性漏洞的镜像，并删除使用这些镜像的 Pod 。 注意：Trivy 仅安装在 cluster 的 master 节点上， 在工作节点上不可使用。 你必须切换到 cluster 的 master 节点才能使用 Trivy 参考资料https://kubernetes.io/zh-cn/docs/reference/kubectl/cheatsheet/#格式化输出 解答 切换集群 kubectl config use-context KSSC00401 查看namespace下pod 和image kubectl get pods -n kamino -o=custom-columns="NAME:.metadata.name,IMAGE:.spec.containers[*].image" 提取镜像名并进行扫描 kubectl describe pod -n kamino | g...

Task创建一个名为 pod-restriction 的 NetworkPolicy 来限制对在 namespace dev-team 中运行的 Pod products-service 的访问。 只允许以下 Pod 连接到 Pod products-service namespace qaqa 中的 Pod 位于任何 namespace，带有标签 environment: testing 的 Pod 注意：确保应用 NetworkPolicy。 你可以在 /cks/net/po.yaml 找到一个模板清单文件。 参考https://kubernetes.io/zh/docs/concepts/services-networking/network-policies/#networkpolicy-resource 解答切换集群 kubectl config use-context KSSH00301 检查namespace标签 模拟环境已提前打好标签了，所以你只需要检查标签即可。但为了防止考试时，没有给你打标签，所以还是需要你将下面打标签的命令记住。 # 查看 q...

Context该 cluster 使用 containerd 作为 CRI 运行时。containerd 的默认运行时处理程序是 runc 。 containerd 已准备好支持额外的运行时处理程序 runsc (gVisor)。 Task使用名为 runsc 的现有运行时处理程序，创建一个名为 untrusted 的 RuntimeClass。 更新 namespace server 中的所有 Pod 以在 gVisor 上运行。 您可以在 /cks/gVisor/rc.yaml 中找到一个模版清单。 参考https://kubernetes.io/zh-cn/docs/concepts/containers/runtime-class/#2-创建相应的-runtimeclass-资源 解答切换集群 kubectl config use-context KSMV00301 创建RuntimeClass vim /cks/gVisor/rc.yaml rc.yaml apiVersion: node.k8s.io/v1 ##将apiVersion: node.k...

Task分析和编辑给定的Dockerfile /cks/docker/Dockerfile（基于ubuntu:16.04 镜像）， 并修复在文件中拥有的突出的安全/最佳实践问题的 两个指令。 分析和编辑给定的清单文件 /cks/docker/deployment.yaml ， 并修复在文件中拥有突出的安全/最佳实践问题的 两个字段。 注意：请勿添加或删除配置设置；只需修改现有的配置设置让以上两个配置设置都不再有安全/最佳实践问题。 注意：如果您需要非特权用户来执行任何项目，请使用用户ID 65535 的用户 nobody 。 只修改即可，不需要创建。 参考https://kubernetes.io/zh/docs/concepts/security/pod-security-standards/#restricted 解答切换集群 kubectl config use-context KSSC00301 修改Dockerfile vim /cks/docker/Dockerfile #修改基础镜像为题目要求的 ubuntu:16.04FRO...

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-instancepassword : KvLftKgs4aVH 最后，创建一个新的 Pod ，它可以通过卷访问 secret db2-test ： Pod 名称 secret-pod Namespace istio-system 容器名 dev-container 镜像 nginx 卷名 secret-volume 挂载路径 /etc/secret 参考https://kubernetes.io...

Task在cluster中启用审计日志。为此，请启用日志后端，并确保： 日志存储在 /var/log/kubernetes/audit-logs.txt 日志文件能保留 10 天 最多保留 2 个旧审计日志文件 /etc/kubernetes/logpolicy/sample-policy.yaml 提供了基本策略。它仅指定不记录的内容。 注意：基本策略位于 cluster 的 master 节点上。 编辑和扩展基本策略以记录： RequestResponse 级别的 persistentvolumes 更改 namespace front-apps 中 configmaps 更改的请求体 Metadata 级别的所有 namespace 中的 ConfigMap 和 Secret 的更改 此外，添加一个全方位的规则以在 Metadata 级别记录所有其他请求。 注意：不要忘记应用修改后的策略。 参考https://kubernetes.io/zh/docs/tasks/debug/debug-cluster/audit/ 解答 日志审计这一题需要自己调整的内...

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。 参考https://kubernetes.io/zh/docs/reference/access-authn-authz/rbac/#role-and-clusterole https://kubernetes.io/zh-cn/docs/ref...