cks-1.32考题

1、修复 kubelet 和 etcd 不安全问题

你必须连接到正确的主机，不这样做可能会导致零分。

[candidate@base] $ ssh cks001091

Context

针对 kubeadm 创建的 cluster 运行 CIS 基准测试工具时，发现了多个必须立即解决的问题。

Task

通过配置修复所有问题并重新启动受影响的组件以确保新的设置生效。

修复针对 kubelet 发现的所有以下违规行为：

1.1.1 确保将 anonymous-auth 参数设置为 false FAIL

1.1.2 确保 --authorization-mode 参数未设置为 AlwaysAllow FAIL

注意：尽可能使用 Webhook 身份验证/授权。

修复针对 etcd 发现的所有以下违规行为：

2.1.1 确保 --client-cert-auth 参数设置为 true FAIL

2、TLS Secret

你必须连接到正确的主机。不这样做可能导致零分

[candidate@base] $ ssh cks000040

Context

您必须使用存储在 TLS Secret 中的 SSL 文件，来保护 Web 服务器的安全访问。

Task

在 clever-cactus namespace 中为名为 clever-cactus 的现有 Deployment 创建名为 clever-cactus 的 TLS Secret 。

使用以下 SSL 文件：

证书 ~/ca-cert/web.k8s.local.crt

密钥 ~/ca-cert/web.k8s.local.key

Deployment 已配置为使用 TLS Secret。

请勿修改现有的 Deployment。

3、Dockerfile 安全最佳实践

你必须连接到正确的主机。不这样做可能导致零分。

[candidate@base] $ ssh cks001094

Task

分析和编辑给定的 Dockerfile /cks/docker/Dockerfile

并修复在文件中拥有的突出的安全/最佳实践问题的一个指令。

分析和编辑给定的清单文件 /cks/docker/deployment.yaml ，

并修复在文件中拥有突出的安全/最佳实践问题的一个字段。

注意：请勿添加或删除配置设置；只需修改现有的配置设置让以上两个配置设置都不再有安全/最佳实践问题。

注意：如果您需要非特权用户来执行任何项目，请使用用户 ID 65535 的用户 nobody 。

4、访问/dev/mem 的 Pod

你必须连接到正确的主机。不这样做可能导致零分。

[candidate@base] $ ssh cks000026

Context

Pod 行为不当，对系统构成安全威胁。

Task

属于应用程序 ollama 的一个 Pod 出现异常。它正从敏感文件/dev/mem 直接访问系统的内存读取数据。

首先，识别访问/dev/mem 行为不当的 Pod。

接下来，将行为不当 Pod 的 Deployment 缩放为零副本。

注意：

除缩小副本外，不要修改 Deployment 其他内容。

不要修改任何其他 Deployment。

不要删除任何 Deployment。

5、安全上下文 Container Security Context

你必须连接到正确的主机。不这样做可能导致零分。

[candidate@base] $ ssh cks001097

Context

您必须更新一个现有的 Pod，以确保其容器的不变性。

Task

修改 sec-ns namespace 里的名为 secdep 的 Deployment，以便其容器：

​ 使用用户 ID 30000 运行

​ 使用只读根文件系统

​ 禁止特权提升

您可以在 ~/sec-ns_deployment.yaml 找到 Deployment 的清单文件。

6、日志审计 log audit

你必须连接到正确的主机。不这样做可能导致零分。

[candidate@base] $ ssh cks001098

Context

您必须为 kubeadm 配置的集群实施审计。

Task

首先，重新配置集群的 PAI 服务器，以便：

位于 /etc/kubernetes/logpolicy/sample-policy.yaml 的基本审计策略被使用

​ 日志存储在 /var/log/kubernetes/audit-logs.txt

​ 最多保留 2 个日志，保留时间为 10 天

注意：基本策略仅指定不记录的内容。

然后，编辑并扩展基本策略以记录：

​ RequestResponse 级别的 persistentvolumes 事件

​ front-apps namespace 中的 configmaps 事件的请求正文

​ Metadata 级别的所有 namespace 中的 ConfigMap 和 Secret 的更改

​ Metadata 级别记录所有其他请求

注意：确保 API 服务器使用扩展后的策略。

7、网络策略 Deny 和 Allow

你必须连接到正确的主机。不这样做可能导致零分。

[candidate@base] $ ssh cks000031

Context

您必须实施 NetworkPolicy 来控制现有的 Deployments 跨 namespace 的流量。

Taks

首先，为了阻止所有入口流量，在 prod namespace 中创建一个名为 deny-policy 的 NetworkPolicy。

PS: prod namespace 被标记为 env: prod

然后，为了仅允许来自 prod namespace 中 Pod 的入口流量，在 data namespace 中创建一个名为 allow-from-prod 的 NetworkPolicy。

使用 prod namespace 的标签来允许流量。

PS: data namespace 被标记为 env: data

注意：请勿修改或删除任何 namespace 或 Pod。仅创建必须得 NetworkPolicy。

8、使用 ingress 公开 https 服务

你必须连接到正确的主机。不这样做可能导致零分。

[candidate@base] $ ssh cks000032

Context

您必须使用 HTTPS 路由来公开 web 应用程序。

Task

在 prod02 namespace 创建一个名为 web 的 Ingress 资源，并按照如下方式配置它：

​ 将主机 web.k8sng.local 和所有路径的流量路由到现有的 web Service。

​ 使用现有的 web-cert Secret 来启用 TLS 终止。

​ 将 HTTP 请求重定向到 HTTPS

PS: 你可以使用以下命令测试 Ingress 配置：

[candidate@cks000032] $ curl -Lk https://web.k8sng.local

9、关闭 API 凭据自动挂载

