CIS Benchmark简介
CIS Benchmark建议使用配置来强化各种组件，包括Docker，Kubernetes，Linux等。这些建议通常是配置选项，可以通过参数在二进制程序或在配置文件中进行指定。基准测试还提供命令来审核安装，确定提高安全性的地方以及纠正这些问题的步骤。
测试及配置文件
一个典型的基准检测审查在控制项文件中指定的项目，这些CIS Benchmark检查项目是YAML格式来表示。控制项每个版本和节点类型都有一个专门的文件来作为审核项目。
控制项基准检测的各种版本可以在同一个CIS版本目录下（cfg/）找到，例如cfg/cis-1.4.0。
Controls控制项
控制项是一个YAML文档，其中包含基准检测的定义。
控制项是基准检测项目的基础来源，以下是CIS基准检测示例controls：
---
controls:
id: 1
text: "Master Node Security Configuration"
type: "master"
groups:
- id: 1.1
text: API Server
checks:
- id: 1.1.1
text: "Ensure that the --allow-privileged argument is set (Scored)"
audit: "ps -ef | grep kube-apiserver | grep -v grep"
tests:
bin_op: or
test_items:
- flag: "--allow-privileged"
set: true
- flag: "--some-other-flag"
set: false
remediation: "Edit the /etc/kubernetes/config file on the master node and
set the KUBE_ALLOW_PRIV parameter to '--allow-privileged=false'"
scored: true
- id: 1.2
text: Scheduler
checks:
- id: 1.2.1
text: "Ensure that the --profiling argument is set to false (Scored)"
audit: "ps -ef | grep kube-scheduler | grep -v grep"
tests:
bin_op: or
test_items:
- flag: "--profiling"
set: true
- flag: "--some-other-flag"
set: false
remediation: "Edit the /etc/kubernetes/config file on the master node and
set the KUBE_ALLOW_PRIV parameter to '--allow-privileged=false'"
scored: true
控制项由组，子组和检查的层次结构组成，每个控制项组件都有一个ID和一个文本描述，它们显示在基准检测输出中。
type指定控制项检测是为哪个节点检测的。
Group组
groups由一些子组构成，这些子组在节点中测试了在controls中定义的大量组件。
这些子组有id，text等字段构成，这些字段跟前文所述类似的目的。子组中最重要的部分是checks字段，该字段是用来做实际检测的。
这是一个子组的示例：
id: 1.1
text: API Server
checks:
- id: 1.1.1
text: "Ensure that the --allow-privileged argument is set (Scored)"
audit: "ps -ef | grep kube-apiserver | grep -v grep"
tests:
# ...
- id: 1.1.2
text: "Ensure that the --anonymous-auth argument is set to false (Not Scored)"
audit: "ps -ef | grep kube-apiserver | grep -v grep"
tests:
# ...
基准检测支持通过id在命令行上使用标志--group或-g来指定子组运行。
Check检查项
在一个基准检测中，一个check对象体现了CIS基准的建议。
这是一个示例 check对象：
id: 1.1.1
text: "Ensure that the --anonymous-auth argument is set to false (Not Scored)"
audit: "ps -ef | grep kube-apiserver | grep -v grep"
tests:
test_items:
- flag: "--anonymous-auth"
compare:
op: eq
value: false
set: true
remediation: |
Edit the API server pod specification file kube-apiserver
on the master node and set the below parameter.
--anonymous-auth=false
scored: false
一个检查项对象有一个id，text，audit，tests，remediation 和scored字段。
基准检测可以在带有--check标志的命令行中通过检查逗号分隔的id列表。
该audit字段指定要运行的检查命令，然后此命令的输出用来评估检测结果是否符合CIS Benchmark建议。
audit字段的执行结果根据tests对象指定的条件进行评估，tests对象包含bin_op和test_items。
test_items规定了audit命令的执行结果必须符合检查制定的标准，这些标准由从audit命令执行结果中提取的关键字组成，并将这些关键字与CIS Benchmark期望的值进行比较。
有两种方法可以从audit命令的执行结果中提取关键字， 信号变量和路径。
1. flag是命令行参数时会被提取为关键字, 关联的audit命令通常是一个ps命令和grep命令所要检查的服务启动参数：
ps -ef | grep somebinary | grep -v grep
这是该命令行参数选项的示例用法：
# ...
audit: "ps -ef | grep kube-apiserver | grep -v grep"
tests:
test_items:
- flag: "--anonymous-auth"
# ...
2.path在JSON或YAML配置文件中设置的选项时也会是关键字，关联的audit命令通常是cat /path/to/config-yaml-or-json。例如：
# ...
text: "Ensure that the --anonymous-auth argument is set to false (Not Scored)"
audit: "cat /path/to/some/config"
tests:
test_items:
- path: "{.someoption.value}"
# ...
test_item通过set和compare字段设置关键字和audit命令输出的对比结果 。
test_items:
- flag: "--anonymous-auth"
compare:
op: eq
value: false
set: true
set检查用来判断审计命令的输出或配置文件中是否存在关键字，set可能设置的值为true和false。
当审计命令或配置文件的输出中存在关键字时，表示检查通过set为true。当审计命令或配置文件的输出中不存在关键字时，检查不通过set为false。
compare中的两个字段op和value用于将关键字与期望值进行比较。op代表用于比较的操作，而value代表要比较的值。
要使用compare，set必须为true。如果set为假，则比较将被忽略
基准检测op当前支持的（操作）如下所示：
eq：测试关键字是否等于比较值。
noteq：测试关键字是否不等于比较值。
gt：测试关键字是否大于比较值。
gte：测试关键字是否大于或等于比较值。
lt：测试关键字是否小于比较值。
lte：测试关键字是否小于或等于比较值。
has：测试关键字是否包含比较值。
nothave：测试关键字是否不包含比较值。
valid_elements：测试关键字是否包含所提供值列表中的有效元素。提供的列表中的值使用逗号作为分隔符。
regex：测试标志值是否与比较值正则表达式匹配。在YAML中定义正则表达式时，通常更容易将它们用单引号引起来，例如'^[abc]$'，以避免出现字符串转义的问题。
配置和变量
组件配置，二进制文件地址和名称根据使用的集群部署方式，操作系统和编排软件发行版而有所不同。因此，这些二进制文件和配置文件的地址通过编辑cfg/config.yaml文件来配置，并且通过控制项文件中的变量被二进制或者文件引用。
cfg/config.yaml文件是全局配置文件，可以为特定的CIS版本创建配置文件。在cfg/config.yaml中，特定版本配置的值会覆盖相同的值。