如何使用Kubescape保护Kubernetes

如何使用 Kubescape 保护 Kubernetes

作者：科技狠活与软件技术 2022-12-06 17:32:18

云计算

云原生将对云原生环境中的渐进式交付选项进行分析，以探索如何在 Kubernetes 环境中添加此增强功能。

Kubernetes 功能强大，但也很复杂。很容易让集群容易受到攻击。第一道防线是自动安全检查。

Kubernetes 不断增长。根据最近的一项调查，它在开发人员中的采用率在 2021 年增长了惊人的 67%。企业正在迁移到 Kubernetes 以享受云原生应用程序的灵活性和可扩展性。

Kubernetes 对企业的价值毋庸置疑，但它是有代价的：由于其复杂性，很容易使集群容易受到攻击。企业知道这一点；在其Kubernetes 安全状况报告中，红帽表示，59% 的受访者认为容器安全是一种威胁。

在持续集成和交付 (CI/CD) 中安装自动化安全检查，这是所有代码在进入生产之前必须通过的唯一地方，是开始防御威胁的最佳方式，而 Kubescape 可以帮助您做到这一点。

在本文中，我们将学习如何在我们的 CI/CD 管道中运行Kubescape以在威胁部署之前检测它们。

进入 Kubescape

Kubescape 是 Kubernetes 的开源安全检查工具。该工具由ARMO开发，可以扫描 Kubernetes 集群、检查容器并检测不安全的部署。

即使拥有多年运行 Kubernetes 的经验，企业仍在学习保护集群的来龙去脉。2019 年，一个加密货币矿工以某种方式进入了 JW Player 的集群，并开始使用他们的资源进行挖矿。开发人员发现原因是权限提升的容器。在这种情况下，如果 JW Player 的团队在他们的部署过程中使用了 Kubescape，那么在部署之前就会检测到提升的容器权限。

Kubescape 基于 NSA、CISA 和 Microsoft 的安全指南实施了 70 多种控制。这些控件分为四类，称为框架：

NSA：遵循NSA Kubernetes 强化指南。这是一个专注于应用程序安全性的自上而下的框架。
MITRE：遵循 Microsoft 的MITRE Framework。MITRE 主要关注保护 Kubernetes 基础设施。
ArmoBest：ARMO 框架由 Kubescape 背后的同一批人维护。该框架试图覆盖 MITRE 和 NSA 框架之间的盲点。
DevOpsBest：一个最小的框架，涵盖了基础设施和应用程序安全性的最基本点。

默认情况下，Kubescape 将运行所有检查并打印出每个框架的风险级别。

确保 Kubernetes 安全的完整性控制

我们可以从两个角度处理 Kubernetes 安全性。在最基本的层面上，有一个集群必须适当地加固以抵御攻击——这对于自我管理和本地安装尤为重要。在应用程序级别，我们必须检查部署是否遵循最佳实践，并且不要留下可利用的漏洞。

使用 Kubescape 保护 Kubernetes

我们将看到的第一组控制涉及保护部署清单，Kubernetes 使用它来描述一组资源的所需状态。通过分析这个清单，Kubescape 可以检测到以下问题：

在容器内运行的不安全 SSH 服务。
容器启动命令中的sudo-commands。
以 root 身份运行容器或使用过多的功能
在没有父 ReplicaSet 的情况下运行 Pod。
Pod 占用所有可用的 CPU 和内存。

您可以在ArmoSec 文档中查看所有控件和可用框架。每个控制都与从低到严重的风险级别相关联。在扫描过程结束时，Kubescape 会计算从 0%（非常安全）到 100%（不安全）的风险评分。

扫描 Kubernetes 清单

让我们看看 Kubescape 的实际应用。对于本教程的这一部分，任何有效的 Kubernetes 清单都可以。作为示例，我将使用此存储库中的部署清单：

信号量-demo-nodejs-k8s

扫描 Kubernetes 清单文件的基本命令如下所示：

