云原生|kubernetes|2022年底cks真题解析（11-16）

前言

接上一篇文章云原生|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是一个工具合集netstattophtoplsof等等命令的功能它都可以实现考试系统是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

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