k8s安全

什么是k8s

kubernetes，简称K8s，是用8代替名字中间的8个字符“ubernete”而成的缩写，是一个开源的用于编排云平台中多个主机上的容器化的应用，目标是让部署容器化的应用能简单并且高效的使用, 提供了应用部署，规划，更新，维护的一种机制。其核心的特点就是能够自主的管理容器来保证云平台中的容器按照用户的期望状态运行着，管理员可以加载一个微型服务，让规划器来找到合适的位置，同时，Kubernetes在系统提升工具以及人性化方面，让用户能够方便的部署自己的应用

核心特点：

可移植: 支持公有云，私有云，混合云，多重云（multi-cloud）
可扩展: 模块化, 插件化, 可挂载, 可组合
自动化: 自动部署，自动重启，自动复制，自动伸缩/扩展
快速部署应用，快速扩展应用
无缝对接新的应用功能
节省资源，优化硬件资源的使用

提到k8s不得不提它的组件：master，node(节点)，pod
其中master是提供集群的管理控制中心，负责整个集群的决策调度，发现和响应集群的事件，Master组件可以在集群中任何节点上运行，但是为了简单起见，通常在一台VM/机器上启动所有Master组件，并且不会在此VM/机器上运行用户容器；node是指k8s集群的工作节点，每个集群中至少需要一台Node节点，当某个Node节点出现问题而导致宕机时，Master会自动将该节点上的Pod调度到其他节点；pod是指k8s的基本调度单元，一个pod一般包含一个或多个容器，这样可以保证它们一直位于主机上，并且可以共享资源，k8s中的每个pod都被分配一个唯一的（在集群内的）IP地址这样就可以允许应用程序使用端口，而不会有冲突的风险

随着越来越多企业开始上云的产品，并且在攻防演练中常常碰到云相关的场景，例：公有云、私有云、混合云、虚拟化集群等，所以很多时候传统的渗透姿势可能也要改变传统格局，开辟新的适用于云原生的渗透路径

参考链接：
https://baike.baidu.com/item/kubernetes/22864162?fr=ge_ala
https://blog.csdn.net/zouyang920/article/details/122819418
https://mp.weixin.qq.com/s?__biz=Mzg2ODYxMzY3OQ==&mid=2247510022&idx=1&sn=4b13dffc44e5cdbc11b39764fd817b0a&chksm=ceab4346f9dcca50ed981739d20530c0cd0959302a8f0f7c974db6124260240b10a70da77cd3&mpshare=1&scene=24&srcid=0327HPY9YFYeUhr2O5YD44TX&sharer_shareinfo=bd0ab73c01bb8887c96187bc6e5ec71b&sharer_shareinfo_first=bd0ab73c01bb8887c96187bc6e5ec71b#rd

k8s攻击面与利用

信息收集

k8s中的每个环境都会有很多信息是共享的，包括Secrets、API Keys、配置、服务等等，所以信息收集是关键，当然现在通常情况下会直接用CDK一把梭

获取环境变量，包括 Kubernetes Secret，服务名称、端口等

敏感信息泄漏

近年来Kubernetes敏感信息泄露事件屡见不鲜，通常情况下导致这些原因的一个是配置问题，如果不小心将敏感信息泄露给了错误的配置项，这些信息就可能被未经授权访问，另一个原因是存储问题如果存储的配置不正确，或者使用了不安全的存储后端，攻击者可能通过访问存储后端来获取敏感信息，或者容器共享相同的网络命名空间和文件系统，导致一个容器中的应用程序能够访问其他容器的文件系统或网络通信，那么敏感信息就可能被泄露

如上面这个，存在一个git泄漏，这样就可以尝试从网站转储 git存储库

使用git log可以查看代码提交的日志记录

然后使用checkout检出指定的提交，说不定会有敏感信息泄漏，比如env环境变量等等

DIND的利用

DIND(docker-in-docker)，简单来说就是在Docker容器中调用和执行宿主机的Docker，通常可以挂载 docker.sock 导致容器逃逸