$ kubescape scan deployment.yml
Controls: 31 (Failed: 14, Excluded: 0, Skipped: 0)
+----------+----------------------------------------+------------------+--------------------+---------------+--------------+
| SEVERITY | CONTROL NAME | FAILED RESOURCES | EXCLUDED RESOURCES | ALL RESOURCES | % RISK-SCORE |
+----------+----------------------------------------+------------------+--------------------+---------------+--------------+
| High | Resources CPU limit and request | 1 | 0 | 1 | 100% |
| High | Resources memory limit and request | 1 | 0 | 1 | 100% |
| Medium | Allow privilege escalation | 1 | 0 | 1 | 100% |
| Medium | CVE-2022-0492-cgroups-container-escape | 1 | 0 | 1 | 100% |
| Medium | Configured liveness probe | 1 | 0 | 1 | 100% |
| Medium | Images from allowed registry | 1 | 0 | 1 | 100% |
| Medium | Ingress and Egress blocked | 1 | 0 | 1 | 100% |
| Medium | Linux hardening | 1 | 0 | 1 | 100% |
| Medium | Non-root containers | 1 | 0 | 1 | 100% |
| Low | Configured readiness probe | 1 | 0 | 1 | 100% |
| Low | Immutable container filesystem | 1 | 0 | 1 | 100% |
| Low | K8s common labels usage | 1 | 0 | 1 | 100% |
| Low | Label usage for resources | 1 | 0 | 1 | 100% |
| Low | Resource policies | 1 | 0 | 1 | 100% |
+----------+----------------------------------------+------------------+--------------------+---------------+--------------+
| | RESOURCE SUMMARY | 1 | 0 | 1 | 40.27% |
+----------+----------------------------------------+------------------+--------------------+---------------+--------------+

FRAMEWORKS: MITRE (risk: 0.00), AllControls (risk: 40.27), ArmoBest (risk: 36.73), DevOpsBest (risk: 63.16), NSA (risk: 36.99)在不选择特定框架的情况下，Kubescape 评估所有控件。您可以通过添加framework. 例如：

$ kubescape scan framework DevOpsBest deployment.yml

您还可以通过列出其ID 代码来运行单个控件。

$ kubescape scan control C-0076,C-0004 deployment.yml

如您所见，Kubescape 输出一个包含控件、它们的状态和最终风险评分的表格。

健全性检查 Kubernetes 集群

由于 Kubernetes 的默认配置导致了大约 47% 的安全问题，因此大多数自我管理的集群都存在风险。Kubescape 可以检查正在运行的集群配置，检测潜在问题并提供修复建议。以下是该工具可以执行的一些集群级别检查：

识别不安全的工作节点。
检查暴露的和不安全的接口，例如管理仪表板。
检测集群是否受到任何已知 CVE 的影响。
检测缺失的网络策略。
查找在没有 TLS 身份验证的情况下运行的 Kubelet 客户端。

要扫描集群，请使用以下命令：

