坐标2024年1月16号,看了一下cks的题目,上升难度了,bbq,难怪市面上很少人考这个,安全这方面我的工作涉及很多,继续考一下吧。环境就不放了,应该很少人考这个,真有人需要找我拿吧。
1.kube-bench 修复不安全项
Context
针对 kubeadm 创建的 cluster 运行 CIS 基准测试工具时,发现了多个必须立即解决的问题。OS:意思是下面这些是kube-bench工具检测出来的漏洞,需要你逐一进行修复;
Task
通过配置修复所有问题并重新启动受影响的组件以确保新的设置生效。
修复针对 API 服务器发现的所有以下违规行为:1.2.7 Ensure that the --authorization-mode argument is not set to AlwaysAllow FAIL
1.2.8 Ensure that the --authorization-mode argument includes Node FAIL
1.2.9 Ensure that the --authorization-mode argument includes RBAC FAIL
1.2.18 Ensure that the --insecure-bind-address argument is not set FAIL
(v1.28 考题中这项没给出,但最好也检查一下,模拟环境是里需要改的)
修复针对 kubelet 发现的所有以下违规行为:Fix all of the following violations that were found against the kubelet:
4.2.1 Ensure that the anonymous-auth argument is set to false FAIL
4.2.2 Ensure that the --authorization-mode argument is not set to AlwaysAllow FAIL
注意:尽可能使用 Webhook 身份验证/授权。
修复针对 etcd 发现的所有以下违规行为:
Fix all of the following violations that were found against etcd:2.2 Ensure that the --client-cert-auth argument is set to true FAIL
做题之前先来了解一下kube-bench,找到一篇文章,可以参考看一下,参考博客
简单解释一下,K8s本身有一些安全策略,如集群安全的TLS证书认证以及RBAC,还有其他的安全机制,参考博客里面都有谈到。但是对于市面上的漏洞是不足以应对的,要实现k8s之外的安全防控,还需要一些插件来支持。kube-bench就是其中一个插件。
kube-bench根据CIS(互联网安全中心)提供的安全防御解决方案,来逐一排查k8s集群的安全漏洞,主要检查一些不安全的参数配置,敏感文件的文件权限,不安全的账户以及公开的端口这些内容。
解答:
说明:我这个是买的模拟环境,我觉得省事,模拟环境需要模拟问题,所以要执行脚本使环境出现一些故障,来进行模拟修复,要注意考试的时候不用进行破坏脚本执行,并且本次练习题不打算强调环境切换,注意考试的时候自己要记得切换环境做题;
参考链接:kubelet配置
(1)切换环境执行破坏脚本
ssh master01
sodo -i
sh kube-bench.sh
可以用这个命令查危险项,只用改题目要求的:
kube-bench master
(2)修改api
cp /etc/kubernetes/manifests/kube-apiserver.yaml /tmp
vim /etc/kubernetes/manifests/kube-apiserver.yaml
修改如下:
修改 authorization-mode,注意 Node 和 RBAC 之间的符号是英文状态的逗号,而不是点。
--authorization-mode=Node,RBAC
删除 insecure-bind-address。实际考试中,有可能本来就没写这行。
--insecure-bind-address=0.0.0.0
(3)修改kubelet
可以用这个命令查:
kube-bench node
找kubelet的配置文件的位置:
systemctl status kubelet
cat /etc/systemd/system/kubelet.service.d/10-kubeadm.conf
找到Environment="KUBELET_CONFIG_ARGS=--config=/var/lib/kubelet/config.yaml":
备份一下文件再修改文件:
cp /var/lib/kubelet/config.yaml /tmp
vim /var/lib/kubelet/config.yaml
(4)修改etcd
可以用这个命令查:
kube-bench
cp /etc/kubernetes/manifests/etcd.yaml /tmp
vim /etc/kubernetes/manifests/etcd.yaml
修改--client-cert-auth=true
修改为 true
然后重新加载配置文件并重启kubelet
systemctl daemon-reload
systemctl restart kubelet.service
等一会,然后查看一下所有的pod看是否都在running:
kubectl get pod -A
最后退回node01上
年末了,老忙了,断断续续的
2.Pod 指定 ServiceAccount
Context
您组织的安全策略包括:
- ServiceAccount 不得自动挂载 API 凭据
- ServiceAccount 名称必须以“-sa”结尾
清单文件 /cks/sa/pod1.yaml 中指定的 Pod 由于 ServiceAccount 指定错误而无法调度。
请完成一下项目:
Task
- 在现有 namespace qa 中创建一个名为 backend-sa 的新 ServiceAccount,
确保此 ServiceAccount 不自动挂载 API 凭据。 - 使用 /cks/sa/pod1.yaml 中的清单文件来创建一个 Pod。
- 最后,清理 namespace qa 中任何未使用的 ServiceAccount。
在答题之前,先了解一下服务账号serviceaccount,参考链接:为pod配置服务账号。
- serviceaccount是pod中用来提供身份标识的,每个pod都可以与一个serviceaccount相关联,这样该pod就可以使用serviceaccount来与kubernetes
API进行交互,以便获取资源、执行操作或进行其他需要授权的任务; - serviceaccount允许pod在集群内部进行身份验证和授权,以便pod可以执行其所需要的操作,如访问其他服务、获取secrets等;
- 每个namespace至少包含一个serviceaccount,也就是说该namespace默认的服务账号default。当你创建pod时没有指定特定的serviceaccount,k8会将该namesapce中的服务账号default分配给该pod;
为pod分配适当的serviceaccount,可以限制pod的权限,从而提高集群的安全性。在pod中使用serviceaccount,kubernetes会自动为pod提供一个与serviceaccount相关的访问令牌,pod可以使用这个令牌来进行API的调用和其他需要授权的操作。
解答:
(1)创建ServiceAccount
复制官网的yaml文件进行修改:
vim qa-ns.yaml
修改如下:
apiVersion: v1
kind: ServiceAccount
metadata:
name: backend-sa # 修改name
namespace: qa # 添加namespace
automountServiceAccountToken: false # 修改为false,表示不自动挂载secret
然后apply一下
kubectl apply -f qa-ns.yaml
kubectl get sa -n qa
(2)创建pod使用该ServiceAccount
vim /cks/sa/pod1.yaml #考试的时候应该是直接修改已有的文件
修改如下:
apiVersion: v1
kind: Pod
metadata:
name: backend
namespace: qa #命名空间对上号
spec:
serviceAccountName: backend-sa #没有这行则添加,有就直接改
containers:
- image: nginx:1.9
imagePullPolicy: IfNotPresent
name: backend
然后apply一下:
kubectl apply -f /cks/sa/pod1.yaml
kubectl get pod -n qa
(3)删除没有使用的ServiceAccount
kubectl delete sa -n qa test01
查看已经在使用的sa:
kubectl get pod -n qa -o yaml | grep -i serviceaccount
篇幅太长了,,,下一篇(该死的检查终于过去了,又开始可以天天摸鱼了Date 01/23/2024
本页的评论功能已关闭