前言：
接上一篇文章：云原生|kubernetes|2022年底cks真题解析（1-10）_晚风_END的博客-CSDN博客
2022年底的csk真题第二部分 11题到16题
十一，
Trivy 扫描镜像安全漏洞
题目：
Task 使用 Trivy 开源容器扫描器检测 namespace kamino 中 Pod 使用的具有严重漏洞的镜像。 查找具有 High 或 Critical 严重性漏洞的镜像，并删除使用这些镜像的 Pod。 注意：Trivy 仅安装在 cluster 的 master 节点上， 在工作节点上不可使用。 你必须切换到 cluster 的 master 节点才能使用 Trivy。
解析：
这道题比较的简单，具体的trivy扫描工具的部署见我的博客：云原生|kubernetes|安全漏扫神器trivy的部署和使用_晚风_END的博客-CSDN博客_trivy
当然了，在考试环境，不存在无法升级trivy-db数据库的问题，可以放心使用。trivy扫描镜像漏洞还是比较快的，基本每个镜像十来秒就扫描完了
根据题目要求，关键点在于如何找到给定的namespace kamino内的pod所有的所使用的镜像名称，下面提供一个比较简单的方法：
kubectl get po --help 。。。。。。。。。前面的略略略。。。。。。。。。。 Usage: kubectl get [(-o|--output=)json|yaml|name|go-template|go-template-file|template|templatefile|jsonpath|jsonpath-as-json|jsonpath-file|custom-columns|custom-columns-file|wide] (TYPE[.VERSION][.GROUP] [NAME | -l label] | TYPE[.VERSION][.GROUP]/NAME ...) [flags] [options]
OK，我们选用custom-columns自定义字段来输出镜像名称（这里以kube-system这个namespace为例）：
kubectl get po -n kube-system --output=custom-columns="IMAGE:.spec.containers[*].image" IMAGE docker.io/calico/kube-controllers:v3.21.2 docker.io/calico/node:v3.21.2 docker.io/calico/node:v3.21.2 docker.io/calico/node:v3.21.2 registry.aliyuncs.com/google_containers/coredns:v1.8.4 registry.aliyuncs.com/google_containers/coredns:v1.8.4 registry.aliyuncs.com/google_containers/etcd:3.5.0-0 registry.aliyuncs.com/google_containers/kube-apiserver:v1.22.10 registry.aliyuncs.com/google_containers/kube-controller-manager:v1.22.10 registry.aliyuncs.com/google_containers/kube-proxy:v1.22.10 registry.aliyuncs.com/google_containers/kube-proxy:v1.22.10 registry.aliyuncs.com/google_containers/kube-proxy:v1.22.10 registry.aliyuncs.com/google_containers/kube-scheduler:v1.22.10 ccr.ccs.tencentyun.com/gcr-containers/metrics-server:v0.5.2
然后使用for循环检测：
a=`kubectl get po -n kube-system --output=custom-columns="IMAGE:.spec.containers[*].image"` for i in $a;do trivy image --skip-update -s 'HIGH,CRITICAL' $i;done
检测结果可以重定向到文件内，然后用搜索大法查看结果即可，有 High 或 Critical漏洞的pod删除掉即可。
解答：
1 切换到 Master 的 candidate 下 ssh master01
2 获取命名空间 kamino 下的所有 pod 的 image a=`kubectl get po -n kamino --output=custom-columns="IMAGE:.spec.containers[*].image"`
3, for 循环扫描 for i in $a;do trivy image --skip-update -s 'HIGH,CRITICAL' $i;done >11.txt
4， 人肉搜索上面的扫描结果，有符合漏洞的pod手动删除并确认结果即可
十二，
Container 安全上下文
题目：
Context Container Security Context 应在特定 namespace 中修改 Deployment。 Task 按照如下要求修改 sec-ns 命名空间里的 Deployment secdep 一、用 ID 为 30000 的用户启动容器（设置用户 ID 为: 30000） 二、不允许进程获得超出其父进程的特权（禁止 allowPrivilegeEscalation） 三、以只读方式加载容器的根文件系统（对根文件的只读权限）
解析：
这个题目是关于pod 的security context，配置的地方比较多，因此还是需要使用官方文档，以关键字 security context在官方文档内搜索即可。
解答：
按照题目要求，在线修改 kubectl -n sec-ns edit deployment secdep 在 template 字段下面的 spec 里面，添加或修改如下红字内容，并保存（考试中也是在 Deployment 下有两个 image 的） 请注意，考试先检查 spec 下面（非 containers 下面）是否有 securityContext: {}，如果有则可以直接修改即可。否则重复添加是不生效的。 template: metadata: creationTimestamp: null labels: app: secdep spec: containers: image: busybox:1.28 imagePullPolicy: IfNotPresent name: sec-ctx-demo-1 securityContext: allowPrivilegeEscalation: false readOnlyRootFilesystem: true resources: {} terminationMessagePath: /dev/termination-log 按照题目要求，在线修改 kubectl -n sec-ns edit deployment secdep 在 template 字段下面的 spec 里面，添加或修改如下红字内容，并保存（考试中也是在 Deployment 下有两个 image 的） 请注意，考试先检查 spec 下面（非 containers 下面）是否有 securityContext: {}，如果有则可以直接修改即可。否则重复添加是不生效的。 template: metadata: creationTimestamp: null labels: app: secdep spec: containers: image: busybox:1.28 imagePullPolicy: IfNotPresent name: sec-ctx-demo-1 securityContext: allowPrivilegeEscalation: false readOnlyRootFilesystem: true resources: {} terminationMessagePath: /dev/termination-log
十三，
日志审计 log audit
题目：
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 级别记录所有其他请求。 注意：不要忘记应用修改后的策略。
解析：
这道题需要配置的地方比较多，因此，还是需要官方文档查询的，关键字audit 审计 | Kubernetes
需要编辑/etc/kubernetes/logpolicy/sample-policy.yaml ，按题目要求修改，然后修改apiserver的配置文件，增加后端配置，最终在/var/log/kubernetes/audit-logs.txt这个文件中可以看到有输出表明此题完成。
解答：
本题分数比较多，占 12%。 日志审计这一题需要自己调整的内容还是挺多的，因此要非常仔细，建议修改前备份一下原始的环境，要不然修改错了就会导致集群崩溃。
配置审计策略 先备份配置文件 mkdir bak5 cp /etc/kubernetes/logpolicy/sample-policy.yaml bak5/ vim /etc/kubernetes/logpolicy/sample-policy.yaml 参考官方网址内容 注意这个文件里的最后一句英文，Please do not delete the above rule content, you can continue to add it below. 考试时，也有类似的一句话，大体是告诉你，不要删除上面的规则，你只可以在下面继续追加题目要求的规则。 …… rules: ###此处省略默认带有的一些规则，不要修改，而是继续添加如下规则。 # namespaces changes at RequestResponse level - level: RequestResponse resources: - group: "" resources: ["persistentvolumes"] #根据题目要求修改，比如题目要求的是 namespaces。 #the request body of persistentvolumes/pods changes in the namespace front-apps - level: Request resources: - group: "" resources: ["configmaps"] #根据题目要求修改，比如题目要求的是 persistentvolumes 或者 pods。 namespaces: ["front-apps"] # Log configmap and secret changes in all other namespaces at the Metadata level. - level: Metadata resources: - group: "" resources: ["secrets", "configmaps"] # Also, add a catch-all rule to log all other requests at the Metadata level. - level: Metadata omitStages: - "RequestReceived"
配置 master 节点的 kube-apiserver.yaml 先备份配置文件 mkdir bak5 cp /etc/kubernetes/manifests/kube-apiserver.yaml bak5/ vi /etc/kubernetes/manifests/kube-apiserver.yaml 添加以下参数：注意空格要对齐，不建议放到最后，建议按照下图的位置放这四条信息。 #定义审计策略 yaml 文件位置，通过 hostpath 挂载 - --audit-policy-file=/etc/kubernetes/logpolicy/sample-policy.yaml #主意检查，如果考试中已经存在了，则不要重复添加。 #定义审计日志位置，通过 hostpath 挂载 - --audit-log-path=/var/log/kubernetes/audit-logs.txt #主意检查，如果考试中已经存在了，则不要重复添加。 #定义保留旧审计日志文件的最大天数为 10 天 - --audit-log-maxage=10 #主意检查，如果考试中已经存在了，则不要重复添加。 #定义要保留的审计日志文件的最大数量为 2 个 - --audit-log-maxbackup=2 #主意检查，如果考试中已经存在了，则不要重复添加。 #在 kube-apiserver.yaml 文件的 volumeMounts 标签下增加 volumeMounts: #找到这个字段，添加下面内容 - mountPath: /etc/kubernetes/logpolicy/sample-policy.yaml #这里也可以写到目录/etc/kubernetes/logpolicy/ name: audit #注意，在 1.25 考试中，蓝色的内容已经默认有了，你只需要添加绿色字体的内容。可以通过红色字，在文件中定位。但模拟环境没有加， 需要你全部手动添加。这样是为了练习，万一考试中没有，你也会加。但是如果考试中已添加，你再添加一遍，则会报错，导致 api-server 启不起来。 readOnly: true #这个为 true - mountPath: /var/log/kubernetes/ name: audit-log #注意，在 1.25 考试中，蓝色的内容已经有了，你只需要添加绿色字体的内容。可以通过红色字，在文件中定位。但模拟环境没有加， 需要你全部手动添加。这样是为了练习，万一考试中没有，你也会加。 readOnly: false #这个为 false #在 kube-apiserver.yaml 文件的 volumes 标签下增加 volumes: #找到这个字段，添加下面内容 #注意，在 1.25 考试中，蓝色的内容已经有了，volumes 这段无需修改，但是为了以防万一，模拟环境中没有 加，需要你手动添加。这样是为了练习，万一考试中没有，你也会加。 - name: audit hostPath: path: /etc/kubernetes/logpolicy/sample-policy.yaml #这里如果写到目录/etc/kubernetes/logpolicy/，则下面的 type:应为 type: DirectoryOrCreate type: File - name: audit-log hostPath: path: /var/log/kubernetes/ type: DirectoryOrCreate
十四，
启用 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 ，以确保经过身份验证的授权的请求仍然被允许。
解析：
首先，这道题需要根据题目要求登陆到正确的master服务器上，也就是说要ssh一下，然后修改配置前还是需要备份一下文件。
讲道理，这道题目是比较简单的，基本怎么修改题目里已经讲的非常清楚了，kubelet的配置是有问题的，但我们不需要更改这些，如果kubelet有问题，使用/etc/kubernetes/admin.conf 这个config文件即可。
解答：
确保只有认证并且授权过的 REST 请求才被允许 编辑/etc/kubernetes/manifests/kube-apiserver.yaml，修改下面内容 - --authorization-mode=AlwaysAllow - --enable-admission-plugins=AlwaysAdmit vi /etc/kubernetes/manifests/kube-apiserver.yaml 修改为 - --authorization-mode=Node,RBAC #注意，只保留 Node,RBAC 这两个，中间是英文状态下的逗号。在 1.25 考试中，这一条可能默认已经有 了，但还是要检查确认一下。 - --enable-admission-plugins=NodeRestriction #在 1.25 考试中，这一个原先为 AlwaysAdmit，需要修改为 NodeRestriction。 重启 kubelet systemctl daemon-reload systemctl restart kubelet
删除题目要求的角色绑定 查 kubectl get clusterrolebinding system:anonymous 删 kubectl delete clusterrolebinding system:anonymous 再检查 kubectl get clusterrolebinding system:anonymous
十五，
TLS 安全配置
题目：
Task 通过 TLS 加强 kube-apiserver 安全配置，要求 1、kube-apiserver 除了 VersionTLS13 及以上的版本可以使用，其他版本都不允许使用。 2、密码套件（Cipher suite）为 TLS_AES_128_GCM_SHA256 通过 TLS 加强 ETCD 安全配置，要求 1、密码套件（Cipher suite）为 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
解析：
这道题不需要查询官方文档
首先，我们需要ssh登陆题目指定的服务器，看看apiserver的配置和etcd的配置，可以发现默认的集群是没有配置tls安全的
根据题目的描述，我们需要修改的文件是kube-apiserver.yaml和etcd.yaml 这两个文件，官方文档以关键字VersionTLS13查询即可
不使用官方文档的方法：
root@k8s-master:~# kubectl exec -n kube-system kube-apiserver-k8s-master -- kube-apiserver --help |grep tls --cert-dir string The directory where the TLS certs are located. If --tls-cert-file and --tls-private-key-file are provided, this flag will be ignored. (default "/var/run/kubernetes") --tls-cert-file string File containing the default x509 Certificate for HTTPS. (CA cert, if any, concatenated after server cert). If HTTPS serving is enabled, and --tls-cert-file and --tls-private-key-file are not provided, a self-signed certificate and key are generated for the public address and saved to the directory specified by --cert-dir. --tls-cipher-suites strings Comma-separated list of cipher suites for the server. If omitted, the default Go cipher suites will be used. --tls-min-version string Minimum TLS version supported. Possible values: VersionTLS10, VersionTLS11, VersionTLS12, VersionTLS13 --tls-private-key-file string File containing the default x509 private key matching --tls-cert-file. --tls-sni-cert-key namedCertKey A pair of x509 certificate and private key file paths, optionally suffixed with a list of domain patterns which are fully qualified domain names, possibly with prefixed wildcard segments. The domain patterns also allow IP addresses, but IPs should only be used if the apiserver has visibility to the IP address requested by a client. If no domain patterns are provided, the names of the certificate are extracted. Non-wildcard matches trump over wildcard matches, explicit domain patterns trump over extracted names. For multiple key/certificate pairs, use the --tls-sni-cert-key multiple times. Examples: "example.crt,example.key" or "foo.crt,foo.key:*.foo.com,foo.com". (default []) --service-account-key-file stringArray File containing PEM-encoded x509 RSA or ECDSA private or public keys, used to verify ServiceAccount tokens. The specified file can contain multiple keys, and the flag can be specified multiple times with different files. If unspecified, --tls-private-key-file is used. Must be specified when --service-account-signing-key is provided
kube-apiserver的帮助命令里有如何配置，只需要将题目要求的密码套件值填入即可。
解答：
修改 kube-apiserver 修改之前，备份一下配置文件。 mkdir bak15 cp /etc/kubernetes/manifests/kube-apiserver.yaml bak15/ vim /etc/kubernetes/manifests/kube-apiserver.yaml 添加或修改相关内容，并保存（先检查一下，如果考试环境里已经给你这两条了，则你只需要修改即可） - --tls-cipher-suites=TLS_AES_128_GCM_SHA256 - --tls-min-version=VersionTLS13
修改 etcd 修改之前，备份一下配置文件。 mkdir bak15 cp /etc/kubernetes/manifests/etcd.yaml bak15/ vim /etc/kubernetes/manifests/etcd.yaml 添加或修改相关内容，并保存 - --cipher-suites=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
修改完成后，需要等待 3 分钟，等集群应用策略后，再检查一下所有 pod，特别是 etcd 和 kube-apiserver 两个 pod，确保模拟环境是正常的。 kubectl get pod -A kubectl -n kube-system get pod
十六，
Sysdig & falco
题目：
Task： 使用运行时检测工具来检测 Pod tomcat123 单个容器中频发生成和执行的异常进程。 有两种工具可供使用： ⚫ sysdig ⚫ falco 注： 这些工具只预装在 cluster 的工作节点 node02 上，不在 master 节点。 使用工具至少分析 30 秒 ，使用过滤器检查生成和执行的进程，将事件写到 /opt/KSR00101/incidents/summary 文件中， 其中包含检测的事件， 格式如下： timestamp,uid/username,processName 保持工具的原始时间戳格式不变。 注： 确保事件文件存储在集群的工作节点上。 请注意，考试时，考题里已表明 sysdig 在工作节点上，所以你需要 ssh 到开头写的工作节点上。
解析：
sysdig是一个工具合集，netstat，top，htop，lsof等等命令的功能它都可以实现，考试系统是Ubuntu，在此系统下也是可以非常方便的安装sysdig
Ubuntu下安装sysdig的命令为：
apt-get install sysdig
sysdig的参数是比较多得，-M 30 就是持续扫描30秒的意思了。
根据题目要求，扫描后的输出要有一定的格式，格式查询可以如下命令：
sysdig -l | grep time sysdig -l | grep uid sysdig -l | grep proc
现在的考试应该是使用的containerd运行时，因此，需要先找出containerd的socket：
crictl info | grep sock
其次，扫描对象是容器，因此，需要找到容器的ID，命令如下：
crictl ps | grep tomcat123
得到以上信息后就进行扫描工作了：
sysdig -M 30 -p "%evt.time,%user.name,%proc.name" --cri /run/containerd/containerd.sock container.name=tomcat123 >> /opt/KSR00101/incidents/summary
最后的结果大概是这样的形式：
