前言：

接上一篇文章：云原生|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查询即可

 kube-apiserver | Kubernetes

 解答：

修改 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

最后的结果大概是这样的形式：