Kubernetes 不断增长。根据最近的一项调查，它在开发人员中的采用率在 2021 年增长了惊人的 67%。企业正在迁移到 Kubernetes 以享受云原生应用程序的灵活性和可扩展性。
Kubernetes 对企业的价值毋庸置疑，但它是有代价的：由于其复杂性，很容易使集群容易受到攻击。企业知道这一点；在其Kubernetes 安全状况报告中，红帽表示，59% 的受访者认为容器安全是一种威胁。
在持续集成和交付 (CI/CD) 中安装自动化安全检查，这是所有代码在进入生产之前必须通过的唯一地方，是开始防御威胁的最佳方式，而 Kubescape 可以帮助您做到这一点。
在本文中，我们将学习如何在我们的 CI/CD 管道中运行Kubescape以在威胁部署之前检测它们。
进入 KubescapeKubescape 是 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) +—————+——————————————————+—————————+——————————+———————–+———————+ | SEVERITY | CONTROL NAME | FAILED RESOURCES | EXCLUDED RESOURCES | ALL RESOURCES | % RISK–SCORE | +—————+——————————————————+—————————+——————————+———————–+———————+ | High | Resources CPU limit and request | 6 | 0 | 6 | 100% | | High | Resources memory limit and request | 5 | 0 | 6 | 69% | | Medium | Configured liveness probe | 1 | 0 | 6 | 14% | | Low | Configured readiness probe | 4 | 0 | 6 | 56% | | Low | K8s common labels usage | 6 | 0 | 6 | 100% | | Low | Label usage for resources | 2 | 0 | 6 | 44% | +—————+——————————————————+—————————+——————————+———————–+———————+ | | RESOURCE SUMMARY | 6 | 0 | 6 | 40.27% | +—————+——————————————————+—————————+——————————+———————–+———————+ FRAMEWORK DevOpsBest 使用 CI/CD 自动化安全审计那么既然我们已经保护了 Kubernetes 环境，我们如何确保它保持安全呢？我们可以在 CI/CD 管道中嵌入完整性检查，以防止不安全的部署到达我们的系统。
为此，我们将使用 Semaphore 作为 CI/CD 解决方案。如果您不熟悉 Semaphore，请查看导览以了解基础知识。您可以使用免费帐户按照本教程中的所有步骤进行操作。
启动管道。我们将在部署之前添加一些测试。
首先，fork 存储库并切换到fork-and-run分支。然后：
将项目添加到信号量。 编辑管道并单击“部署”以显示持续部署管道。 单击+ 添加块。 打开Prologue，输入Kubescape安装命令：curl -s
https://raw.githubusercontent.com/armosec/kubescape/master/install.sh | /bin/bash 在作业中，添加以下命令。checkout命令克隆 CI 机器中的存储库，以便我们可以访问清单文件 ( deployment.yml) checkoutexport MAX_RISK=40kubescape scan -t “$MAX_RISK” deployment.yml –format junit -o report.xml 安排管道中的作业依赖关系，使新作业先运行。 配置测试报告在本节中，我们将配置测试报告，这是一个可以分析所有 CI/CD 运行的 Kubescape 结果并在统一报告中显示的功能。
打开持续部署管道的Epilogue部分并输入以下行以处理 Kubescape 生成的报告。 [[ -f report.xml ]] && test-results publish report.xml
单击“在作业后添加”并输入以下命令。这将从所有作业收集报告并更新仪表板：1个测试结果生成管道报告
test-results gen-pipeline-report 管道应立即启动。等到 CI 管道中的所有作业都完成后，再单击“升级”按钮。如果风险级别超过设定的阈值（在我们的示例中为 40%，但可以随意调整），管道将失败，阻止部署以保护集群。安装了清单完整性检查的持续部署管道。
完成后，您可以在测试结果选项卡中查看 Kubescape 发现的故障。
测试报告让您深入了解明显的安全问题。
群集Pre-Flight检查保护部署只是解决方案的一半。另一半包括持续检查 Kubernetes 集群本身。Kubescape 可以通过两种互补的方式实现这一点：
在集群上安装 Kubescape 并让它在后台运行。您可以在Armo Cloud门户中查看结果。 在每次部署之前扫描 CI/CD 管道中的集群。因此，让我们更新 CI/CD 管道以运行飞行前检查以确保其部署安全。在此之前，我们需要将 Kubeconfig 文件上传到 Semaphore，以便它可以连接到集群。这意味着我们必须使用其中的文件创建一个秘密。我们称之为秘密kubeconfig。
通过编辑管道并将管道扫描作业添加到我们之前创建的块来完成设置。运行检查的命令如下所示：
checkout export MAX_RISK=40 kubescape scan —exclude–namespaces kube–system,kube–public –t $MAX_RISK —format junit –o report.xml在保存之前，打开秘密部分并启用kubeconfig条目。
将集群扫描作业和 kubeconfig 密码添加到块中。
而已。再次运行管道以检查一切是否正常。
完成所有检查的最终 CI/CD 管道。
结论Kubernetes 是一个流行的大规模运行应用程序的平台，但这也使其成为攻击的主要目标。安全从来都不是事后才加上的东西。这是一个持续的实践，应该被视为软件开发周期每个部分的一个组成部分。该实践的一部分是利用 Kubescape 等工具来保护您的系统。
原文地址：https://www.toutiao.com/article/7172358788774019615/
声明： 猿站网有关资源均来自网络搜集与网友提供，任何涉及商业盈利目的的均不得使用，否则产生的一切后果将由您自己承担！ 本平台资源仅供个人学习交流、测试使用 所有内容请在下载后24小时内删除，制止非法恶意传播，不对任何下载或转载者造成的危害负任何法律责任！也请大家支持、购置正版！ 。本站一律禁止以任何方式发布或转载任何违法的相关信息访客发现请向站长举报，会员发帖仅代表会员个人观点，并不代表本站赞同其观点和对其真实性负责。本网站的资源部分来源于网络，如有侵权烦请发送邮件至：2697268773@qq.com进行处理。