最近阿里云容器团队与 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 进行安全防护的情况，黑客可以通过以下三种方式对用户环境产生极大影响：
这些将给用户带来极大的安全隐患，我们需要对整个容器平台进行安全的防护。
首先，我们怎么知道我们的 Kubernetes 集群的 API server 有没有启用不安全的端口呢？
Kubernetes 的 API server 默认监听 8080 端口，也就是不安全的端口，所有的访问都会接受，并且不需要通过任何的认证和授权。也就是刚才所提到的，如果你使用了这个默认配置，整个 K8s 集群等于是向所有人都开放了，这是个非常严重的问题。
你可以通过以下命令来检查：
如果返回了类似如下的信息：
则说明你的 K8s 集群使用的默认设定，也就是说你的 API 端口不需要任何验证就可以直接操作你的集群，需要马上进行修复。
修改 API server 的配置中–insecure-port 项参数为 0，并且没有配置–insecure-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 强企业服务，为他们的容器环境通过全面的保护。在此主要列举客户在容器安全领域面对的十大挑战：
面对这些挑战，我们需要一直努力完善对容器环境的保护。我们不但要有效保护在共有云和专有云中部署的 Kubernetes 集群，还需要为整个软件生命周期，提供跨主机、容器和无服务器部署的整体保护。Prisma Cloud 计算版本身是云原生的，并且支持 API，与阿里云的 ACK，ASK 容器平台无缝集成。同时，Palo Alto Networks 的容器安全解决方案也将很快上架阿里云的容器镜像市场，方便大家快速部署并集成到大家的容器平台之中。
原文链接 ：
