最近阿里云容器团队与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集群中去。 - 先部署合法的容器，然后容器运行时下载恶意代码，并执行
首先先部署合法的容器在Kubernetes集群中，逃避一些容器镜像检查的策略。然后通过运行的容器去下载并执行恶意代码。 - 直接在主机上部署并运行恶意代码
通过部署一些特权容器，或者mount主机的根目录进入容器，来获得提权，直接在主机上下载恶意代码，并且执行。
这些将给用户带来极大的安全隐患，我们需要对整个容器平台进行安全的防护。
首先，我们怎么知道我们的Kubernetes的集群的API有没有启用不安全的端口呢？
Kubernetes的API server默认监听8080端口，也就是不安全的端口，所有的访问都会接受，并且不需要通过任何的认证和授权。也就是刚才所提到的，如果你使用了这个默认配置，整个K8s集群等于是向所有人都开放了，这是个非常严重的问题。
你可以通过以下命令来检查：
如果返回了类似如下的信息：
则说明你的K8s集群使用的默认设定，也就是说你的API端口不需要任何验证就可以直接操作你的集群，需要马上进行修复。
修改API server的配置中--insecure-port项参数为0，并且没有配置--insecure-bind-address。
同时启用安全的访问端口：
o 启用TLS加密。通过--tls-cert-file，--tls-private-key-file 这两项来设置证书及密钥。
o 默认端口为6443, 可以通过--secure-port来修改。
o 通过 --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强企业服务，为他们的容器环境通过全面的保护。在此主要列举客户在容器安全领域面对的十大挑战：
- 对容器环境提供实时全面直观的可视性，我们保护不了我们看不见的环境。
- 控制镜像的来源，让应用的开发，集成，部署，运行的生命周期中只使用可靠的镜像来源。
- 在应用的生命周期中持续的进行镜像漏洞扫描。漏洞发现不断更新，昨天安全的镜像可能今天就会因为新发现的漏洞而成为骇客的攻击目标。实时监控镜像存在已知漏洞及其严重性以制定修复优先次序。
- 监控和管理生产环境，包括对容器漏洞持续监控，修复存在漏洞的容器。
- 实时监控特权容器的使用，以防止骇客通过容器攻击主机。
- 实时监控应用服务暴露在集群之外的容器。这些容器最容易受到攻击。
- 实时监控运行时中所有容器的异常行为，对于异常行为报警或阻断。
- 甄别和阻断恶意容器攻击。
- 对容器应用服务进行合规性的检查和持续监控，能够检查CIS, PCI-DSS, HIPAA, GDPR, NIST SP 800-190, 以及FISMA等常见的国际标准。
- 建立和监视针对容器环境和云原生应用程序的访问控制措施，并与企业和云厂商的IAM系统集成。
面对这些挑战，我们需要一直在努力完善对容器环境的保护。我们不但要有效保护在共有云和私有云中部署的Kubernetes集群，还需要以为整个软件生命周期，提供跨主机、容器和无服务器部署的整体保护。Prisma Cloud计算版本身是云原生的，并且支持 API，与阿里云的ACK，ASK容器平台无缝集成。同时，Palo Alto Networks的容器安全解决方案也将很快上架阿里云的容器镜像市场，方便大家快速部署并集成到大家的容器平台之中。
阿里云大学提供的免费云原生技术公开课，详细讲解了Kubernetes 以及它的安全访问控制。阿里云大学还提供了免费的容器安全与Palo Alto Networks解决方案课程， 对于如何利用Prisma Cloud 计算版全面保护你的容器环境和应用的生命周期进行了详细的讲解和演示，为了方便大家讨论Kubernetes的防护以及容器安全解决方案，Palo Alto Networks与阿里云容器团队建立了容器安全讨论钉钉群。欢迎大家扫码加入钉钉群和我们进一步讨论容器安全的话题。