总结内容参考阿里云基线检查
一、CentOS Linux 7/8安全基线检查
一）设置密码修改最小间隔时间
设置密码修改最小间隔时间，限制密码更改过于频繁
修复方式
设置密码修改最小间隔时间为7-14天
设置root用户密码修改最小间隔时间为7-14天
二）设置SSH空闲超时退出时间
设置SSH空闲超时退出时间,可降低未授权用户访问其他用户ssh会话的风险
修复方式
设置ssh会话超时时间为300到900秒
设置ssh会话超时次数为0到3次
三）密码复杂度检查
检查密码长度和密码是否使用多种字符类型
修复方式
密码包含4类字符(大小写字母、数字、特殊字符)中的3类或4类
密码最小长度设置为9-32位
四）检查密码重用是否受限制
强制用户不重用最近使用的密码，降低密码猜测攻击风险
修复方式
system-auth强制用户不重用最近使用的密码数量为5-24之间
password-auth强制用户不重用最近使用的密码数量为5-24之间
五）检查系统空密码账户身份鉴别
描述
检查系统空密码账户
检查提示
--
加固建议
为用户设置一个非空密码，或者执行passwd -l <username>锁定用户
操作时建议做好记录或备份
六）禁止SSH空密码用户登录 SSH服务配置
描述
禁止SSH空密码用户登录
检查提示
--
加固建议
编辑文件/etc/ssh/sshd_config，将PermitEmptyPasswords配置为no:
PermitEmptyPasswords no
操作时建议做好记录或备份
七）设置密码失效时间身份鉴别
描述
设置密码失效时间，强制定期修改密码，减少密码被泄漏和猜测风险，使用非密码登陆方式(如密钥对)请忽略此项。
检查提示
--
加固建议
使用非密码登陆方式如密钥对，请忽略此项。在 /etc/login.defs 中将 PASS_MAX_DAYS 参数设置为 60-180之间，如:
PASS_MAX_DAYS 90
需同时执行命令设置root密码失效时间：
chage --maxdays 90 root
操作时建议做好记录或备份
八）确保密码到期警告天数为7或更多身份鉴别
描述
确保密码到期警告天数为7或更多
检查提示
--
加固建议
在 /etc/login.defs 中将 PASS_WARN_AGE 参数设置为7-14之间，建议为7：
PASS_WARN_AGE 7
同时执行命令使root用户设置生效：
chage --warndays 7 root
操作时建议做好记录或备份
九）确保SSH MaxAuthTries设置为3到6之间 SSH服务配置
描述
设置较低的Max AuthTrimes参数将降低SSH服务器被暴力攻击成功的风险。
检查提示
--
加固建议
在/etc/ssh/sshd_config中取消MaxAuthTries注释符号#，设置最大密码尝试失败次数3-6，建议为4：
MaxAuthTries 4
操作时建议做好记录或备份
十）确保rsyslog服务已启用安全审计
描述
确保rsyslog服务已启用，记录日志用于审计
检查提示
--
加固建议
运行以下命令启用rsyslog服务：
systemctl enable rsyslog
systemctl start rsyslog
操作时建议做好记录或备份
十一）确保SSH LogLevel设置为INFO服务配置
描述
确保SSH LogLevel设置为INFO,记录登录和注销活动
检查提示
--
加固建议
编辑 /etc/ssh/sshd_config 文件以按如下方式设置参数(取消注释):
LogLevel INFO
操作时建议做好记录或备份
十二）访问控制配置文件的权限设置文件权限
描述
访问控制配置文件的权限设置
检查提示
--
加固建议
运行以下4条命令：
chown root:root /etc/hosts.allow
chown root:root /etc/hosts.deny
chmod 644 /etc/hosts.deny
chmod 644 /etc/hosts.allow
操作时建议做好记录或备份
十三）设置用户权限配置文件的权限文件权限
描述
设置用户权限配置文件的权限
检查提示
--
加固建议
执行以下5条命令
chown root:root /etc/passwd /etc/shadow /etc/group /etc/gshadow
chmod 0644 /etc/group
chmod 0644 /etc/passwd
chmod 0400 /etc/shadow
chmod 0400 /etc/gshadow
操作时建议做好记录或备份
十四）开启地址空间布局随机化入侵防范
描述
它将进程的内存空间地址随机化来增大入侵者预测目的地址难度，从而降低进程被成功入侵的风险
检查提示
--
加固建议
在/etc/sysctl.conf或/etc/sysctl.d/*文件中设置以下参数： kernel.randomize_va_space = 2 执行命令： sysctl -w kernel.randomize_va_space=2
操作时建议做好记录或备份
十五）确保root是唯一的UID为0的帐户身份鉴别
描述
除root以外其他UID为0的用户都应该删除，或者为其分配新的UID
检查提示
--
加固建议
除root以外其他UID为0的用户(查看命令cat /etc/passwd | awk -F: '($3 == 0) { print $1 }'|grep -v '^root$' )都应该删除，或者为其分配新的UID
操作时建议做好记录或备份
二、docker基线检查
一）限制容器之间的网络流量服务配置
描述
默认情况下，同一主机上的容器之间允许所有网络通信。 如果不需要，请限制所有容器间的通信。 将需要相互通信的特定容器链接在一起。默认情况下，同一主机上所有容器之间都启用了不受限制的网络流量。 因此，每个容器都有可能读取同一主机上整个容器网络上的所有数据包。 这可能会导致意外和不必要的信息泄露给其他容器。 因此，限制容器间的通信。
检查提示
--
加固建议
在守护程序模式下运行docker并传递'--icc = false'作为参数。 例如，
/usr/bin/dockerd --icc=false
若使用systemctl管理docker服务则需要编辑
/usr/lib/systemd/system/docker.service
文件中的ExecStart参数添加 --icc=false选项 然后重启docker服务
systemctl daemon-reload
systemctl restart docker
二）不共享主机的进程名称空间服务配置
描述
进程ID（PID）命名空间隔离了进程ID号空间，这意味着不同PID命名空间中的进程可以具有相同的PID。 这是容器和主机之间的进程级别隔离。
PID名称空间提供了流程分离。 PID命名空间删除了系统进程的视图，并允许进程ID重复使用，包括PID1。如果主机的PID命名空间与容器共享，则它将基本上允许容器内的进程查看主机上的所有进程。 系统。 这破坏了主机和容器之间的进程级别隔离的好处。 有权访问容器的人最终可以知道主机系统上正在运行的所有进程，甚至可以从容器内部杀死主机系统进程。 这可能是灾难性的。 因此，请勿与容器共享主机的进程名称空间。
检查提示
--
加固建议
不要使用'--pid = host'参数启动容器。
三）将容器的根文件系统挂载为只读服务配置
描述
容器的根文件系统应被视为“黄金映像”，并且应避免对根文件系统的任何写操作。 您应该显式定义用于写入的容器卷。
您不应该在容器中写入数据。 属于容器的数据量应明确定义和管理。 在管理员控制他们希望开发人员在何处写入文件和错误的许多情况下，这很有用。
检查提示
--
加固建议
添加“ --read-only”标志，以允许将容器的根文件系统挂载为只读。 可以将其与卷结合使用，以强制容器的过程仅写入要保留的位置。 您应该按以下方式运行容器：
docker run --interactive --tty --read-only --volume <writable-volume> <Container Image Name or ID> <Command>
如果您是k8s或其他容器编排软件编排的容器，请按照相应的安全策略配置或忽略。
四）Docker cp命令可导致容器逃逸攻击漏洞入侵防范
描述
当Docker宿主机使用cp命令时，会调用辅助进程docker-tar，该进程没有被容器化，且会在运行时动态加载一些libnss*.so库。攻击者可以通过在容器中替换libnss*.so等库，将代码注入到docker-tar中。当Docker用户尝试从容器中拷贝文件时将会执行恶意代码，成功实现Docker逃逸，获得宿主机权限。
检查提示
容器id : 2e9375a917dc e8d7fbf7c0ff daf622879cb1 ac0c65d77423 bcb06dbdc161
加固建议
19.03.1之前的docker，存在docker cp容器逃逸的漏洞 建议以非root权限启动容器，可以有效遏制容器逃逸 docker run --user=<uid> ...启动 或 升级到最新的安全可用的docker版本
操作时建议做好记录或备份
五）审核Docker文件和目录安全审计
描述
除了审核常规的Linux文件系统和系统调用之外，还审核所有与Docker相关的文件和目录。 Docker守护程序以“ root”特权运行。 其行为取决于某些关键文件和目录。如 /var/lib/docker、/etc/docker、docker.service、 docker.socket、/usr/bin/docker-containerd、/usr/bin/docker-runc等文件和目录
检查提示
--
加固建议
在/etc/audit/audit.rules与/etc/audit/rules.d/audit.rules文件中添加以下行：
-w /var/lib/docker -k docker
-w /etc/docker -k docker
-w /usr/lib/systemd/system/docker.service -k docker
-w /usr/lib/systemd/system/docker.socket -k docker
-w /usr/bin/docker-containerd -k docker
-w /usr/bin/docker-runc -k docker
然后，重新启动audit程序。 例如
service auditd restart
操作时建议做好记录或备份
六）限制容器的内存使用量服务配
描述
默认情况下，Docker主机上的所有容器均等地共享资源。 通过使用Docker主机的资源管理功能（例如内存限制），您可以控制容器可能消耗的内存量。
默认情况下，容器可以使用主机上的所有内存。 您可以使用内存限制机制来防止由于一个容器消耗主机的所有资源而导致的服务拒绝，从而使同一主机上的其他容器无法执行其预期的功能。 对内存没有限制可能会导致一个问题，即一个容器很容易使整个系统不稳定并因此无法使用。
检查提示
--
加固建议
仅使用所需的内存来运行容器。 始终使用'--memory'参数运行容器。 您应该按以下方式启动容器：
docker run --interactive --tty --memory 256m <Container Image Name or ID>
操作时建议做好记录或备份
七）为Docker启用内容信任服务配置
描述
默认情况下禁用内容信任。 您应该启用它。
内容信任提供了将数字签名用于发送到远程Docker注册表和从远程Docker注册表接收的数据的功能。 这些签名允许客户端验证特定图像标签的完整性和发布者。 这确保了容器图像的出处
检查提示
--
加固建议
要在bash shell中启用内容信任，请输入以下命令：export DOCKER_CONTENT_TRUST=1 或者，在您的配置文件中设置此环境变量，以便在每次登录时启用内容信任。 内容信任目前仅适用于公共Docker Hub的用户。 当前不适用于Docker Trusted Registry或私有注册表。
操作时建议做好记录或备份
三、Redis安全基线检查
一）禁止监听在公网 访问控制
描述
Redis监听在0.0.0.0，可能导致服务对外或内网横向移动渗透风险，极易被黑客利用入侵。
检查提示
--
加固建议
在redis的配置文件redis.conf中配置如下： bind 127.0.0.1或者内网IP，然后重启redis
二）禁止使用root用户启动 访问控制
描述
使用root权限去运行网络服务是比较有风险的（nginx和apache都是有独立的work用户，而redis没有）。redis crackit 漏洞就是利用root用户的权限来替换或者增加authorized_keys，来获取root登录权限的
检查提示
--
加固建议
使用root切换到redis用户启动服务:
useradd -s /sbin/nolog -M redis
sudo -u redis /<redis-server-path>/redis-server /<configpath>/redis.conf 2&1>/dev/null &
三）限制redis 配置文件访问权限 文件权限
描述
因为redis密码明文存储在配置文件中，禁止不相关的用户访问改配置文件是必要的，设置redis配置文件权限为600,
检查提示
--
加固建议
执行以下命令修改配置文件权限：
chmod 600 /<filepath>/redis.conf
四）禁用或者重命名危险命令 入侵防范
描述
Redis中线上使用keys *命令是非常危险的，应该禁用或者限制使用这些危险的命令，可降低Redis写入文件漏洞的入侵风险。
检查提示
--
加固建议
修改 redis.conf 文件，添加
rename-command FLUSHALL ""
rename-command FLUSHDB ""
rename-command CONFIG ""
rename-command KEYS ""
rename-command SHUTDOWN ""
rename-command DEL ""
rename-command EVAL ""
然后重启redis。 重命名为"" 代表禁用命令，如想保留命令，可以重命名为不可猜测的字符串，如： rename-command FLUSHALL joYAPNXRPmcarcR4ZDgC
五）打开保护模式 访问控制
描述
redis默认开启保护模式。要是配置里没有指定bind和密码，开启该参数后，redis只能本地访问，拒绝外部访问。
检查提示
--
加固建议
redis.conf安全设置： # 打开保护模式 protected-mode yes
六）修改默认6379端口 服务配置
描述
避免使用熟知的端口,降低被初级扫描的风险
检查提示
--
加固建议
编辑文件redis的配置文件redis.conf，找到包含port的行，将默认的6379修改为自定义的端口号，然后重启redis
七）版本存在安全漏洞入侵防范
描述
Redis以下版本存在漏洞，容易被入侵
1. Redis 2.8.1 之前版本和 3.0.2 之前 3.x 版本存在字节码命令执行漏洞
https://avd.aliyun.com/detail?id=AVD-2015-4335
2. Redis 4.x至5.0.5版本存在主从复制命令执行漏洞
3. Redis 3.2.0 至 3.2.4 版本存在缓冲区溢出漏洞，可导致任意代码执行
https://avd.aliyun.com/detail?id=AVD-2016-8339
检查提示
--
加固建议
更新服务至最新版本，完成漏洞的修复，这些漏洞基于未授权访问或者服务存在弱口令，完成访问认证加固可降低被入侵风险。
八）开启redis密码认证,并设置高复杂度密码 身份鉴别
描述
redis在redis.conf配置文件中，设置配置项requirepass， 开户密码认证。 redis因查询效率高，auth这种命令每秒能处理9w次以上，简单的redis的密码极容易为攻击者暴破。
检查提示
存在弱密码(配置文件|密码):/app/3rd/redis-6.2.4/./redis_cluster/7002/redis.conf| /app/3rd/redis-6.2.4/./redis_cluster/7001/redis.conf|
加固建议
打开redis.conf，找到requirepass所在的地方，修改为指定的密码，密码应符合复杂性要求：
1、长度8位以上
2、包含以下四类字符中的三类字符:
英文大写字母(A 到 Z)
英文小写字母(a 到 z)
10 个基本数字(0 到 9)
非字母字符(例如 !、$、#、%、@、^、&)
3、避免使用已公开的弱口令，如：abcd.1234 、admin@123等
再去掉前面的#号注释符，然后重启redis
四、Mysql安全基线检查
一）为MySQL服务使用专用的最低特权账户访问控制
描述
使用最低权限账户运行服务可减小MySQL天生漏洞的影响。受限账户将无法访问与MySQL无关的资源，例如操作系统配置。
检查提示
--
加固建议
使用非root和非sudo权限用户启动MySQL服务
二）禁用local-infile选项访问控制
描述
禁用local_infile选项会降低攻击者通过SQL注入漏洞器读取敏感文件的能力
检查提示
--
加固建议
编辑Mysql配置文件<conf_path>/my.cnf，在[mysqld] 段落中配置local-infile参数为0，并重启mysql服务：
local-infile=0
三）删除'test'数据库服务配置
描述
测试数据库可供所有用户访问，并可用于消耗系统资源。删除测试数据库将减少MySQL服务器的攻击面。
检查提示
--
加固建议
登录数据库执行以下SQL语句删除test数据库：
DROP DATABASE test;
flush privileges;
四）确保没有用户配置了通配符主机名身份鉴别
描述
避免在主机名中只使用通配符，有助于限定可以连接数据库的客户端，否则服务就开放到了公网
检查提示
--
加固建议
执行SQL更新语句，为每个用户指定允许连接的host范围。
登录数据库，执行use mysql; ；
执行语句select user,Host from user where Host='%';查看HOST为通配符的用户;
删除用户或者修改用户host字段，删除语句：DROP USER 'user_name'@'%'; 。更新语句：update user set host = <new_host> where host = '%';。
执行SQL语句:
OPTIMIZE TABLE user;
flush privileges;
五）修改默认3306端口服务配置
描述
避免使用熟知的端口，降低被初级扫描的风险
检查提示
--
加固建议
编辑<conf_path>/my.cnf文件，[mysqld] 段落中配置新的端口参数，并重启MySQL服务：
port=3506
六）禁止使用--skip-grant-tables选项启动MySQL服务访问控制
描述
使用此选项，会导致所有客户端都对所有数据库具有不受限制的访问权限。
检查提示
--
加固建议
编辑Mysql配置文件<conf_path>/my.cnf，删除skip-grant-tables参数，并重启mysql服务
七）确保配置了log-error选项安全审计
描述
启用错误日志可以提高检测针对mysql和其他关键消息的恶意尝试的能力，例如，如果错误日志未启用，则连接错误可能会被忽略。
检查提示
--
加固建议
编辑Mysql配置文件<conf_path>/my.cnf，在[mysqld_safe] 段落中配置log-error参数，<log_path>代表存放日志文件路径，如：/var/log/mysqld.log，并重启mysql服务：
log-error=<log_path>
八）确保log-raw选项没有配置为ON安全审计
描述
当log-raw记录启用时，有权访问日志文件的人可能会看到纯文本密码。
检查提示
--
加固建议
编辑Mysql配置文件<conf_path>/my.cnf，删除log-raw参数，并重启mysql服务
九）匿名登录检查身份鉴别
描述
检查MySQL服务是否允许匿名登录
检查提示
--
加固建议
登录MySQL数据库，执行以下命令删除匿名账户：
delete from user where user='';
flush privileges;
十）禁用symbolic-links选项服务配置
描述
禁用符号链接以防止各种安全风险
检查提示
--
加固建议
编辑Mysql配置文件<conf_path>/my.cnf，在[mysqld] 段落中配置symbolic-links=0，5.6及以上版本应该配置为skip_symbolic_links=yes，并重启mysql服务。
五、Kubernetes-Master安全基线检查
一）确保将--allow-privileged参数设置为false 用户帐户和环境
描述
特权容器具有所有系统功能，并且还消除了设备cgroup控制器强制执行的所有限制。 换句话说，容器可以完成主机可以做的几乎所有事情。 存在此标志是为了允许特殊用例，例如在Docker中运行Docker，因此应避免在生产工作负载中使用。
影响：
您将无法运行任何特权容器。
注意：Kubernetes集群目前使用的许多组件都使用特权容器（例如Container Network Interface插件）。应该注意确保最小化此类插件的使用，尤其是应仔细检查对kube-system名称空间之外的特权容器的任何使用。在可能的情况下，查看此类插件所需的权限，以确定是否可以应用更细粒度的权限集。
检查提示
--
加固建议
编辑主节点上的/ etc / kubernetes / config文件，并将KUBE_ALLOW_PRIV参数设置为“ --allow-privileged = false”： KUBE_ALLOW_PRIV =“-allow-privileged = false”根据您的系统，重新启动kube-apiserver服务。 例如： systemctl restart kube-apiserver.service
操作时建议做好记录或备份
二）禁止敏感字段配置到configmap中服务配置
描述
使用secret配置敏感信息方便管理，减少泄露风险
检查提示
含敏感信息的configmap:(namespace:kube-system configmap:kube-proxy) , (namespace:kube-system configmap:kubelet-config-1.21) , (namespace:kubesphere-system configmap:kubesphere-config)
加固建议
敏感字段，如password，pwd等，建议配置到secret后再关联到pod中，以减少泄露风险
创建方法
https://kubernetes.io/zh/docs/concepts/configuration/secret/
关联参考
https://kubernetes.io/zh/docs/concepts/configuration/secret/
操作时建议做好记录或备份
三）确保将准入控制策略设置为AlwaysPullImages身份鉴别
描述
将准入控制策略设置为AlwaysPullImages会强制每个新容器每次都提取所需的图像。 在多租户群集中，可以确保用户只有拥有凭据才能将其私有图像的人才能使用其私有图像。 如果没有这种准入控制策略，一旦将图像拖到节点上，来自任何用户的任何吊舱都可以简单地通过知道图像名称来使用它，而无需对图像所有权进行任何授权检查。 启用此插件后，始终会在启动容器之前提取图像，这意味着需要有效的凭据
检查提示
--
加固建议
编辑主节点上的<apiserver_config>文件，添加或修改参数设置为
--admission-control = ...，AlwaysPullImages，...
<apiserver_config>可能存在于以下路径
/etc/kubernetes/config
/etc/kubernetes/manifests/kube-apiserver.yaml
/etc/kubernetes/manifests/kube-apiserver.yml
/etc/kubernetes/manifests/kube-apiserver.manifest
/var/snap/kube-apiserver/current/args
/var/snap/microk8s/current/args/kube-apiserver
defaultconf: /etc/kubernetes/manifests/kube-apiserver.yaml
操作时建议做好记录或备份
四）使用https进行kubelet连接。网络及服务
描述
从apiserver到kubelet的连接可能会携带敏感数据，例如机密和密钥。 因此，对于apiserver和kubelet之间的任何通信使用过渡加密非常重要。
检查提示
--
加固建议
编辑主节点上的apiserver配置文件<apiserver_config_path>，并从KUBE_API_ARGS参数中删除（默认为true）或修改成 --kubelet-https=true参数。 根据您的系统，重新启动kube-apiserver服务。 例如：
systemctl restart kube-apiserver.service
<apiserver_config_path>可能是以下文件
/etc/kubernetes/manifests/kube-apiserver.yaml,
/etc/kubernetes/manifests/kube-apiserver.yml,
/etc/kubernetes/manifests/kube-apiserver.manifest,
/var/snap/kube-apiserver/current/args,
/var/snap/microk8s/current/args/kube-apiserver
操作时建议做好记录或备份
五）确保未设置--insecure-allow-any-token参数身份鉴别
描述
不允许任何不安全的令牌。
接受不安全的令牌将允许任何令牌而无需实际验证任何内容。 从令牌解析用户信息，并允许连接。
检查提示
--
加固建议
编辑主节点上的apiserver配置文件（默认是/etc/kubernetes/apiserver），并在KUBE_API_ARGS参数中删除“ --insecure-allow-any-token = username/group1,group2” 不允许配置--insecure-allow-any-token项 根据您的系统，重新启动kube-apiserver服务。 例如 systemctl restart kube-apiserver.service
操作时建议做好记录或备份
六）确保未设置--insecure-bind-address参数网络及服务
描述
不要绑定到不安全的地址。
如果将联合身份验证apiserver绑定到不安全的地址，则基本上任何可以通过不安全端口连接到该地址的人都将具有未经身份验证和未加密的访问权限。 联合身份验证apiserver不对不安全的绑定进行任何身份验证检查，也不对不安全的流量进行加密。 因此，您不应将联合身份验证apiserver绑定到不安全的地址。
检查提示
--
加固建议
编辑主节点上的apiserver配置文件<apiserver_config_path>，并在KUBE_API_ARGS参数中
删除--insecure-bind-address 项，或配置为本地，如 --insecure-bind-address =127.0.0.1
根据您的系统，重新启动kube-apiserver服务。 例如 systemctl restart kube-apiserver.service
<apiserver_config_path>可能是以下文件
/etc/kubernetes/manifests/kube-apiserver.yaml,
/etc/kubernetes/manifests/kube-apiserver.yml,
/etc/kubernetes/manifests/kube-apiserver.manifest,
/var/snap/kube-apiserver/current/args,
/var/snap/microk8s/current/args/kube-apiserver
操作时建议做好记录或备份
七）确保将--client-cert-auth参数设置为true访问控制
描述
etcd是Kubernetes部署使用的高度可用的键值存储，用于持久存储其所有REST API对象。 这些对象本质上是敏感的，未经身份验证的客户端不应使用。 您应该通过有效的证书启用客户端身份验证，以确保对etcd服务的访问安全。
检查提示
--
加固建议
打开etcd配置文件，默认在/etc/kubernetes/manifests/etcd.yaml 在etcd下配置
- --client-cert-auth=true
需重启etcd，如自动重启请耐心等待 在etcd服务器节点上运行以下命令： ps -ef | grep etcd验证--client-cert-auth参数是否设置为true（生效）。 <etcd_config>可能存在以下目录列表中
/etc/kubernetes/manifests/etcd.yaml /etc/kubernetes/manifests/etcd.yml /etc/kubernetes/manifests/etcd.manifest /etc/etcd/etcd.conf /var/snap/etcd/common/etcd.conf.yml /var/snap/etcd/common/etcd.conf.yaml /var/snap/microk8s/current/args/etcd defaultconf:/etc/kubernetes/manifests/etcd.yaml
八）确保将唯一的证书颁发机构用于etcd身份鉴别
描述
为etcd服务配置TLS加密。
检查提示
--
加固建议
打开etcd配置文件，默认在/etc/kubernetes/manifests/etcd.yaml 在etcd下配置
--key-file=< k8sclient.key >
--cert-file=< k8sclient.cert >
并使用https作为URL架构
需重启etcd，如自动重启请耐心等待 <etcd_config>可能存在以下目录列表中
/etc/kubernetes/manifests/etcd.yaml
/etc/kubernetes/manifests/etcd.yml
/etc/kubernetes/manifests/etcd.manifest
/etc/etcd/etcd.conf
/var/snap/etcd/common/etcd.conf.yml
/var/snap/etcd/common/etcd.conf.yaml
/var/snap/microk8s/current/args/etcd
defaultconf:/etc/kubernetes/manifests/etcd.yaml
操作时建议做好记录或备份
九）确保将唯一的证书颁发机构用于etcd可信验证
描述
描述：
对etcd使用与Kubernetes所使用的证书颁发机构不同的证书颁发机构。
检查提示
--
加固建议
查看etcd环境使用的CA，并确保它与Kubernetes使用的CA证书不匹配。 在etcd服务器节点上运行以下命令： ps -ef | grep etcd查看--trusted-ca-file参数引用的文件，并确保所引用的CA与用于管理整个Kubernetes集群的CA不同。 补救措施： 请遵循etcd文档，并为etcd服务创建专用的证书颁发机构设置，也可参考``` https://www.yuque.com/opensource-books/kubernetes-handbook/practice-create-tls-and-secret-key
影响：
将需要对专用证书颁发机构的证书和密钥进行其他管理。
在配置文件中配置 `--trusted-ca-file`
<etcd_config>可能存在以下目錄列表中
/etc/kubernetes/manifests/etcd.yaml /etc/kubernetes/manifests/etcd.yml /etc/kubernetes/manifests/etcd.manifest /etc/etcd/etcd.conf /var/snap/etcd/common/etcd.conf .yml /var/snap/etcd/common/etcd.conf.yaml /var/snap/microk8s/current/args/etcd defaultconf:/etc/kubernetes/manifests/etcd.yaml
十）确保将--peer-client-cert-auth参数设置为true可信验证
描述
应该配置etcd以进行对等身份验证
检查提示
--
加固建议
在etcd服务器节点上运行以下命令： ps -ef | grep etcd验证--peer-client-cert-auth参数是否设置为true。 在etcd服务器节点上编辑etcd环境文件
配置文件可能存在路径
/etc/kubernetes/manifests/kube-apiserver.yaml,
/etc/kubernetes/manifests/kube-apiserver.yml,
/etc/kubernetes/manifests/kube-apiserver.manifest,
/var/snap/kube-apiserver/current/args,
/var/snap/microk8s/current/args/kube-apiserver
并添加--peer-client-cert-auth 参数，设置为true，如没有请在配置文件中添加
操作时建议做好记录或备份
十一）确保正确设置--wal-dir参数文件权限
描述
etcd是Kubernetes部署使用的高度可用的键值存储，用于持久存储其所有REST API对象。 这些对象本质上是敏感的，不应与日志数据混合。 将日志数据与etcd数据分开还可以确保可以分别保护这两种类型的数据。 另外，您可以使用集中式和远程日志目录进行持久日志记录。 此外，这种分离还有助于避免日志记录和其他IO操作之间的IO竞争。
检查提示
--
加固建议
在<etcd_config>配置文件中新增/修改配置
--wal-dir=...
使其等于适当值，但不能与--data-dir 的值相同 <etcd_config>可能存在以下目录列表中
/etc/kubernetes/manifests/etcd.yaml /etc/kubernetes/manifests/etcd.yml /etc/kubernetes/manifests/etcd.manifest /etc/etcd/etcd.conf /var/snap/etcd/common/etcd.conf.yml /var/snap/etcd/common/etcd.conf.yaml /var/snap/microk8s/current/args/etcd defaultconf:/etc/kubernetes/manifests/etcd.yaml
十二）禁止apiserver使用AlwaysAllow的鉴权模式身份鉴别
描述
基于角色（Role）的访问控制（RBAC）是一种基于企业中用户的角色来调节控制对计算机或网络资源的访问方法。
RBAC 使用 rbac.authorization.k8s.io API 组 来驱动鉴权操作，允许管理员通过 Kubernetes API 动态配置策略。
在ABAC中，K8s集群中的访问策略只能跟用户直接关联
而在RBAC中，访问策略可以跟某个角色关联，具体的用户在跟一个或多个角色相关联
如果您的集群是1.6版本以后，建议您使用RBAC鉴权，更为灵活，方便管理
检查提示
--
加固建议
apiserver认证后还需要进行权限认证 开启方式为--authorization-mode 编辑kube-apiserver.service文件，在apiserver的启动参数，或配置文件中添加--authorization-mode的参数为以下方式中的一种，并确保不能包含AlwaysAllow
ABAC
Webhook
RBAC
Node
ABAC：基于属性的访问控制 RBAC：基于角色的访问控制，这是 1.6 版本之后开始推荐的授权方式 WebHook： kubernetes apiserver 根据事先定义的授权策略 来决定用户是否有权限访问。每个请求都带上了用户和资源的信息：比如发送请求的用户、请求的路径、请求的动作等，授权就是根据这些信息和授权策略进行比较，如果符合策略，则认为授权通过，否则会返回 403 Unauthorized 错误。
操作时建议做好记录或备份
十三）至少启用一种apiserver的认证方式访问控制
描述
认证是kubernetes的第一道防线，也是最重要的一道防线，如果您的kubernetes开启了允许匿名用户登录，相当于是再裸奔，相当的危险，建议您选一种适当的认证方式开启
检查提示
--
加固建议
在以下认证方式中选择一种进行配置，最佳推荐x509认证
X509客户证书
Static Token File(静态令牌)
Bootstrap Tokens（引导令牌）
Static Password File（静态密码文件）
Service Account Tokens（服务帐户令牌）
OpenID Connect Tokens（OpenID Connect令牌，或称jwt）
Webhook Token Authentication（Webhook令牌认证）
配置详情参考https://v1-16.docs.kubernetes.io/docs/reference/access-authn-authz/authentication/ 另外禁用匿名登录，在<apiserver_config>中指定 --anonymous-auth 参数来禁用 在 1.5.1 - 1.5.x 版本中，默认情况下命名访问是被禁用的，可以通过传递 --anonymous-auth=True来禁用 其他版本--anonymous-auth=False来禁用，使用kubectl version 可以查看版本号（版本号为1.5.x的用户按要求配置后可以忽略该项）
操作时建议做好记录或备份
十四）kubeflow直接暴露在公网下访问控制
描述
kubeflow直接暴露在公网下，有可能遭受批量自动化攻击，请按建议取一定的安全措施
检查提示
--
加固建议
kubectl get service istio-ingressgateway -n istio-system 查看kubeflow是否存在独立ip暴露公网 尽量添加安全措施使其不直接暴露公网，如配置为NodePort替代LoadBalancer，或添加安全组，如已添加，可将该项加致白名单
操作时建议做好记录或备份
十五）确保将配置文件权限设置为644或更严格文件权限
描述
配置文件控制设置工作节点各个组件行为的各种参数。 您应限制其文件权限以维护文件的完整性。 该文件只能由系统上的管理员写入。
检查提示
--
加固建议
stat -c %a <kubernetes_config>
Verify that the permissions are 644 or more restrictive. Run the below command (based on the file location on your system) on the each worker node. For example, chmod 644 <kubernetes_config> <kubernetes_config> 默认的值为/etc/kubernetes/kubelet.conf 或系统环境变量里KUBECONFIG的值（可通过env命令查看）
操作时建议做好记录或备份
