Hello folks，我是 Luga，今天我们来分享一下与云原生安全相关的话题，即面向“DevOps”的 Kubernetes 最佳安全实践。
如今，DevOps 和云原生理念事实上已成为各大企业和组织的标准实践。因此，软件开发人员及运维人员越来越希望利用这些更新的计算范例来加快上市时间，同时保持高可用性并降低资源成本。Kubernetes 就是这样一种平台，组织希望采用这种平台来加快软件交付速度。
然而，不幸的是，在没有适当安全措施的情况下采用 Kubernetes 会增加我们业务的网络攻击风险。容器服务的分布式特性使我们的环境面临更多的攻击窗口。但是，若我们通过适当的安全协议和最佳实践，那么可以避免所构建的 Kubernetes Cluster 和应用程序免受这些潜在威胁，并确保我们的核心数据处于安全和机密状态。
— 1—
Kubernetes 安全重要性
据 ionir 的一项调查结果显示，大约 60% 的受访者正在或已經在 Kubernetes 平台上运行不同種類的应用程序，50% 的受访者表示他们计划在未来 12 个月内也將其業務遷移至 Kubernetes 平台。此外，Red Hat 的《2022 年 Kubernetes 安全状况》调查报告指出，在 Kubernetes 部署方面，78% 的受访者选择 DevSecOps 作为他们的首選解决方案。
在深入探讨 Kubernetes 安全性的细节之前，让我们先看看这些安全协议背后的概念。众所周知，Kubernetes 之所以能够如此安全，无非是因为它基于与主机操作系统完全隔离的 Linux 容器环境。即意味着如果攻击者想要尝试破坏我们所构建的 Kubernetes Cluster 平台，他们将只能够访问容器，而无法进入主机操作系统的其他部分。基于这种隔离特性，使得攻击者需要单独破坏集群中运行的每个容器才能访问或修改敏感数据，因此，导致攻击者在未经授权的情况下访问 Kubernetes Cluster 内的数据变得更加困难（如果不是不可能的话）。
诚然， Kubernetes 为现代组织提供了诸多好处，并带来了较大收益，然而，我們需要注意的是，作为一种软件产品，这也意味着 Kubernetes 在某种特定的场景中可能会遭受到网络安全威胁。此外，再加上 Kubernetes 开源特性，使得它可能比商业软件更容易受到更多安全风险的影响。因此，在我们的环境中引入 Kubernetes 之前，我们应当确保有一个安全策略来保护我们的数据免受网络威胁。否则，攻击者可能会在未经授权的情况下访问我们的敏感数据并破坏所规划的业务流程，从而导致重大的经济及名誉受损。
— 2—
Kubernetes 安全最佳实践
接下来，笔者将为大家分享一下 Kubernetes Cluster 安全的一些最佳实践，主要涉及如下不同层面。
使用可信容器镜像
1、容器 Image 的选型
首先，确保我们环境使用的是受信任的容器 Image。在实际的项目活动中，基于大家的“良好”习惯，可能会在网上随意 Pull 所想构建的应用镜像，然而，这些镜像的来源未知，可能会导致将来构建好的容器存在各种风险及漏洞。因此，在团队技术实力不允许的条件下，我们还是尽量使用受信任的开源镜像，毕竟，这些镜像经过安全扫描或认证，降低了在容器中引入恶意代码注入的风险。
当然，若团队技术实力比较雄厚或是行业的龙头，有自己的标准体系，那么，可以基于自身的业务属性进行镜像的分级构建，从所依赖的底层 OS、中间件、第三方支撑组件以及到应用本身等。
2、权限的赋予
此外，在配置容器时应遵循最小权限原则。这意味着尽量减少我们所构建的容器比他们实际需要更多的访问权限。毕竟，这样做会增加违规的风险，因为恶意行为者如果没有权限就无法获得对操作系统的完全访问权限。
权限管理
在实际的系统维护活动中，如何能够减轻资源的管理成本，乃是保护 Kubernetes Cluster 的关键的第一步。许多组织选择为需要集群范围权限的 Kubernetes 创建有限的服务账户。本质上就是为 Kubernetes 中需要集群范围权限的每个组件创建一个特殊的用户帐户以进行资源的合理维护。
Kubernetes 有两类用户：
1、集群用户用于集群的日常管理。他们可以创建 Pod 和 Services，但无权修改 Kubernetes API。
2、经过身份验证的用户使用 Kubernetes API 进行身份验证，并拥有对 Kubernetes API 的完全访问权限。
Kubernetes Cluster 观测
基于云原生生态环境，在实际的业务场景中，我们必须持续性观测所构建的 Kubernetes 工作负载和环境是否存在恶意的活动，以防止这些活动带来以下安全风险及威胁，具体如下：
1、未经授权用户的访问：我们应该能够监控访问所构建的 Kubernetes Cluster 的用户的资源信息，例如，IP 地址等。理想情况下，这应该扩展到容器本身。这使我们可以查看访问的容器的请求是否是授权用户。
2、API 滥用：若我们正在使用 Kubernetes 的 API，那么，应该监控 API 调用以确保恶意行为者不会滥用我们的 API 来破坏所构建的 Kubernetes Cluster。这可能包括监控来自未授权 IP 地址的 API 调用、失败的 API 调用或比预期时间更长的 API 调用等。
3、数据泄露：除上述所述的 2 种风险之外，基于业务特性，我们还应该监控 Kubernetes Cluster 内的数据泄露问题，例如，可能涉及异常文件活动的监视、对敏感数据的意外和随机访问或异常网络流量。
CI/CD 中集成安全工具
Kubernetes 安全工具/平台（例如 Kubescape、Datree、Trivy 等）可以帮助我们发现所编写的 Yaml 文件和 Cluster 中的安全问题和漏洞。运维、开发人员需要有一种方法将这些工具集成到 CI/CD 管道中。
引入 GitOps
基于 GitOps ，使得我们在不同的场景中能够轻而易举地解决各种安全问题。以 Git 作为主要工具，一切都可以追溯，让观测变得更为容易。将 CI/CD 工具链与 GitOps 方法结合使用对于确保 Kubernetes 部署安全并在整个组织中维护标准方法至关重要。让我们深入了解如何实现它。
— 3 —
Kubernetes 安全扫描工具
针对上述所述的 Kubernetes 安全工具/平台，让我们来了解一下每个工具的作用以及它在管道中所能检测到的具体内容。
Kubescape
作为一个 K8s 开源工具，Kubescape 能够提供 Kubernetes 单一管理平台，包括风险分析、安全合规、RBAC 可视化工具和图像漏洞扫描。Kubescape 工具能够扫描 K8s 集群、YAML 文件和 HELM 图表，根据多个框架（如 NSA-CISA、MITRE ATT & CK®）检测错误配置、软件漏洞和早期 RBAC（基于角色的访问控制）违规 CI/CD 管道，即时计算风险评分并显示随时间变化的风险趋势。
从本质上讲，Kubescape 主要扫描 Kubernetes Cluster 并展示不符合安全标准的 YAML 文件，具体如下所示：
+----------+----------------------------------------+---------------------------------------+-------------------------------------------------------------------------------------+ | SEVERITY | CONTROL NAME | DOCS | ASSISTANT REMEDIATION | +----------+----------------------------------------+---------------------------------------+-------------------------------------------------------------------------------------+ | High | Apply Security Context to Your | https://hub.armosec.io/docs/cis-5-7-3 | spec.template.spec.containers[0].securityContext.readOnlyRootFilesystem=true | | | Pods and Containers | | spec.template.spec.containers[0].securityContext.runAsNonRoot=true | | | | | spec.template.spec.containers[0].securityContext.allowPrivilegeEscalation=false | | | | | spec.template.spec.containers[0].securityContext.capabilities.drop=NET_RAW | | | | | spec.template.spec.containers[0].securityContext.seLinuxOptions=YOUR_VALUE | | | | | spec.template.spec.containers[0].securityContext.seccompProfile=YOUR_VALUE | +----------+----------------------------------------+---------------------------------------+-------------------------------------------------------------------------------------+ | Medium | Allow privilege escalation | https://hub.armosec.io/docs/c-0016 | spec.template.spec.containers[0].securityContext.allowPrivilegeEscalation=false | + +----------------------------------------+---------------------------------------+-------------------------------------------------------------------------------------+ | | …… | | spec.template.spec.containers[0].securityContext.seLinuxOptions=YOUR_VALUE | | | | | spec.template.spec.containers[0].securityContext.capabilities.drop[0]=YOUR_VALUE | + +----------------------------------------+---------------------------------------+-------------------------------------------------------------------------------------+ | | Non-root containers | https://hub.armosec.io/docs/c-0013 | spec.template.spec.containers[0].securityContext.runAsNonRoot=true | | | | | spec.template.spec.containers[0].securityContext.allowPrivilegeEscalation=false | +----------+----------------------------------------+---------------------------------------+-------------------------------------------------------------------------------------+ | Low | Immutable container filesystem | https://hub.armosec.io/docs/c-0017 | spec.template.spec.containers[0].securityContext.readOnlyRootFilesystem=true | + +----------------------------------------+---------------------------------------+-------------------------------------------------------------------------------------+ | | Label usage for resources | https://hub.armosec.io/docs/c-0076 | metadata.labels=YOUR_VALUE | | | | | spec.template.metadata.labels=YOUR_VALUE | +----------+----------------------------------------+---------------------------------------+-------------------------------------------------------------------------------------+
Trivy
作为多合一的开源安全扫描工具，Trivy 是当下云原生生态领域中最流行的开源安全扫描器。基于其可靠、快速且易于使用特性，使得 Trivy 在漏洞查找和 IaC 错误配置、SBOM 发现、云扫描以及 Kubernetes 安全风险等不同场景下广泛应用。
基于此优秀特性，Aqua Trivy 也成为许多流行项目和公司的 DevOps 和安全团队的默认选择扫描仪。用户受益于定期的、高质量的贡献和创新的功能请求。同时，Aqua Trivy 也是 GitLab 代码库、Artifact Hub以及 Harbor 镜像仓库的默认扫描器。除此之外，Aqua Trivy 也已成为 RedHat 认证的扫描组件，其影响力甚广。
其实，从本质上而言，Trivy 则主要扫描我们 Kubernetes Cluster 工作负载中的漏洞情况，具体如下所示：
===================== Total: 1 (HIGH: 1, CRITICAL: 0) ┌──────────┬────────────────┬──────────┬───────────────────┬───────────────┬───────────────────────────────────────────────────────────┐ │ Library │ Vulnerability │ Severity │ Installed Version │ Fixed Version │ Title │ ├──────────┼────────────────┼──────────┼───────────────────┼───────────────┼───────────────────────────────────────────────────────────┤ │ httplib2 │ CVE-2021-21240 │ HIGH │ 0.12.1 │ 0.19.0 │ python-httplib2: Regular expression denial of service via │ │ │ │ │ │ │ malicious header │ │ │ │ │ │ │ https://avd.aquasec.com/nvd/cve-2021-21240 │ └──────────┴────────────────┴──────────┴───────────────────┴───────────────┴───────────────────────────────────────────────────────────┘ Dockerfile (dockerfile) ======================= Tests: 17 (SUCCESSES: 16, FAILURES: 1, EXCEPTIONS: 0) Failures: 1 (HIGH: 1, CRITICAL: 0) HIGH: Last USER command in Dockerfile should not be 'root'
Datree
作为一个开源扫描器，Datree 主要用于检查 Kubernetes Cluster 文件资源是否存在错误配置。通常情况下，Datree 能够通过阻止不符合所预设定的策略的资源来防止配置错误。基于 Datree 内置的各种规则，我们无须担心自己编写策略。毕竟，其内置了多个领域的多种不同规则，主要涉及容器、工作负载、CronJob、网络、安全、弃用、Argo、NSA-hardening-guidelines 等。
除此之外，Datree 还能够用于命令行、Admission Webhook，甚至作为 Kubectl 插件来针对 Kubernetes Cluster 对象运行策略进行扫描。
与上述 2 种不同工具相比而言，Datree 显示我们的 Kubernetes 清单文件中是否存在任何错误配置。具体如下所示：
> File: /Users/leonli/traefik_values.yml [V] YAML validation [X] Kubernetes schema validation ❌ k8s schema validation error: error while parsing: missing 'kind' key Are you trying to test a raw Helm file? To run Datree with Helm - check out the helm plugin README: https://github.com/datreeio/helm-datree [?] Policy check didn't run for this file (Summary) - Passing YAML validation: 1/1 - Passing Kubernetes (1.20.0) schema validation: 0/1 - Passing policy check: 0/1 +-----------------------------------+------------------------------------------------------+ | Enabled rules in policy "Default" | 21 | | Configs tested against policy | 0 | | Total rules evaluated | 0 | | Total rules skipped | 0 | | Total rules failed | 0 | | Total rules passed | 0 | | See all rules in policy | https://app.datree.io/login?t=mMcCiuo14nt2DZx1E7ZhA8 | +-----------------------------------+------------------------------------------------------+
作为部署和扩展应用程序的一种方式，Kubernetes 和容器化正迅速流行起来。然而，随着 DevOps 的普及，安全威胁也随之增加，尤其是在团队没有始终如一地遵循最佳实践的情况下。毕竟，安全是一件有趣的、难以捉摸的事情。
诚然，Kubernetes 是一种用于交付容器化应用程序的流行技术，但扩展 Kubernetes 环境仍具有挑战性，每一个新部署的容器都会增加攻击面。要有效处理 Kubernetes 安全性，我们必须对每个托管容器和应用程序请求具有完整的可见性。Kubernetes 擅长编排，但不擅长安全。对于所有部署，必须采用适当的部署架构和安全最佳实践。
Adiós !
