如何让你的 Kubernetes 集群更安全

最近阿里云容器团队与 Palo Alto Networks 的安全团队发现，目前用户自己部署的 Kubernetes 集群中有约 2752 个可能存在安全隐患，比如用户把 Kubernetes 的 API 向所有互联网 IP 地址开放了。其中有超过 120 个 Kubernetes 集群甚至没有启用 API 认证，这导致了所有人都可以对这些不安全 Kubernetes 集群进行访问，读取信息，甚至远程部署恶意容器。这将给用户带来极大的安全风险。

同时，Palo Alto Networks 的 Unit42 的资深研究员 Jay Chan 发现目前全球有超过 1400 个不安全的 Docker 主机，8673 个不安全运行的容器，17927 个有漏洞的镜像和 15229 个不安全的目录挂载。更需要大家引起重视的是，其中 47.7% 在中国。可查看 原文链接 。

首先，介绍一下什么是 Kubernetes 的 API server。

顾名思义，Kubernetes 的 API server 的主要功能就是提供 REST API，来访问和控制 Kubernetes 集群的。它的功能非常强大，一旦你拥有了这个 API 的所有权限，也就类似你有了对整个集群的 root 权限了。

对于没有对 Kubernetes 的 API 进行安全防护的情况，黑客可以通过以下三种方式对用户环境产生极大影响：

• 1 部署带有恶意软件的容器

  首先上传恶意镜像去公共的镜像仓库。然后自动的下载并部署到不安全的 Kubernetes 集群中去。

• 2 先部署合法的容器，然后容器运行时下载恶意代码，并执行

  首先先部署合法的容器在 Kubernetes 集群中，逃避一些容器镜像检查的策略。然后通过运行的容器去下载并执行恶意代码。

• 3 直接在主机上部署并运行恶意代码

  通过部署一些特权容器，或者 mount 主机的根目录进入容器，来获得提权，直接在主机上下载恶意代码，并且执行。

这些将给用户带来极大的安全隐患，我们需要对整个容器平台进行安全的防护。

首先，我们怎么知道我们的 Kubernetes 集群的 API server 有没有启用不安全的端口呢？

Kubernetes 的 API server 默认监听 8080 端口，也就是不安全的端口，所有的访问都会接受，并且不需要通过任何的认证和授权。也就是刚才所提到的，如果你使用了这个默认配置，整个 K8s 集群等于是向所有人都开放了，这是个非常严重的问题。

你可以通过以下命令来检查：

如果返回了类似如下的信息：

则说明你的 K8s 集群使用的默认设定，也就是说你的 API 端口不需要任何验证就可以直接操作你的集群，需要马上进行修复。

修改 API server 的配置中–insecure-port 项参数为 0，并且没有配置–insecure-bind-address。

同时启用安全的访问端口：

• 启用 TLS 加密。通过–tls-cert-file，–tls-private-key-file 这两项来设置证书及密钥。
• 默认端口为 6443, 可以通过–secure-port 来修改。
• 通过 --bind-address 来修改绑定地址。

详细请参见 Kubernetes 官网 。

整个 Kubernetes 的部署会比较复杂，同时对安全的配置也相当的麻烦。一些早期的 Kubernetes 版本中往往有很多安全漏洞存在。所以用户可以直接使用阿里云的 ACK 容器服务，通过很方便的导航式部署模式免去很多客户的麻烦。阿里云的 ACK 集群默认启用安全的 API 访问端口，系统组件的参数配置和镜像均经过安全合规加固；同时通过授权管理，加密通信，证书管理，默认启用 RBAC 等手段来加固整个客户 Kubernetes 集群的平台安全，彻底杜绝上述自建集群由于配置失误缩带来的重大安全隐患。

在授权管理方面，ACK 采用阿里云 RAM 和 Kubernetes RBAC 结合的机制，为用户提供了对 API server 以及 Kubernetes 集群其他资源的访问控制机制。用户可以使用主账号和具有管理员权限的子账号角色扮演用户进行授权管理，根据工作需要对管理的子账号赋予细粒度的集群内资源访问权限，例如某个集群的一个命名空间的只读权限。

同时 ACK 还面向不同身份的使用者提供了相应的缺省 RBAC 角色模板，方便用户使用：

角色 说明 管理员 对所有命名空间下所有资源的读写权限 运维人员 对所有命名空间下控制台可见资源的读写权限，对集群节点，存储卷，命名空间，配额的只读权限 开发人员 对所有命名空间或所选命名空间下控制台可见资源的读写权限 受限用户 对所有命名空间或所选命名空间下控制台可见资源的只读权限 自定义 权限由您所选择的 Cluster Role 决定，请在确定所选 Cluster Role 对各类资源的操作权限后再进行授权，以免子账号获得不符合预期的权限

