1、腾讯云
健康检查的参考资料:cloud.tencent.com
- 检查的项目(参数说明)
检查类别 | 检查项 | 检查内容 |
资源状态 | kube-apiserver 的状态 | 检测组件是否正在运行,如果组件以 Pod 形式运行,则检测其24小时内是否重启过。 |
kube-scheduler 的状态 | ||
kube-controller-manager 的状态 | ||
etcd 的状态 | ||
kubelet 的状态 | ||
kube-proxy 的状态 | ||
dockerd 的状态 | ||
master 节点的状态 | 检测节点状态是否 Ready 且无其他异常情况,如内存不足,磁盘不足等。 | |
worker 节点的状态 | 检测节点状态是否 Ready 且无其他异常情况,如内存不足,磁盘不足等。 | |
各个工作负载的状态 | 检测工作负载当前可用 Pod 数是否符合其期望目标 Pod 数。 | |
运行情况 | kube-apiserver 的参数配置 | 根据 master 节点配置检测以下参数: max-requests-inflight:给定时间内运行的非变更类请求的最大值。 max-mutating-requests-inflight:给定时间内运行的变更类请求的最大值。 |
kube-scheduler 的参数配置 | 根据 master 节点配置检测以下参数: kube-api-qps:请求 kube-apiserver 使用的 QPS。 kube-api-burst:和 kube-apiserver 通信的时候最大 burst 值。 | |
kube-controller-manager 的参数配置 | 根据 master 节点配置检测以下参数: kube-api-qps:请求 kube-apiserver 使用的 QPS。 kube-api-burst:和 kube-apiserver 通信的时候最大 burst 值。 | |
etcd 的参数配置 | 根据 master 节点配置检测以下参数:quota-backend-bytes:存储大小。 | |
node 高可用 | 检测目前集群是否是单节点集群;检测当前集群节点是否支持多可用区容灾。即当一个可用区不可用后,其他可用区的资源总和是否足以支撑当前集群业务规模。 | |
工作负载的 Request 和 Limit 配置 | 检测工作负载是否有未设置资源限制的容器,配置资源限制有益于完善资源规划、Pod 调度、集群可用性等。 | |
工作负载的反亲和性配置 | 检测工作负载是否配置了亲和性或者反亲和性,配置反亲和性有助于提高业务的高可用性。 | |
工作负载的 PDB 配置 | 检测工作负载是否配置了 PDB,配置 PDB 可避免您的业务因驱逐操作而不可用。 | |
工作负载的健康检查配置 | 检测工作负载是否配置了健康检查,配置健康检查有助于发现业务异常。 | |
HPA-IP 配置 | 当前集群剩余的 Pod IP 数目是否满足 HPA 扩容的最大数。 |
说明:
- 创建集群
- 登录 容器服务控制台,选择左侧导航栏中的运维中心 > 健康检查。
- 立即检查
- 检查结果-资源状态
运行状况
2、火山云
火山云官方文档没有健康检查的内容,有基线巡检和应用巡检的内容,详见基线巡检--容器服务-火山引擎
2.1 基线巡检
基线巡检是基于业界的一些安全要求规范,主要面向 Kubernetes 集群中的 Worker 节点。基线巡检为用户提供集群节点的安全性巡检,可以及时发现集群节点中的不安全配置,并提示用户进行修复,以免被利用攻击,保障用户业务稳定、安全地运行。
注:此处巡检项详细信息官方未给出说明,火山云试用需要企业认证,也无法通过试用得知具体巡检项。以下截图均来自官网,没有更多截图。可以参考阿里云的基线巡检内容。
配置立即巡检
手动立即触发一次基线巡检。可参考以下步骤执行立即巡检:
- 登录 容器服务控制台。
- 单击左侧导航栏中的 集群。
- 在集群列表页面,单击目标集群。
- 在集群管理页面的左侧导航栏中,选择 安全管理 基线巡检,单击 立即巡检。
- 在 立即巡检 对话框中,确认巡检任务相关提示信息。
- 单击 确定,开始巡检。
注:CIS Kubernetes基线是针对开源Kubernetes发行版本所编写的,旨在尽可能广泛应用于各个发行版本,同时不同的基线版本与特定的Kubernetes版本相关联。
配置周期巡检
设置每月、每周或指定日期的固定时间点,周期性自动触发基线巡检任务。可参考以下步骤配置周期巡检:
- 登录 容器服务控制台。
- 单击左侧导航栏中的 集群。
- 在集群列表页面,单击目标集群。
- 在集群管理页面的左侧导航栏中,选择 安全管理 基线巡检,单击 周期巡检设置。
- 在 周期巡检设置 对话框中,确认巡检任务相关提示信息后,开启 周期巡检。 巡检周期支持 每周 或 每月,同时配置具体的时间。
- 单击 确定,保存周期巡检配置。
查看巡检详情
- 登录 容器服务控制台。
- 单击左侧导航栏中的 集群。
- 在集群列表页面,单击目标集群。
- 在集群管理页面的左侧导航栏中,选择 安全管理 基线巡检。
- 在 基线巡检 页面中,单击已完成的基线巡检名称,查看巡检详情。
- 在 节点列表 页面,查看集群下所有节点的巡检状态。
- 单击 巡检详情,查看单节点的巡检详情。
- 单击 重新巡检,对单节点进行重新巡检。
- 在单节点右侧 操作 列,单击 详情,可以查看该节点具体巡检项的详细信息。
2.2 应用巡检
应用巡检基于业界的一些安全要求规范,结合容器安全最佳实践,为用户提供应用安全巡检能力。应用巡检可以及时发现并阻止用户部署的不安全配置,并提示用户进行修复,以免应用被攻击或利用,保障用户业务稳定、安全地运行。 应用巡检弥补了基线巡检未覆盖的 Workload、Pod、ConfigMap 等 Kubernetes 原生资源的安全扫描检查。可通过巡检系统,帮助用户发现 Kubernetes 原生资源中潜在的安全隐患并给出修复建议,有效提升容器集群云原生应用的安全性。
注:此处巡检项详细信息官方未给出说明,火山云试用需要企业认证,也无法通过试用得知具体巡检项。以下截图均来自官网,没有更多截图。
配置巡检策略
执行巡检之前,可以配置巡检策略。
- 登录 容器服务控制台。
- 单击左侧导航栏中的 集群。
- 在集群列表页面,单击目标集群。
- 在集群管理页面的左侧导航栏中,选择 安全管理 应用巡检,单击 策略配置。
- 在 策略配置 对话框,按需配置参数。
参数 | 描述 |
周期巡检 | 打开按钮,可按照固定周期进行应用巡检。详细的配置说明和操作步骤,请参见本文下方 配置周期巡检。 |
巡检项 | 容器服务提供 基线策略、加固策略、漏洞缓解策略 三种巡检分类,各分类具有不同的巡检项,请按需勾选巡检项。说明已配置的巡检项,对 立即巡检 和 周期巡检 均生效。鼠标悬浮到具体巡检项后,可查看该巡检项的策略说明。 |
基线策略:基线策略是一组安全配置规则,用于确保容器环境的安全性。这些规则包括但不限于:禁止使用特权容器、禁止使用不安全的镜像、禁止使用不安全的挂载点等。
加固策略:加固策略是一组安全措施,用于加强容器环境的安全性。这些措施包括但不限于:限制容器的内存使用量、限制容器的 CPU 使用量、限制容器的网络访问等。
漏洞缓解策略:漏洞缓解策略是一组措施,用于缓解容器环境中已知漏洞的影响。这些措施包括但不限于:升级容器镜像、修补容器运行时组件、修补容器应用部署配置等。
注:
1、不安全的挂载点是指容器中的文件系统挂载点存在潜在的安全风险,可能导致安全漏洞或攻击。在容器环境中,挂载点是指将主机或其他容器中的文件系统路径映射到容器内部的路径,以便容器可以访问主机或其他容器的文件或目录。 不安全的挂载点可能包括以下情况:
- 敏感数据泄露:如果容器中的挂载点允许访问主机上的敏感数据,攻击者可能通过挂载点访问或修改这些数据。
- 提升权限攻击:挂载点的不安全配置可能导致攻击者能够在容器内访问主机上的关键系统文件,从而提升其权限并执行恶意操作。
- 文件系统攻击:不安全的挂载点配置可能使容器容易受到文件系统攻击,例如通过挂载恶意文件或利用文件系统漏洞进行攻击。
在容器的基线策略中,禁止使用不安全的挂载点是为了确保容器环境的安全性,防止潜在的攻击和数据泄露。基线策略通常包括规则,禁止容器挂载主机上的敏感目录,限制挂载点的访问权限,并强制最小化容器所需的文件系统权限。这有助于降低攻击面,提高容器环境的整体安全性。
配置立即巡检
手动立即触发一次应用巡检。可参考以下步骤执行立即巡检:
- 登录 容器服务控制台。
- 单击左侧导航栏中的 集群。
- 在集群列表页面,单击目标集群。
- 在集群管理页面的左侧导航栏中,选择 安全管理 应用巡检,单击 立即巡检。
- 在系统弹出的提示框中,确认巡检任务相关提示信息。
- 单击 确定,开始巡检。
配置周期巡检
设置每月或每周指定日期的固定时间点,周期性自动触发应用巡检任务。可参考以下步骤配置周期巡检:
- 登录 容器服务控制台。
- 单击左侧导航栏中的 集群。
- 在集群列表页面,单击目标集群。
- 在集群管理页面的左侧导航栏中,选择 安全管理 应用巡检,单击 策略配置。
- 在 策略配置 对话框,开启 周期巡检,并配置巡检周期。 巡检周期支持 每周 或 每月,同时配置具体的时间。巡检项 的配置,请参见本文上方 配置巡检策略。
- 单击 确定,保存周期巡检配置。 配置完成后,系统将按巡检周期,自动触发巡检任务并输出报告。应用巡检仅保留最近一次巡检报告,请及时查看巡检报告。
查看巡检报告
巡检完成并输出巡检报告后,可按需筛选风险类型、资源级别等,查看巡检结果。
- 登录 容器服务控制台。
- 单击左侧导航栏中的 集群。
- 在集群列表页面,单击目标集群。
- 在集群管理页面的左侧导航栏中,选择 安全管理 应用巡检。
- 按需筛选 风险类型、资源级别,查看巡检结果。
- 单击巡检巡检资源名称右侧 操作 列的 详情,支持查看该资源的各个巡检项结果。
- 单击巡检项后面的 详情,支持查看各个巡检项相关的 策略说明、安全风险说明、修复建议 和 备注。
3、阿里云
阿里云为基线检查,详见https://help.aliyun.com/zh/security-center/user-guide/baseline-check
基线检查-功能原理介绍
基线 检查功能通过配置不同的基线检查策略,可以帮助您快速对服务器进行批量扫描,发现包括系统、账号权限、数据库、弱口令 、等级保护合规配置等存在的风险点,并提供修复建议和一键修复功能。支持检测的内容详情,请参见基线检查内容。
策略概述
策略包含了云安全中心对基线的检测规则。云安全中心提供三种类型的策略:默认策略、标准策略和自定义策略。
下表为您介绍默认策略、标准策略、自定义策略支持的基线检查类型、包含的基线数量及其支持的版本和应用场景。
策略类型 | 支持的版本 | 说明 | 应用场景 |
默认策略 | 高级版、企业版、旗舰版 | 该类型策略包含70+基线检查项,仅支持编辑策略的开始时间和生效服务器。支持以下基线类型: 未授权访问 容器安全 最佳安全实践 弱口令 说明:高级版仅支持弱口令检查。 | 默认策略为云安全中心默认执行的基线检查策略,您购买云安全中心高级版、企业版或旗舰版后,云安全中心将使用默认策略每隔一天检查一次您阿里云账号下的所有资产,每次在00:00~06:00或您修改后的时间进行检查。默认策略仅支持未授权访问、最佳安全实践、容器安全和弱口令类型的基线检查项。 |
标准策略 | 企业版、旗舰版 | 该类型策略包含120+基线检查项,支持编辑策略配置项。支持以下基线类型: 未授权访问 等保合规 最佳安全实践 容器安全 CIS合规 弱口令 | 标准策略相比默认策略增加了等保合规基线检查类型,其他基线类型也增加了更多的基线,且支持编辑策略的配置项。您可为资产自行配置符合业务场景需要的基线检查策略。 |
自定义策略 | 企业版、旗舰版 | 该类型策略包含50+基线检查项,支持编辑策略配置项和部分基线的参数。支持操作系统自定义基线。 | 自定义策略用于检查您的资产在操作系统自定义基线的配置上是否存在风险。您可为资产自行配置基线检查策略,并可按照业务需求修改基线的参数,使得基线检查策略更加符合您的业务场景。 |
基线检查内容说明
详见 基线检查内容
1、容器安全实现方案
Vesta: 一款快速镜像扫描以及容器基线检查工具 - FreeBuf网络安全行业门户
容器安全策略规则和规则模板_容器服务 Kubernetes 版 ACK-阿里云帮助中心
2、等保合规
ACK基于Alibaba Cloud Linux的等保加固使用说明以及如何为ACK集群开启等保加固、配置基线检查策略。_容器服务 Kubernetes 版 ACK-阿里云帮助中心
4、华为云
健康诊断
云容器引擎CCE服务提供一键集群诊断能力,包括集群诊断、节点诊断、工作负载诊断、核心插件诊断和外部依赖诊断,可以辅助您定位集群中出现的问题。本文介绍如何在集群中使用集群诊断功能。
功能入口
- 登录CCE控制台,单击集群名称进入集群详情页。
- 在左侧导航栏中选择“监控中心”,单击“健康诊断”页签。
配置定时巡检规则
在“健康诊断”页面右上角打开“定时巡检”开关,并配置定时巡检启动的时间。集群将在指定时间自动开始集群巡检任务。单个集群,每天仅支持配置一个定时巡检时间。
手动发起诊断
当您初次使用健康诊断时,单击“马上诊断”,集群将开始执行诊断。诊断结束后,页面将自动刷新并展示诊断结果,其中无风险项将自动隐藏。
健康诊断将针对不同维度的巡检项,归纳Kubernetes中常见的问题,并提供相应的修复建议。用户可以单击“诊断详情”查看具体诊断项的详细信息以及存在异常的资源。
支持的巡检项
巡检维度 | 集群巡检场景 | 巡检项 |
集群 | 集群资源规划能力 | 集群Master节点是否高可用 |
集群CPU的Request水位是否超过80% | ||
集群CPU的Limit水位是否超过150% | ||
集群内存的Request水位是否超过80% | ||
集群内存的Limit水位是否超过150% | ||
集群版本是否超期 | ||
集群运维能力 | 集群kube-prometheus-stack插件状态是否正常 | |
集群log-agent插件状态是否正常 | ||
集群npd插件状态是否正常 | ||
集群配置 | 安全组配置是否正确 | |
核心插件 | coredns插件状态 | coredns近24小时CPU使用率最大值是否超过80% |
coredns近24小时内存使用率最大值是否超过80% | ||
coredns近24小时是否存在域名解析失败的请求 | ||
coredns近24小时P99请求时延是否超过5s | ||
coredns插件状态 | ||
everest插件状态 | everest插件状态 | |
everest近24小时CPU使用率最大值是否超过80% | ||
everest近24小时内存使用率最大值是否超过80% | ||
kube-prometheus-stack插件状态 | kube-prometheus-stack近24小时CPU使用率最大值是否超过80% | |
kube-prometheus-stack近24小时内存使用率最大值是否超过80% | ||
kube-prometheus-stack插件状态 | ||
kube-prometheus-stack近24小时是否出现OOM | ||
kube-prometheus-stack在Server部署模式下,prometheus-server的PVC使用率是否超过80% | ||
log-agent插件状态 | log-agent插件状态 | |
LTS日志组、日志流是否创建成功 | ||
LTS日志组结构化是否创建成功 | ||
autoscaler插件状态 | 集群在开启节点池弹性扩缩容条件下,autoscaler插件状态是否可用 | |
节点 | 节点状态 | 节点状态是否就绪 |
节点状态不可调度 | ||
节点kubelet状态 | ||
节点配置 | 节点内存的Requset是否超过80% | |
节点CPU的Request是否超过80% | ||
节点内存的Limit是否超过150% | ||
节点CPU的Limit是否超过150% | ||
节点资源水位诊断 | 节点24小时内CPU使用率最大值是否超过80% | |
节点24小时内内存使用率最大值是否超过80% | ||
节点磁盘使用率是否超过80% | ||
节点PID(进程ID)使用量是否正常 | ||
节点24小时内是否发生OOM事件 | ||
负载 | Pod状态 | Pod状态检查 |
Pod负载状态 | Pod在24小时内是否发生OOM | |
Pod的24小时内CPU使用率最大值是否超过80% | ||
Pod的24小时内内存使用率最大值是否超过80% | ||
Pod配置 | Pod中的容器是否配置Request | |
Pod中的容器是否配置Limit | ||
Pod探针配置 | Pod中的容器是否配置存活探针 | |
Pod中的容器是否配置就绪探针 | ||
外部依赖 | 租户节点资源配额 | 租户云硬盘配额使用率是否超过90% |
租户ECS配额使用率是否超过90% |
5 、基线策略实现方式-开源OPA
Open Policy Agent(OPA)是一款开源的通用策略规则引擎工具,提供Policy as Service服务,通过统一标准的高级声明式查询语言Rego定义规则,基于规则和输入数据输出判定结果:
Open Policy Agent (OPA) 的服务工作流程主要涉及以下几个步骤:
- 请求、事件等:这是工作流程的开始,可以是任何形式的输入,如 HTTP 请求、Kubernetes Admission Review 对象等。
2. 服务:服务接收到输入后,会根据策略和数据做出决策。这个服务可以是 OPA 本身,也可以是集成了 OPA 的应用、服务或工具。
3. 决策Decision:服务做出的决策可以是任何 JSON 值。这个决策会被返回给请求的发送者。
4. 策略:策略是用 Rego 语言编写的,用于指导服务如何做出决策。
5. 数据:数据以 JSON 格式存储,用于辅助策略做出决策。
5.1 OPA示例代码解释
1.受信任的镜像仓库
此策略很简单,但功能强大:仅允许从受信任的镜像仓库中拉取容器镜像。
这是因为,从网上随意拉取未知镜像会带来风险,例如恶意软件。通过确保镜像仅来自受信任的镜像仓库,你可以紧密控制镜像安全,减轻软件被攻击的风险,随之提高集群的整体安全性。
// 这个策略会拒绝任何试图在Pod中使用非"hooli.com/"镜像仓库的镜像的请求,
// 并生成一个错误消息,指出镜像来自不受信任的镜像仓库。
package kubernetes.validating.images
// deny[msg]这是一个规则,当它的主体为真时,它将生成一个或多个被拒绝的消息
deny[msg] {
some i //迭代,用于遍历Pod中的所有容器
input.request.kind.kind == "Pod" //条件,检查请求的资源类型是否为"Pod"
image := input.request.object.spec.containers[i].image //容器的镜像名称赋值给变量"image"
not startswith(image, "hooli.com/") //条件,检查镜像名称是否以"hooli.com/"开头
msg := sprintf("Image '%v' comes from untrusted registry", [image]) //生成一个错误消息,指出镜像来自不受信任的镜像仓库
}
2.安全的标签
该策略要求所有Kubernetes资源都包含指定的标签,并使用适当的格式。由于标签确定了Kubernetes对象和策略的分组,包括工作负载可以在何处运行,以及哪些资源可以发送流量,因此错误的标签会导致生产中出现难以置信的部署和运维问题。
此外,由于没有访问权限来控制标签的应用方式(增删改),因此集群缺乏基本的安全性。手动输入标签的危险会使错误会蔓延,特别是因为标签在Kubernetes中既非常灵活又非常强大。
// 这个策略会拒绝任何试图在没有"costcenter"标签,
// 或者"costcenter"标签的值不以"cccode-"开头的资源的请求,并生成一个错误消息。
package kubernetes.validating.existence
// deny[msg]是一个规则,当它的主体为真时,它将生成一个或多个被拒绝的消息。
deny[msg] {
// 检查请求的资源是否有一个名为"costcenter"的标签。如果没有,这个条件就为真,规则就会生成一个错误消息。
not input.request.object.metadata.labels.costcenter
// 生成一个错误消息,指出每个资源都必须有一个"costcenter"标签。
msg := "Every resource must have a costcenter label"
}
deny[msg] {
// 将"costcenter"标签的值赋值给变量"value"
value := input.request.object.metadata.labels.costcenter
// 检查"value"是否以"cccode-"开头。如果不是,这个条件就为真,规则就会生成一个错误消息
not startswith(value, "cccode-")
// 生成一个错误消息,指出"costcenter"标签的值必须以"cccode-"开头
msg := sprintf("Costcenter code must start with `cccode-`; found `%v`", [value])
}
3.禁止使用特权模式
此策略,确保默认情况下容器不能在特权模式下运行。
通常,你要避免在特权模式下运行容器,因为它提供对主机资源和内核功能(包括禁用主机级保护的功能)的访问。
尽管容器在某种程度上是隔离的,但它们最终共享同一内核。这意味着,如果特权容器遭到破坏,则它可能成为破坏整个系统的起点。如果想要在特权模式下运行镜像-仅确保这些时间是例外,而不是常规。
// 这个策略会拒绝任何试图以特权模式运行容器的请求,并生成一个错误消息。
package kubernetes.validating.privileged
deny[msg] {
some c //遍历所有的容器
input_container[c] //检查容器"c"是否存在
c.securityContext.privileged //检查容器"c"是否以特权模式运行。如果是,这个条件就为真,规则就会生成一个错误消息。
// 生成一个错误消息,指出容器"c"不应该以特权模式运行
msg := sprintf("Container '%v' should not run in privileged mode.", [c.name])
}
// 规则,用于提取普通容器,
input_container[container] {
container := input.request.object.spec.containers[_]
}
// 规则,用于提取初始化容器。
input_container[container] {
container := input.request.object.spec.initContainers[_]
}
在Kubernetes中,初始化容器(Init Container)是一种特殊类型的容器,用于在应用容器运行之前执行一些预处理任务或初始化操作。通过使用初始化容器,可以确保应用容器在正常运行之前,其依赖项和预处理任务已经完成。
4.定义和控制流量入口
流量入口策略,允许你根据需要公开特定的服务,或者根据需要不公开某些服务。
下面的策略示例,可防止不同名称空间中的Ingress对象共享相同的主机名。这就可以确保新的工作负载会从现有工作负载中“窃取”互联网流量,不然带来一系列负面影响,如数据泄露等等。
//这段代码的目的是确保在 Kubernetes 集群中不会创建具有相同主机名的多个 Ingress 对象。如果试图创建具有相同主机名的 Ingress 对象,OPA 将拒绝请求并返回一个错误消息。这有助于防止可能的路由冲突和安全问题。
package kubernetes.validating.ingress
deny[msg] {
is_ingress // 辅助规则,用于检查输入的 Kubernetes 对象是否为 Ingress
input_host := input.request.object.spec.rules[_].host //从输入的 Ingress 对象中提取主机名
// 对所有可能的 other_ns 和 other_name 的组合进行迭代。这里的 other_ns 和 other_name 分别代表 Kubernetes 集群中其他 Ingress 对象的命名空间和名称
some other_ns, other_name
other_host :=
data.kubernetes.ingresses[other_ns][other_name].spec.rules[_].host //从集群中的其他 Ingress 对象中提取主机名。
[input_ns, input_name] != [other_ns, other_name] //确保不会将输入的 Ingress 对象与其自身进行比较。
input_host == other_host //如果输入的 Ingress 对象和集群中的其他 Ingress 对象具有相同的主机名,那么这个条件就会满足
//错误消息,指出输入的 Ingress 对象与哪个 Ingress 对象发生了冲突
msg := sprintf("Ingress host conflicts with ingress %v/%v", [other_ns, other_name])
}
//从输入的 Ingress 对象中提取命名空间
input_ns = input.request.object.metadata.namespace
// 从输入的 Ingress 对象中提取名称
input_name = input.request.object.metadata.name
// 如果这三个条件都满足,那么 is_ingress 规则就会返回 true,表示输入的 Kubernetes 对象是一个 Ingress 对象。否则,is_ingress 规则将返回 false,表示输入的 Kubernetes 对象不是一个 Ingress 对象。
is_ingress {
input.request.kind.kind == "Ingress" //检查输入的 Kubernetes 对象的种类是否为 “Ingress”
input.request.kind.group == "extensions"//检查输入的 Kubernetes 对象的 API 组是否为“extensions”。
input.request.kind.version == "v1beta1" //检查输入的 Kubernetes 对象的 API 版本是否为 “v1beta1”。
}
5.定义和控制流量出口
防止创建允许所有出站流量的网络策略,或者允许出站流量超出特定 IP 范围的网络策略。
//这段代码的目的是确保在 Kubernetes 集群中不会创建允许所有出站流量的网络策略,
//或者允许出站流量超出特定 IP 范围的网络策略。如果试图创建这样的网络策略,OPA 将拒绝请求并返回一个错误消息。
package kubernetes.validating.egress
allow_list := { // 允许的 IP 地址范围列表
"10.10.0.0/16",
"192.168.100.1/32"
}
// 规则,当满足其内部条件时,它将生成一个错误消息 reason
deny[reason] {
network_policy_allows_all_egress // 辅助规则,用于检查网络策略是否允许所有出站流量
reason := "Network policy allows access to any IP address."
}
//这段代码的目的是防止创建允许出站流量超出特定 IP 范围的网络策略。
//如果试图创建这样的网络策略,OPA 将拒绝请求并返回一个错误消息。
deny[reason] {
count(allow_list) > 0 //允许的 IP 地址列表 allow_list 不为空
input.request.kind.kind == "NetworkPolicy" //输入的 Kubernetes 对象的种类是 “NetworkPolicy”
input.request.object.spec.policyTypes[_] == "Egress"//网络策略包含 “Egress” 类型的策略
ipBlock := input.request.object.spec.egress[_].to[_].ipBlock //从出站规则中提取 IP 块(一组 IP 地址)
// 检查 IP 块是否不在允许的 IP 地址范围列表中。如果 IP 块不在允许的 IP 地址范围列表中,那么这个条件就会满足。
not any({t | t := net.cidr_contains(allow_list[_], ipBlock.cidr)})
// 如果所有条件都满足,那么将生成一个错误消息,指出网络策略允许出站流量超出允许的 IP 地址范围
reason := "Network policy allows egress traffic outside of allowed IP ranges."
}
// 如果所有这些条件都满足,那么 network_policy_allows_all_egress 规则就会返回 true,
// 表示网络策略允许所有出站流量
network_policy_allows_all_egress {
input.request.kind.kind == "NetworkPolicy" //检查输入的 Kubernetes 对象的种类是否为 “NetworkPolicy”。
input.request.object.spec.policyTypes[_] == "Egress" //检查网络策略是否包含 “Egress” 类型的策略。
egress := input.request.object.spec.egress[_] //从网络策略中提取出站规则
// 检查出站规则是否没有定义 to 字段。在 Kubernetes 网络策略中,to 字段用于指定出站流量的目标。
// 如果没有定义 to 字段,那么就意味着允许所有出站流量
not egress.to
}
6 、Kubernetes 设计的巡检工具-kubeEye
KubeEye 是为 Kubernetes 设计的巡检工具,用于发现 Kubernetes 资源(使用 OPA )、集群组件、集群节点(使用Node-Problem-Detector)等配置是否符合最佳实践,对于不符合最佳实践的,将给出修改建议。
KubeEye 支持自定义巡检规则、插件安装,通过 KubeEye Operator 能够使用 web 页面的图形化展示来查看巡检结果以及给出修复建议。
架构图
KubeEye 通过 Kubernetes API 获取资源详情,通过巡检规则和插件检查获取到的资源配置,并生成诊断结果,详见架构图。
KubeEye 能为您做什么
- KubeEye 根据 Kubernetes 最佳实践来检查集群资源,确保集群保持最佳配置,稳定运行。
- KubeEye 可以帮助您发现集群控制平面问题,包括 kube-apiserver、kube-controller-manager、etcd 等。
- KubeEye 可以帮助您检测各种集群节点问题,包括内存、CPU、磁盘压力、意外的内核错误日志等。
检查项
是/否 | 检查项 | 描述 | 级别 |
✅ | PrivilegeEscalationAllowed | 允许特权升级 | 紧急 |
✅ | CanImpersonateUser | role/clusterrole 有伪装成其他用户权限 | 警告 |
✅ | CanDeleteResources | role/clusterrole 有删除 kubernetes 资源权限 | 警告 |
✅ | CanModifyWorkloads | role/clusterrole 有修改 kubernetes 资源权限 | 警告 |
✅ | NoCPULimits | 资源没有设置 CPU 使用限制 | 紧急 |
✅ | NoCPURequests | 资源没有设置预留 CPU | 紧急 |
✅ | HighRiskCapabilities | 开启了高危功能,例如 ALL/SYS_ADMIN/NET_ADMIN | 紧急 |
✅ | HostIPCAllowed | 开启了主机 IPC | 紧急 |
✅ | HostNetworkAllowed | 开启了主机网络 | 紧急 |
✅ | HostPIDAllowed | 开启了主机PID | 紧急 |
✅ | HostPortAllowed | 开启了主机端口 | 紧急 |
✅ | ImagePullPolicyNotAlways | 镜像拉取策略不是 always | 警告 |
✅ | ImageTagIsLatest | 镜像标签是 latest | 警告 |
✅ | ImageTagMiss | 镜像没有标签 | 紧急 |
✅ | InsecureCapabilities | 开启了不安全的功能,例如 KILL/SYS_CHROOT/CHOWN | 警告 |
✅ | NoLivenessProbe | 没有设置存活状态检查 | 警告 |
✅ | NoMemoryLimits | 资源没有设置内存使用限制 | 紧急 |
✅ | NoMemoryRequests | 资源没有设置预留内存 | 紧急 |
✅ | NoPriorityClassName | 没有设置资源调度优先级 | 通知 |
✅ | PrivilegedAllowed | 以特权模式运行资源 | 紧急 |
✅ | NoReadinessProbe | 没有设置就绪状态检查 | 警告 |
✅ | NotReadOnlyRootFilesystem | 没有设置根文件系统为只读 | 警告 |
✅ | NotRunAsNonRoot | 没有设置禁止以 root 用户启动进程 | 警告 |
✅ | CertificateExpiredPeriod | 将检查 ApiServer 证书的到期日期少于30天 | 紧急 |
✅ | EventAudit | 事件检查 | 警告 |
✅ | NodeStatus | 节点状态检查 | 警告 |
✅ | DockerStatus | docker 状态检查 | 警告 |
✅ | KubeletStatus | kubelet 状态检查 | 警告 |
参考资料
基于开源OPA实现Kubernetes资源安全合规基线检查 | 运维进阶 - 墨天轮
借助OPA实施Kubernetes的5大准入控制策略_Kubernetes中文社区
kubernetes OPA(open policy agent)
Open Policy Agent(OPA) 入门实践