你必须连接到正确的主机。不这样做可能导致零分。

[candidate@base] $ ssh cks000033

Context

安全审计发现某个 Deployment 有不合规的服务账号令牌，这可能导致安全漏洞。

Task

首先，修改 monitoring namespace 中现有的 stats-monitor-sa ServiceAccount，以关闭 API 凭据自动挂载。

然后，修改 monitoring namespace 中现有的 stats-monitor Deployment，

以注入装载在/var/run/secrets/kubernetes.io/serviceaccount/token 的 ServiceAccount 令牌。

使用名为 token 的投射卷，来注入 ServiceAccount 令牌，并确保它以只读方式挂载。

PS: 部署的清单配置文件可以在以下位置找到：

~/stats-monitor/deployment.yaml

10、升级集群节点

你必须连接到正确的主机。不这样做可能导致零分。

[candidate@base] $ ssh cks000034

Context

kubeadm 配置的集群最近进行了升级，由于工作负载兼容性问题，将一个节点保留在稍旧的版本上。

Task

升级集群节点 node02 以匹配 control plane 节点的版本。

使用如下所示命令连接到此计算节点：

[candidate@cks000034] ssh node02

PS: 不要修改集群中的任何正在运行的工作负责。

11、bom 工具生成 SPDX 文档

你必须连接到正确的主机。不这样做可能导致零分。

[candidate@base] $ ssh cks000035

Task

在 alpine namespace 中的 alpine Deployment，有三个运行不同版本的 alpine 镜像的容器。

首先，找出 alpine 镜像的哪个版本包含版本为 3.1.4-r5 的 libcrypto3 软件包。

其次，使用预安装的 bom 工具，在 ~/alpine.spdx 为找出的镜像版本创建一个 SPDX 文档。

最后，更新 alpine Deployment 并删除 使用找出的镜像版本的容器。

Deployment 的清单文件可以在~/alipine-deployment.yaml 中找到。

PS: 请勿修改 Deployment 的任何其他容器。

12、限制性 Pod 安全标准

你必须连接到正确的主机。不这样做可能导致零分。

[candidate@base] $ ssh cks000036

Context

为了符合要求，所有用户命名空间都强制执行受限的 Pod 安全标准。

Task

在 confidential namespace 中包含一个不符合限制性的 Pod 安全标准的 Deployment。因此，其 Pod 无法被调度。

修改这个 Deployment 以符合标准，并验证 Pod 可以正常运行。PS: 部署的清单文件可以在 ~/nginx-unprivileged.yaml 找到。

13、Docker 守护进程

你必须连接到正确的主机。不这样做可能导致零分。

[candidate@base] $ ssh cks000037

Task

执行以下任务，以保护集群节点 cks000037

从 docker 组中删除用户 developer

PS: 不要从任何其他组中删除用户

重新配置并重启 Docker 守护程序，以确保位于/var/run/docker.sock 的套接字文件由 root 组拥有。

重新配置并重启 Docker 守护进程，以确保它不监听任何 TCP 端口。

PS: 完成工作后，确保 Kubernetes 集群保持健康状态。

14、Cilium 网络策略

你必须连接到正确的主机。不这样做可能导致零分。

[candidate@base] $ ssh cks000039

Context

这道题，您参考网址：

CiliumNetworkPolicy

Task

使用 Cilium 执行以下任务，以保护现有应用程序的内部和外部网络流量。

PS: 您可以使用浏览器访问 Cilium 的文档。

首先，在 nodebb namespace 里创建一个名为 nodebb 的 L4 CiliumNetworkPolicy，并按照如下方式配置它：

​ 允许 ingress-nginx namespace 中运行的所有 Pod 访问 nodebb Deployment 的 Pod

​ 要求相互身份验证

然后，将前一步创建的网络策略扩展如下：

​ 允许主机访问 nodebb Deployment 的 Pod

​ 不要使用相互身份验证

15、容器镜像策略 ImagePolicyWebhook

你必须连接到正确的主机。不这样做可能导致零分。

[candidate@base] $ ssh cks001094

Context

您必须将容器镜像扫描完全集成到 kubeadm 配置的集群中。

Task

假设位于 /etc/kubernetes/epconfig 中的不完整的配置，

以及具有 HTTPS 端点 https://image-bouncer-webhook.default.svc:1323/image_policy 的功能性容器镜像扫描器，

请执行以下任务，来实现验证（Validating）准入控制器。

首先，重新配置 API 服务器，以启用所有准入插件，以支持提供的 AdmissionConfiguration

其次，重新配置 ImagePolicyWebhook 以在后端失效时拒绝镜像。

最后，为了测试配置，部署在 ~/web1.yaml 中定义的测试资源，该资源使用应被拒绝的镜像。

您可以根据需要删除和重新创建这个资源。

16、启用 API server 身份验证

你必须连接到正确的主机。不这样做可能导致零分。

[candidate@base] $ ssh cks001092

Context

出于测试目的，由 kubeadm 创建的 cluster 的 Kubernetes API 服务器临时配置为，允许未经身份验证和未经授权的访问。

Task

首先，按照以下方式配置集群的 API 服务器，以确保其安全：

​ 禁止匿名身份验证

​ 使用授权模式 Node,RBAC

​ 使用准入控制器 NodeRestriction

注意：所有 kubectl 配置环境/文件也被配置使用未经身份验证和未经授权的访问。

你不必更改它，但请注意，一旦完成集群的安全加固， kubectl 的配置将无法工作。

您可以使用集群位于 /etc/kubernetes/admin.conf 的原始 kubectl 配置文件来访问受保护的集群。

然后，请删除 ClusterRoleBinding system:anonymous 来进行清理。