一、K8s安全基准条例

CIS(Center for Internet Security)，是一个专门制定针对于各种系统、各种知名软件的安全设置标准的组织。地址：https://www.cisecurity.org/

当我们登录注册完账号后，可以获取CIS针对于各个系统、软件设置的基准文档。我们也可以参考这个基准来完成对于K8s或者其他软件系统的评估。

例如我们下载后，查看其中的内容：

例如，1.1.8条例说明了我们需要确保etcd pod规范文件的所有权被设置为root:root，并且也给出了具体的设置方法。但是我们可以看到，整个文档有271页，如果我们手动的按照其中的规范进行检测，会特别繁琐。所以，在这里，可以在我们的K8s集群中安装kube-bench这个软件，kube-bench会依据CIA制定的规范，进行扫描，检测出哪些设置是符合或者不符合规范的，方便我们进行修复。

二、实验环境：

底层系统为ubuntu18.04，然后在每个node上安装k8s，并构建集群。Master node的IP地址为192.168.26.71/24，两个Worker node的IP地址为192.168.26.72/24、192.168.26.73/24。

Ubuntu如何搭建K8s集群，请参考：
https://www.jianshu.com/p/f2d4dd4d1fb1

在创建K8s网络时，可以使用calico完成：

curl https://docs.projectcalico.org/manifests/calico-etcd.yaml -o calico.yaml

接着在master上查看calico.yaml需要哪些镜像：

[root@vms71 ~]# grep image calico.yaml
          image: docker.io/calico/cni:v3.21.0
          image: docker.io/calico/pod2daemon-flexvol:v3.21.0
          image: docker.io/calico/node:v3.21.0
          image: docker.io/calico/kube-controllers:v3.21.0

然后再master上将所有所需镜像pull下来，并打包成tar文件拷贝到2个work nodes上，然后在三台设备上导入回镜像：

docker save calico/cni  calico/kube-controllers calico/node calico/pod2daemon-flexvol >  calico-3.21-img.tar

scp calico-3.21-img.tar vms72:~
scp calico-3.21-img.tar vms73:~

docker load -i calico-3.21-img.tar

在三台设备上使用docker images查看加载是否成功。然后在master修改calico.yaml文件，并安装：

vim calico.yaml

搜索192.168.0.0，修改为初始化集群时pod的10.244.0.0/24即可：

- name: CALICO_IPV4POOL_CIDR
  value: "10.244.0.0/16"

修改保存后在master设备上使用如下命令安装calico：

kubectl apply -f calico.yaml

三、使用Kube-bench检测系统安全

下载地址：https://github.com/aquasecurity/kube-bench/tags，可以选择自己所需要的版本，不同的版本检测的基于的CIS基准有所区别。

首先，我们现在目前最新的v0.6.5做检测，然后选择一个契合自己系统的包下载即可：

下载完成后导入到我们的master node上，然后使用如下命令进行安装：

sudo dpkg -i kube-bench_0.6.5_linux_amd64.deb

然后进入到/etc/kube-bench/cfg目录下，查看其中包含的基准信息：

root@vms71:/etc/kube-bench/cfg# ls
ack-1.0  aks-1.0  cis-1.20  cis-1.5  cis-1.6  config.yaml  eks-1.0  gke-1.0  rh-0.7  rh-1.0

例如我们查看cis-1.6版本的基准信息，不同的yaml文件定义了不同组件的检测基准信息：

root@vms71:/etc/kube-bench/cfg/cis-1.6# ls
config.yaml  controlplane.yaml  etcd.yaml  master.yaml  node.yaml  policies.yaml

返回上级目录，我们还可以看到config.yaml文件，其中定义了K8s各个组件需要检测的配置信息的名称与路径。接下来可以使用如下的命令来检测信息：

root@vms71:/etc/kube-bench# kube-bench --config-dir `pwd`/cfg --config `pwd`/cfg/config.yaml run --targets=master

注意–config-dir pwd/cfg指定了当前目录下的cfg文件的位置，–config指定了config.yaml文件的位置，–targets则是指定了我们需要检测的内容，可以是etcd、master、node（也就是worker）、controlplane、policies。例如，我们现在要检测master的信息，执行完上述命令后，在最后的summary处，可以看到最终的检测结果。

== Summary master ==
42 checks PASS
11 checks FAIL
11 checks WARN
0 checks INFO

== Summary total ==
42 checks PASS
11 checks FAIL
11 checks WARN
0 checks INFO

结果显示，有11个checks是FAIL，有42个checks是PASS。查看检查报告，标注为FAIL的则是检查失败的地方，可以看到，其中有一个检查失败的编号是1.2.20。

接着查看1.2.20对应的详细报告，可以确定问题出在哪个yaml文件中：

修改对应的yaml文件，按照要求添加值为false的–profiling参数：

修改保存后，重启kubectl，再重新检查：

systemctl restart kubelet

可以看到，1.2.20已经检查通过：

最后，需要注意的是，我们测试时使用的是0.6.5版本的kube-bench，需要去指定各种文件的位置。如果版本比较低的话，例如是0.3.5，则直接使用命令检查，不需要指定各种文件的位置：

kube-bench etcd/master/node/controlplane/policies

参考资料：
《老段CKS课程》