假设现在存在一个命令注入的场景，如果要利用DIND进行逃逸，前提是在docker容器运行的时候把docker.sock套接字文件一并挂载到了容器中。当我们拿到容器权限又存在挂载的docker.sock套接字文件，我们就可以通过 Docker Socket与宿主机的Docker服务进行通信，我们可以通过它创建新的容器，并把宿主机的目录挂载到新创建的容器中，这样我们就能访问宿主机的资源了

通过信息收集发现了本地挂载docker.sock

然后我们下载一个docker可执行程序

随后就利用docker.sock来访问宿主机系统并在宿主机上执行docker命令

SSRF

服务器端请求伪造漏洞是云原生环境的首选攻击方式，通过SSRF可以访问云实例元数据以及内部服务元数据信息

通常情况下，pod部署的时候5000端口常用来做转发，也可以扫描其他端口，寻找敏感信息

容器逃逸之敏感目录挂载

通过mount查看挂载信息，可以看到一个host-system的挂载

查看里面的内容，发现像是把宿主机完整的系统都挂载进来了，那么我们可以用chroot切换到宿主机的目录，直接获取对宿主机系统的权限访问

可以使用docker ps查看宿主机运行的容器

目的是控制整个k8s集群，先查看k8s节点级配置文件

随后可以利用配置文件直接获取集群内的所有资源

kubectl --kubeconfig /etc/kubernetes/kubelet.conf  get all -n kube-system

API未授权访问

容器仓库是存储所有容器镜像的地方，大多数情况下，每个组织都有自己的私有仓库，有时候会因为配置错误，导致仓库处于公共/开放状态，此外，如果开发人员因为使用内部私有仓库安全配置不当，可能会在在容器镜像中存储一些敏感信息

我们可以利用API文档来测试访问仓库的信息

API文档参考：https://docs.docker.com/registry/spec/api/

列出存储库

查看仓库的具体信息，并且可以直接未授权下载下来

通过审计，可以发现镜像信息中有API密钥信息和ENV变量等敏感信息泄露

挖矿分析

因为鉴于k8s环境的复杂性和神秘性，我们很难知道其中的容器镜像是基于什么构建的，并且部署了哪些主动监控也都是未知数，所以k8s很容易成为挖矿攻击的目标，遇到此类攻击，我们该如何识别和分析？首先，我们需要确定k8s集群中的所有资源/镜像以及作业，一旦我们确定了在k8s集群中运行的作业，就可以通过以下命令，来获取pod信息

kubectl describe job batch-check-job
kubectl get pods --namespace default -l "job-name=batch-check-job"

然后进行manifest分析，manifest是一个json或yaml格式的Kubernetes API对象描述

kubectl get pod batch-check-job-xxxx -o yaml

可以看到Docker镜像名称，然后通过docker history查看镜像的构建历史记录，检查每一层的构建中是否植入了恶意挖矿脚本

docker history --no-trunc madhuakula/k8s-goat-batch-check

敏感信息提取与恢复

在容器化世界中，密码、私钥、令牌等很容易被错误处理或者增加了一些看不到的敏感信息文件，我们该如何恢复提取？
首先，尽可能多的尝试浏览运行容器中的所有文件、环境变量等

通过分析镜像信息，找到敏感信息，我们可以通过镜像反向生成dockerfile

alias dfimage="docker run -v /var/run/docker.sock:/var/run/docker.sock --rm alpine/dfimage"
dfimage -sV=1.36 madhuakula/k8s-goat-hidden-in-layers

或者使用Dive工具，可以辅助分析镜像的每一层，下载地址：https://github.com/wagoodman/dive

通过分析，可以看到/root/contributions.txt, /root/secret.txt这两个比较重要和可疑的文件，并且secret.txt在构建的时候被删除了，我们现在来恢复它

使用docker save把镜像导出文件并解压，这里因为只有3层，所以很容易提取所有的层并检查内容，找到相对应的id进行二次解压即可得到敏感信息文件

RBAC最低权限配置错误

