Eryoung2的个人博客

任务注意：你必须在 cluster 的 master节点上完成整个考题，所有服务和文件都已被准备好并放置在该节点上。给定一个目录 /etc/kubernetes/epconfig中不完整的配置以及具有 HTTPS 端点 https://acme.local:8082/image_policy 的功能性容器镜像扫描器： 1. 启用必要的插件来创建镜像策略 2. 校验控制配置并将其更改为隐式拒绝（implicit deny） 3. 编辑配置以正确指向提供的 HTTPS 端点最后，通过尝试部署易受攻击的资源 /cks/img/web1.yaml 来测试配置是否有效。你可以在/var/log/imagepolicy/roadrunner.log 找到容器镜像扫描仪的日志文件。 解题 修改/etc/kubernetes/epconfig/admission_configuration.json，将defaultAllow设置为false 1 ...

任务重新配置 cluster 的Kubernetes APl 服务器，以确保只允许经过身份验证和授权的 REST 请求。使用授权模式 Node,RBAC 和准入控制器NodeRestriction。删除用户 system:anonymous 的 ClusterRoleBinding 来进行清理。 注意：所有 kubectl 配置环境/文件也被配置使用未经身份验证和未经授权的访问。 你不必更改它，但请注意，一旦完成 cluster的安全加固， kubectl 的配置将无法工作。 您可以使用位于 cluster 的 master 节点上，cluster 原本的kubectl 配置文件 /etc/kubernetes/admin.conf ，以确保经过身份验证的授权的请求仍然被允许。 解题 备份并修改kube-apiserver配置123# 备份mkdir -p /opt/backup/15cp -f /etc/kubernetes/manifests/kube-apiserver.yaml /opt/backup/15 12- --authoriz ...

任务通过TLS加强kube-apiserver安全配置，要求1、kube-apiserver除了VersionTLS13及以上的版本可以使用，其他版本都不允许使用。2、密码套件（Cipher suite）为TLS_AES_128_GCM_SHA256 通过TLS加强ETCD安全配置，要求1、密码套件（Cipher suite）为TLS_AES_128_GCM_SHA256 做题 备份相关配置文件 123mkdir -p /opt/backup/14cp -f /etc/kubernetes/manifests/kube-apiserver.yaml /opt/backup/14cp -f /etc/kubernetes/manifests/etcd.yaml /opt/backup/14 修改配置文件 1234567# kube-apiserver.yamlspec: containers: - command: - kube-apiserver - --tls-min-version=VersionTLS13 #任务1 - --tls-cipher-suite ...

任务按照如下要求修改sec-ns命名空间里的Deployment secdep1、用ID为30000的用户启动容器（设置用户1D为：30000）2、不允许进程获得超出其父进程的特权（禁止allowPrivilegeEscalation）3、以只读方式加载容器的根文件系统（对根文件的只读权限） 解题 修改deployment secdep，添加配置kubectl edit deploy secdep -n sec-ns 12345678910111213spec: securityContext: #增加这两行完成任务1 runAsUser: 30000 ... containers: securityContext: #增加这三行完成任务2，3 allowPrivilegeEscalation: false readOnlyRootFilesystem: true ... containers: ...

任务使用运行时检测工具来检测 Pod tomcat123 单个容器中频发生成和执行的异常进程。 有两种工具可供使用： sysdig falco注： 这些工具只预装在 cluster 的工作节点node02，不在 master 节点。 使用工具至少分析 30 秒，使用过滤器检查生成和执行的进程，将事件写到 /opt/KSR00101/incidents/summary 文 件中，其中包含检测的事件， 格式如下： [timestamp],[uid],[processName] 保持工具的原始时间戳格式不变。注：确保事件文件存储在集群的工作节点上。 做题 找到containerd的sock 12crictl info | grep sock"containerdEndpoint": "/run/containerd/containerd.sock", 找到目标container 1crictl ps|grep tomcat123 通过sysdig扫描容器并输出 1234sysdig -l | grep ...

任务在 cluster 的工作节点上，实施位于 /etc/apparmor.d/nginx_apparmor 的现有 APPArmor配置文件。编辑位于 /home/candidate/KSSH00401/nginx-deploy.yaml 的现有清单文件以应用AppArmor 配置文件。 最后，应用清单文件并创建其中指定的 Pod 。 做题 在集群所有节点上加载apparmor策略，并检查 12apparmor_parser /etc/apparmor.d/nginx_apparmorapparmor_status|grep nginx-profile 回到主节点，编辑清单文件，添加配置vim /home/candidate/KSSH00401/nginx-deploy.yaml 12345678910111213141516apiVersion: v1kind: Podmetadata: name: nginx-deploy annotations: # 从官 ...

任务使用 Trivy 开源容器扫描器检测 namespace kamino 中 具有严重漏洞的镜像 的 Pod。查找具有 High 或 Critical 严重性漏洞的镜像，并删除使用这些镜像的 Pod 。注意：Trivy 仅安装在 cluster 的 master 节点上， 在工作节点上不可使用。 你必须切换到 cluster 的 master 节点才能使用 Trivy 解题 登录到相应的master节点，查看kamino namespace下的pod 12ssh xxx-masterkubectl get pod -n kamino -oyaml|grep "image:" 使用Trivy工具挨个扫描，观察是否有HIGH或者CRITICAL（过程有点久，可以在扫描的时候新开一个terminal做其他题目，扫描完毕之后再看） 1trivy image -s "HIGH,CRITICAL" xxx|grep -i "Total" 删除有HIGH或者CRITICAL漏洞的pod 1kubectl delete pod xxx ...

任务创建一个名为 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 找到一个模板清单文件。 做题 检查相关namespace的标签， 没有就打一个 123456# 查标签kubectl get ns products-service --show-labelskubectl get ns qaqa --show-labels# 打标签kubectl label ns xxx name=xxx 编辑网络策略的yaml文件vim cks-09.yaml 123456789101112131415161718192021apiVersion ...

任务使用名为runsc的现有运行时处理程序，创建一个名为untrusted的RuntimeClass。更新namespace server中的所有Pod以在gVisor上运行。您可以在/cks/gVisor/rc.yaml中找到一个模版清单。 解题 创建名为untrusted的RuntimeClass vim cks-08.yaml 12345 apiVersion: node.k8s.io/v1kind: RuntimeClassmetadata: name: untrustedhandler: runsc kubectl apply -f cks-08.yaml 更新namespace server下的所有pod，使其在gVisor下运行 123kubectl get pods -n serverkubectl edit pod xxx# 在spec下添加runtimeClassName: untrusted, 此runtimeClassName与container同级 参考 https://kubernetes.io/zh-cn/docs/c ...

任务分析和编辑给定的Dockerfile /cks/docker/Dockerfile（基于ubuntu:16.04 镜像）， 并修复在文件中拥有的突出的安全/最佳实践问题的两个指令。分析和编辑给定的清单文件 /cks/docker/deployment.yaml ， 并修复在文件中拥有突出的安全/最佳实践问题的两个字段。注意：请勿添加或删除配置设置；只需修改现有的配置设置让以上两个配置设置都不再有安全/最佳实践问题。注意：如果您需要非特权用户来执行任何项目，请使用用户ID 65535 的用户 nobody 。只修改即可，不需要创建。 解题 修改Dockerfile 12345#修改基础镜像为题目要求的 ubuntu:16.04FROM ubuntu:16.04#仅将CMD上面的USER root修改为USER nobody，不要改其他的USER root。USER nobody 修改Deployment文件vim /cks/docker/deployment.ya ...