如何让你的Kubernetes集群更安全

2020 年 4 月 21 日

如何让你的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

2020 年 4 月 21 日 10:00 804

评论 1 条评论

发布
用户头像
Prisma的确挺好用
2020 年 04 月 22 日 01:06
回复
没有更多评论了
发现更多内容

创业使人成长系列 (2)- 散伙协议

石云升

创业 股权 合伙人 散伙协议

啃碎并发(八):深入分析wait&notify原理 猿码架构

猿灯塔

16种设计思想 - Design for failure

Man

Java 微服务 设计原则

肖风:数据要素市场与分布式AI平台

CECBC区块链专委会

Git 常用操作汇总-cheat sheet

多选参数

git GitHub gitlab gitee

计算机操作系统基础(十七)---进程同步之Unix域套接字

书旅

php laravel 线程 操作系统 进程

架构师必须知道的架构知识

Chank

架构 架构师 Architecture Architect

如何基于 BitMap 进行海量数据分析

GrowingIO技术专栏

互联网 数据分析 科技互联网 数据化

Docker基础修炼3--Docker容器及常用命令

黑马腾云

Docker Linux 命令 容器技术

区块链+高考,让世界再无冒名顶替

CECBC区块链专委会

实验室里的AI激情:腾讯优图的升级修炼之路

脑极体

使用 Dockerfile 创建镜像 | Docker 系列

AlwaysBeta

Docker 容器 镜像 Dockerfile 容器技术

无价值人生记录.0:浪费1000%时间去做一个用来节省1%时间的“轮子玩具”(上:因缘)

八苦-瞿昙

C# 程序员人生 随笔 随笔杂谈 aop

redis系列之——Redis为什么这么快?

诸葛小猿

Java redis 程序员

DOM 树的构建

法正

html DOM 前端进阶训练营

521我发誓读完本文,再也不会担心Spring配置类问题了

YourBatman

spring springboot @Configuration Spring配置类

一个爱不释手的Apifox,让我扔掉 Postman的想法

给你买橘子

Java 编程 程序员 开发 Postman

猿灯塔:spring Boot Starter开发及源码刨析(三)

猿灯塔

Java 猿灯塔

【写作群星榜】6.27~7.10 写作平台优秀作者 & 文章排名

InfoQ写作平台

写作平台 排行榜

终于有人把Elasticsearch架构原理讲明白了,感觉之前看的都是渣

爱嘤嘤嘤斯坦

Java elasticsearch 编程 架构

如果你想写自己的Benchmark框架

程序那些事

JVM 性能调优 GC benchmark

Java 后端博客系统文章系统——No2

猿灯塔

【Java虚拟机】垃圾收集器与内存分配

烫烫烫个喵啊

Java Java虚拟机

给 Spring Boot 项目减减肥!18.18M 到 0.18M 是如何做到的?

给你买橘子

Java 程序员 Spring Cloud 编码 SpringBoot 2

亚马逊:让创新科技成为重启世界的新动能

InfoQ_a5af1d89eb51

SpringBoot入门:01 - 配置数据源

阿亮

Java spring springboot

图解:深度优先搜索与广度优先搜索

淡-蓝色

Java 数据结构 算法

刘华:上云还是不上云,这是一个问题

刘华Kenneth

架构 敏捷

《精益思想》读后感分享

zhongzhq

精益 精益思想 精益生产方式 高效工作方式

玩转Redis高可用 - 哨兵(Sentinel)模式

Man

高可用 redis高可用 中间件

微服务架构下分布式事务解决方案

Arthur

如何让你的Kubernetes集群更安全-InfoQ