RBAC是对K8S集群中的一些Pod采取限制，以防止它们访问 API server，从而帮助保护 Kubernetes 集群，但一些错误配置可能导致访问控制薄弱，无法实现最小特权原则，攻击者往往利用绑定到 pod的serviceaccount提供的webhookapikey访问权限来控制和获取敏感资源，默认情况下将所有secrets、tokens和service accounts信息都存储在一个固定的目录，通常是在/var/run/secrets/kubernetes.io/serviceaccount/目录下面

可以使用这些信息与 Kubernetes API服务进行交互访问，从而达到获取敏感资源信息的目的

指向内部 API 服务器主机名：export APISERVER=https://${KUBERNETES_SERVICE_HOST}
设置 ServiceAccount令牌的路径：export SERVICEACCOUNT=/var/run/secrets/kubernetes.io/serviceaccount
读取 pods namespace并将其设置为变量：export NAMESPACE=$(cat ${SERVICEACCOUNT}/namespace)
指定读取ServiceAccount持有者令牌：export TOKEN=$(cat ${SERVICEACCOUNT}/token)
指定在curl请求查询时要使用的证书路径:export CACERT=${SERVICEACCOUNT}/ca.crt

然后就可以使用令牌和构造的查询来访问 Kubernetes API了

curl --cacert ${CACERT} --header "Authorization: Bearer ${TOKEN}" -X GET ${APISERVER}/api

因为 Kubernetes本身是利用API服务来创建、删除 pod等操作的，所以接下来的操作就很多了，比如查询default命名空间中的secrets

curl --cacert ${CACERT} --header "Authorization: Bearer ${TOKEN}" -X GET ${APISERVER}/api/v1/secrets

查询特定命名空间的secrets

curl --cacert ${CACERT} --header "Authorization: Bearer ${TOKEN}" -X GET ${APISERVER}/api/v1/namespaces/${NAMESPACE}/secrets

获取 k8svaultapikey

curl --cacert ${CACERT} --header "Authorization: Bearer ${TOKEN}" -X GET ${APISERVER}/api/v1/namespaces/${NAMESPACE}/secrets | grep k8svaultapikey

自动化基线检查与安全评估

Docker CIS 安全基线分析

场景主要用于在Kubernetes节点之上进行Docker CIS基准分析，以识别可能存在的安全漏洞，首先需要部署docker bench security将它启动为DaemonSet

kubectl apply -f scenarios/docker-bench-security/deployment.yaml

访问docker-bench-security-xxxxx pod 并执行Docker CIS基线测试脚本（如果有多个节点，就依次进入并执行）最后，可以根据 Docker CIS安全基线测试的结果进行进一步的利用或修复

Kubernetes CIS 安全基线分析

场景主要用在Kubernetes节点之上进行Kubernetes CIS基线分析，识别可能存在的安全漏洞，首先，我们在节点上部署kube-bench security为Kubernetes job

kubectl apply -f scenarios/kube-bench-security/node-job.yaml
kubectl apply -f scenarios/kube-bench-security/master-job.yaml

然后获取pod信息和查看jobs列表

最后通过查看pod日志进行漏洞分析和修补

KubeAudit审计k8s集群

kubeaudit是一个命令行工具和一个 Go包，用于审计 Kubernetes集群各种不同的安全问题，下载链接：https://github.com/Shopify/kubeaudit
Kubeaudit会检测在集群中的容器是否运行，并且会审计该集群中的所有Kubernetes资源

kubeaudit all

Sysdig Falco安全监控与检测

Falco是一个云原生运行时安全工具，旨在检测应用程序中的异常活动，可用于监控Kubernetes应用程序和内部组件的运行时安全性。 仅需为Falco撰写一套规则，即可持续监测并监控容器、应用、主机及网络的异常活动，Falco可在运行时检测意外的应用程序行为并发出威胁警报；使用前需要用helm v3进行部署

helm repo add falcosecurity https://falcosecurity.github.io/charts
helm repo update
helm install falco --set falco.jsonOutput=true  falcosecurity/falco

Z29vZGJ5ZQo=