使用 ACK 集群的用户可以方便的通过控制台或 OpenAPI 的方式获取集群访问 kubeconfig 凭证，如果因为人员离职等原因发生凭证的泄漏，可以立即吊销，从而确保账户安全。更多内容请参考阿里云容器服务官方文档

Docker 的进程隔离机制有可能导致的安全漏洞，对于安全要求高的客户来讲无法接受。例如客户希望能够有一个高隔离能力的多租平台。这类用户可以尝试阿里云新推出的 安全沙箱容器 的技术。不同于传统 Docker 应用进程隔离，共享宿主机操作系统内核的设计特点，安全沙箱容器采用虚拟化技术隔离容器应用，每个容器都独享操作系统内核。这样的优势在于隔离性大大提升，可以防止很多进程隔离带来的安全隐患。并且安全沙箱容器的性能非常好，实测可以达到原生 Docker 性能的 90% 以上，而且运行效率还在持续提升。

除了架构方面的加固，用户也需要对容器的东西，或者南北向的流量进行防护，对镜像仓库的镜像进行漏洞扫描，对容器的进程，文件系统，系统调用等方面进行管理和保护。用户也迫切希望看到对容器安全的管理和企业的开发运维流程结合起来，从而把 DevOps 演进为 DevSecOps。这需要在容器镜像的栖身之地镜像仓库入手。阿里云的 镜像仓库服务 ，可以支持 Linux、Windows、ARM 等多架构容器镜像的托管。安全方面镜像服务提供了基于 RAM 的认证授权机制容器镜像扫描, 签名等能力，并可以与第三方安全产品进行集成，例如 Palo Alto Networks 的 Prisma Cloud。同时阿里云还推出了镜像服务企业版，提供了网络和权限的访问控制，并支持更为安全的云原生交付链管理。

基于容器的开发，集成，部署，运行环境变得越来越复杂，如何全面保护这个快速变化的环境远远比单单保护 Kubernetes 集群复杂的多。Gartner 在 2019 年十月发布的一份云安全研究报告中提到，那些在云环境中最成功的网络攻击，都是由于用户的设置缺失，人为错误或者管理失败造成的，而不是公有云厂商安全防护职责的失误。

早在 2017 年，Twistlock 的联合创始人 John Merrolo 就受邀为美国国家标准技术研究所 (NIST) 编写了 SP800-190 应用容器安全指南。美国国家标准技术研究所 (NIST) 的职责之一是发布计算机网络安全标准和指南。 美国联邦政府部门需要在 NIST 安全指南发布一年之内遵照执行。Twistlock 在 2019 年五月成为 Palo Alto Networks 云安全平台 Prisma 的一员，同时 John Merrolo 先生成为 Prisma 的全球副总裁，继续引领公司成为主流的容器安全平台。

在过去的五年中，Prisma 为超过 90% 的美国联邦政府机构，超过 40% 的财富 100 强企业服务，为他们的容器环境通过全面的保护。在此主要列举客户在容器安全领域面对的十大挑战：

• 1 对容器环境提供实时全面直观的可视性，我们保护不了我们看不见的环境。
• 2 控制镜像的来源，让应用的开发，集成，部署，运行的生命周期中只使用可靠的镜像来源。
• 3 在应用的生命周期中持续的进行镜像漏洞扫描。漏洞发现不断更新，昨天安全的镜像可能今天就会因为新发现的漏洞而成为骇客的攻击目标。实时监控镜像存在已知漏洞及其严重性以制定修复优先次序。
• 4 监控和管理生产环境，包括对容器漏洞持续监控，修复存在漏洞的容器。
• 5 实时监控特权容器的使用，以防止骇客通过容器攻击主机。
• 6 实时监控应用服务暴露在集群之外的容器。这些容器最容易受到攻击。
• 7 实时监控运行时中所有容器的异常行为，对于异常行为报警或阻断。
• 8 甄别和阻断恶意容器攻击。
• 9 对容器应用服务进行合规性的检查和持续监控，能够检查 CIS, PCI-DSS, HIPAA, GDPR, NIST SP 800-190, 以及 FISMA 等常见的国际标准。
• 10 建立和监控针对容器环境和云原生应用程序的访问控制措施，并与企业和云厂商的访问控制系统集成。

面对这些挑战，我们需要一直努力完善对容器环境的保护。我们不但要有效保护在共有云和专有云中部署的 Kubernetes 集群，还需要为整个软件生命周期，提供跨主机、容器和无服务器部署的整体保护。Prisma Cloud 计算版本身是云原生的，并且支持 API，与阿里云的 ACK，ASK 容器平台无缝集成。同时，Palo Alto Networks 的容器安全解决方案也将很快上架阿里云的容器镜像市场，方便大家快速部署并集成到大家的容器平台之中。

本文转载自阿里云开发者社区。

原文链接：

https://developer.aliyun.com/article/754232?groupCode=kubernetes