$ kubescape scan
Controls: 57 (Failed: 35, Excluded: 0, Skipped: 5)
+----------+---------------------------------------------------------------------+------------------+--------------------+---------------+--------------+
| SEVERITY | CONTROL NAME | FAILED RESOURCES | EXCLUDED RESOURCES | ALL RESOURCES | % RISK-SCORE |
+----------+---------------------------------------------------------------------+------------------+--------------------+---------------+--------------+
| Critical | Data Destruction | 17 | 0 | 67 | 25% |
| Critical | Disable anonymous access to Kubelet service | 0 | 0 | 0 | skipped* |
| Critical | Enforce Kubelet client TLS authentication | 0 | 0 | 0 | skipped* |
| High | Cluster-admin binding | 1 | 0 | 67 | 1% |
| High | List Kubernetes secrets | 10 | 0 | 67 | 15% |
| High | Privileged container | 1 | 0 | 6 | 14% |
| High | Resources CPU limit and request | 6 | 0 | 6 | 100% |
| High | Resources memory limit and request | 5 | 0 | 6 | 69% |
| High | Workloads with Critical vulnerabilities exposed to external traffic | 0 | 0 | 0| skipped** |
| High | Workloads with RCE vulnerabilities exposed to external traffic | 0 | 0 | 0 | skipped** |
| High | Workloads with excessive amount of vulnerabilities | 0 | 0 | 0 | skipped** |
| High | Writable hostPath mount | 3 | 0 | 6 | 42% |
| Medium | Access container service account | 2 | 0 | 2 | 100% |
| Medium | Allow privilege escalation | 5 | 0 | 6 | 69% |
| Medium | Allowed hostPath | 3 | 0 | 6 | 42% |
| Medium | Automatic mapping of service account | 4 | 0 | 8 | 57% |
| Medium | CVE-2022-0492-cgroups-container-escape | 1 | 0 | 6 | 31% |
| Medium | Cluster internal networking | 5 | 0 | 5 | 100% |
| Medium | Configured liveness probe | 1 | 0 | 6 | 14% |
| Medium | CoreDNS poisoning | 3 | 0 | 67 | 4% |
| Medium | Delete Kubernetes events | 3 | 0 | 67 | 4% |
| Medium | Exec into container | 1 | 0 | 67 | 1% |
| Medium | HostNetwork access | 5 | 0 | 6 | 69% |
| Medium | HostPath mount | 4 | 0 | 6 | 56% |
| Medium | Ingress and Egress blocked | 6 | 0 | 6 | 100% |
| Medium | Linux hardening | 1 | 0 | 6 | 14% |
| Medium | Mount service principal | 4 | 0 | 6 | 56% |
| Medium | Namespace without service accounts | 4 | 0 | 7 | 57% |
| Medium | Network mapping | 5 | 0 | 5 | 100% |
| Medium | No impersonation | 1 | 0 | 67 | 1% |
| Medium | Non-root containers | 6 | 0 | 6 | 100% |
| Medium | Portforwarding privileges | 1 | 0 | 67 | 1% |
| Low | Audit logs enabled | 1 | 0 | 1 | 100% |
| Low | Configured readiness probe | 4 | 0 | 6 | 56% |
| Low | Immutable container filesystem | 5 | 0 | 6 | 69% |
| Low | K8s common labels usage | 6 | 0 | 6 | 100% |
| Low | Label usage for resources | 2 | 0 | 6 | 44% |
| Low | PSP enabled | 1 | 0 | 1 | 100% |
| Low | Resource policies | 6 | 0 | 6 | 100% |
| Low | Secret/ETCD encryption enabled | 1 | 0 | 1 | 100% |
+----------+---------------------------------------------------------------------+------------------+--------------------+---------------+--------------+
| | RESOURCE SUMMARY | 37 | 0 | 90 | 16.62% |
+----------+---------------------------------------------------------------------+------------------+--------------------+---------------+--------------+

FRAMEWORKS: MITRE (risk: 12.58), AllControls (risk: 16.62), ArmoBest (risk: 13.44), DevOpsBest (risk: 40.27), NSA (risk: 17.92)

添加--enable-host-scan以在每个节点上安装诊断容器。这给出了更详细的结果，如下所示：

$ kubescape scan framework DevOpsBest --enable-host-scan
Controls: 11 (Failed: 6, Excluded: 0, Skipped: 0)
+----------+------------------------------------+------------------+--------------------+---------------+--<

标题名称：如何使用Kubescape保护Kubernetes
标题网址：http://www.mswzjz.cn/qtweb/news39/330589.html

攀枝花网站建设、攀枝花网站运维推广公司-贝锐智能，是专注品牌与效果的网络营销公司；服务项目有等

声明：本网站发布的内容（图片、视频和文字）以用户投稿、用户转载内容为主，如果涉及侵权请尽快告知，我们将会在第一时间删除。文章观点不代表本网站立场，如需处理请联系客服。电话：028-86922220；邮箱：631063699@qq.com。内容未经允许不得转载，或转载时需注明来源：贝锐智能

贝锐智能技术为您推荐以下文章