安全防御 04月06日 01:30
浅谈K8s安全
index_new5.html
../../../zaker_core/zaker_tpl_static/wap/tpl_guoji1.html

 

本文总结了Kubernetes(K8s)集群中常见的安全问题,包括未授权访问、特权容器、挂载宿主机目录、容器自身安全、容器内应用安全、镜像安全、组件漏洞以及管理平台漏洞等多个方面。文章还强调了安全实践,如最小授权原则、网络控制、资源规划以及审计工具的重要性,并推荐了Falco和NeuVector等安全工具,为K8s集群的安全防护提供了实用的参考。

🔓 未授权访问:这是最严重的错误之一,可能由于弱口令或配置错误导致apiserver、kubectl、etcd等组件被直接访问,进而导致整个K8s集群的沦陷。例如,修改配置开启匿名认证后,可能泄露信息,甚至允许在宿主机容器中执行命令。

🐳 特权容器:配置特权容器可能允许攻击者挂载宿主机目录,从而控制宿主机。此外,应谨慎赋予容器特殊能力,如CAP_SYS_PTRACE和CAP_SYS_ADMIN,它们分别允许追踪进程和执行系统管理任务,可能导致安全风险。

📁 挂载宿主机重要目录:避免挂载/root、/etc、/proc等重要目录,这些目录包含系统关键信息。攻击者进入容器后,可能通过操作这些文件实现容器逃逸。

🖼️ 容器镜像安全:使用存在漏洞、被投毒或带有后门的镜像,可能导致供应链攻击。因此,定期扫描和更新镜像至关重要。

🛡️ 安全实践:实施最小授权原则、做好网络控制与准入、合理规划资源用量,并结合审计与安全工具,是保障K8s集群安全的关键。文章推荐了Falco和NeuVector等工具进行监控。

原创 lion_00 2023-08-22 10:58 北京

个人对K8s的安全做个随笔总结

  Kubernetes,简称K8s,相信看这篇文章的朋友,应该都不会太陌生,最近正好研究了一下这个东西,根据网上和自己的一些研究,简单对这个东西的安全性以及可能存在的安全问题,进行个总结。

一 K8s 架构

整体的架构如下图所示,

K8s 整体可以分为控制节点(Master)与工作节点(Node)两部分。Master 节点又包括如下组件:apiserver,etcd,scheduler,contorller-manager。各个组件的功能里就不作太多介绍详情可以参考K8s各组件介绍:

https://kubernetes.io/zh-cn/docs/concepts/overview/components/

二 K8s常见的安全问题

2.1 未授权访问

  这是笔者认为最不应该或者最愚蠢的错误类型,包括且不限于因为各种五花八门的弱口令,配置错误导致的apiserver,kubectl,etcd等可以直接访问,或者得通过各种方式拿到到kubeconfig的配置文件,这样的后果便是使得整个K8集群彻底沦陷。

例如kubectl,默认情况下访问是未授权状态:

但如果修改了某个节点的config.yaml配置文件,将匿名认证打开:

再次访问则会出现信息泄露:

甚至可以在对应的宿主机的容器中进行命令执行:

因此需要尽量在日常的应用运维中犯下类似这样的错误。常见的组件对应的端口如下:

    K8S组件
    默认端口
    kube-apiserver
    6443
    kubelet
    10250
    etcd
    2379 , 2380
    kube-proxy10256
    kube-controller-manager
    10252
    kube-scheduler
    10251


2.2 特权容器

  这也是运维中可能出现的情况,如下图配置,在运维过程中为了某种原因,把容器配置为特权模式:

  这样,万一这个容器失陷,便可以通过挂载宿主机目录,操作宿主机的文件,例如/root/.ssh/authorized_keys, crontab 等等,达到控制宿主机,进行逃逸。

  除此之外,容器的一些特殊能力的赋予也需要慎重,例如CAP_SYS_PTRACE,便是拥有着追踪进程的能力,这样有可能通过strace等命令捕获SSH密码:


  CAP_SYS_ADMIN,允许执行系统管理任务例如加载或卸载文件系统,基本等同于特权容器,也需要谨慎赋予。

其他容器能力介绍可以使用命令 man capabilities 进行参考。

2.3 挂载宿主机的重要目录

  与2.2类似,尽量不要挂载宿主机的重要目录,例如/root ,/etc ,/porc等目录,毕竟这些目录都存有系统的重要信息,如果攻击者进入到容器内,便可能通过操作某些文件,达到容器逃逸的目的。

2.4 容器自身安全

  因为容器本身与宿主机共享内核,那么便可以通过内核漏洞进入宿主机的namespace,从而达到逃逸的目的,最典型的应该算脏牛漏洞(CVE-2016-5195)。

2.5 容器内应用安全

  容器内的应用本身也存在各种安全问题,例如命令执行,SQL注入,文件上传,rce等等,与传统安全一致,所以这里就不用再进行展开了。当然,如果通过某种漏洞进入到应用pod中,在没有网络隔离的情况下,便可以面向整个K8S集群进行进一步攻击了。

2.6 容器镜像安全

   这也比较容易理解,例如使用了有漏洞的镜像,或者使用了被投毒的镜像,或者带有后门的镜像等等类似供应链攻击。

2.7 K8s本身组件的漏洞及第三方组件的漏洞

  K8s本身拥有着非常众多的组件,因此非常有可能因为某些组件出现漏洞从而导致整个集群沦陷的可能。

2.8 一些管理平台

  除了官方的Dashborad外,还有很多的K8s管理平台,例如Rancher ,KubeCube,KubeSphere 等等,这些平台除了未授权访问,弱口令外,本身也可能存在其他漏洞,一旦出现安全问题,也可能导致整个集群失陷。

2.9  其他问题

  例如某些功能,本意是想为运维提供方便,但被发现,可以利用控制集群的情况,类似system函数。

三  关于K8s的一些安全实践

  个人觉得,K8s使用了这么长时间,只要做到了安全里边的最小授权原则,做好网络控制与准入,做好资源的用量规划,除pod应用与自身组件产生的安全问题外,基本不会出现太多的安全问题。当然,审计与安全工具也十分重要,例如我之前推荐的两款工具Falco—云原生安全守护者

NeuVector----功能丰富且强大的容器安全开源软件,大到整体集群,小到单个容器,都可以进行监控。


四 一点感悟

  本文参考了腾讯安全的《红蓝对抗中的云原生漏洞挖掘及利用实录》(https://security.tencent.com/index.php/blog/msg/183)这篇文章,这篇文章发表于2021年三月,感概对K8s的研究领先了我3年半。这篇文章一直存在我的收藏里。从最初的完全懵逼到现在可以看懂,也欣慰自己在K8s方面也有了一点点进步,也终于可以可以把这个收藏的文章画个圈了。

  

阅读原文

跳转微信打开

Fish AI Reader

Fish AI Reader

AI辅助创作,多种专业模板,深度分析,高质量内容生成。从观点提取到深度思考,FishAI为您提供全方位的创作支持。新版本引入自定义参数,让您的创作更加个性化和精准。

FishAI

FishAI

鱼阅,AI 时代的下一个智能信息助手,助你摆脱信息焦虑

联系邮箱 441953276@qq.com

相关标签

Kubernetes K8s 容器安全 集群安全
相关文章