Kubernetes学习笔记

Kubernetes

kubernetes，简称 K8s,是 Google 开源的一个容器编排引擎，它支持自动化部署、大规模可伸缩、应用容器化管理。在生产环境中部署一个应用程序时，通常要部署该应用的多个实例以便对应用请求进行负载均衡。

官网 : https://kubernetes.io/

Fofa : app="kubernetes"

kubectl使用

相关文章

相关案例

未授权

Kubernetes Api Server 未授权访问

  • 漏洞描述

    Kubernetes API Server 可以在两个端口上提供了对外服务：8080（insecure-port，非安全端口）和 6443（secure-port，安全端口），其中 8080 端口提供 HTTP 服务且无需身份认证，6443 端口提供 HTTPS 服务且支持身份认证 (8080 和 6443 端口并不是固定的，是通过配置文件来控制的)。

    如果 8080 在外部环境中被暴露出来，攻击者便可以利用此端口进行对集群的攻击, 前提条件略显苛刻（配置失当 + 版本较低），首先 8080 端口服务是默认不启动的，但如果用户在 /etc/kubernets/manifests/kube-apiserver.yaml 中有 --insecure-port=8080 配置项，那就启动了非安全端口，有了安全风险。1.20版本后该选项已无效化.

    若我们不带任何凭证的访问 API server 的 secure-port 端口，默认会被服务器标记为 system:anonymous 用户, 一般 system:anonymous 用户权限是很低的，但是如果运维人员管理失当，将 system:anonymous 用户绑定到了 cluster-admin 用户组，那么就意味着 secure-port 允许匿名用户以管理员权限向集群下达命令。

  • 相关文章

Kubernetes Dashboard 未授权访问

  • 漏洞描述

    Kubernetes Dashboard 是一个通用的，基于 Web 的 Kubernetes 集群用户界面。它允许用户管理集群中运行的应用程序，并对其进行故障排除，以及管理集群本身。在其早期版本中（v1.10.1 之前）存在未授权访问风险，用户在按照官方文档所给方式部署完成后，默认下，需要先执行 kubectl proxy，然后才能通过本地 8001 端口访问 Dashboard。但是，如果直接将 Dashboard 端口映射在宿主机节点上，或者在执行 kubectl proxy 时指定了额外地址参数，如：

    kubectl proxy --address 0.0.0.0 --accept-hosts='^*$'

    那么所有能够访问到宿主机的用户，包括攻击者，都将能够直接访问 Dashboard。

    默认情况下 Dashboard 需要登录认证，但是，如果用户在 Dashboard 的启动参数中添加了 --enable-skip-login 选项，那么攻击者就能够直接点击 Dashboard 界面的 “跳过” 按钮，无需登录便可直接进入 Dashboard。关于如何设置 --enable-skip-login ，在 v1.10.1 前，实则是无需配置的，通过在 Kubernetes Dashboard 的 Web 登录界面点击 “跳过” 按钮即可访问，也是因为这个原因，安全意识较为薄弱的用户直接将早期版本以默认的配置方式部署在互联网上使得攻击者无需花费丝毫力气就可以轻易浏览到 Kubernetes 集群的运行状态，因而在 v1.10.1 版本后，开发团队增加了显式配置的功能，需要用户在相应部署的 yaml 文件中指定 --enable-skip-login 参数配置才能开启未授权访问。

kubelet 未授权访问

  • 漏洞描述

    kubelet 是在 Node 上用于管理本机 Pod 的，kubectl 是用于管理集群的。kubectl 向集群下达指令，Node 上的 kubelet 收到指令后以此来管理本机 Pod。

    Kubelet 服务启动后会监听多个端口，用于接收 Kubernetes API Server 组件发送的请求

    • 10248 : Kubelet healthz 的服务端口，用于判断 Kubelet 组件的健康状态，已于 Kubernetes v1.16 版本后弃用，访问该端口默认需要认证授权
    • 10250 : Kubelet 的 HTTPS 服务，读写端口，提供 Kubernetes 基本资源运行状态， 访问该端口默认需要认证授权
    • 10255 : Kubelet 的 HTTP 服务，只读端口，提供只读形式的 Kubernetes 基本资源运行状态，该端口无需进行认证授权，默认为禁用
    • 4194 : cAdvisor 的 HTTP 服务端口，自 Kubernetes v1.10 版本开始，官方去除了 --cadvisor-port 参数配置，不再支持对 cAdvisor 的访问

    kubelet 对应的 API 端口默认在 10250，运行在集群中每台 Node 上，kubelet 的配置文件在 node 上的 /var/lib/kubelet/config.yaml

    配置文件中 authentication 选项用于设置 kubelet api 能否被匿名访问，authorization 选项用于设置 kubelet api 访问是否需要经过 Api server 进行授权, 如果把 authentication-anonymous-enabled 改为 true，authorization-mode 改为 AlwaysAllow，再使用命令 systemctl restart kubelet 重启 kubelet，那么就存在 kubelet 未授权访问

  • POC | Payload | exp

    # 如果有 kubelet 未授权，可以用以下命令在 Pod 内执行命令

curl https://node_ip:10250/pods
curl -XPOST -k https://node_ip:10250/run/<namespace>/<PodName>/<containerName> -d "cmd=command"

/pods
/runningpods
/metrics
/spec
/stats
/stats/container
/logs
/run/
/exec/
/attach/
/portForward/
/containerLogs/

  • kubeconfig 泄露

    kubectl --kubeconfig=config --insecure-skip-tls-verify=true get pods --all-namespaces -o wide

etcd 未授权

  • 漏洞描述

    etcd 是 k8s 集群中的数据库组件，默认监听在 2379 端口. 如果 2379 存在未授权，那么就可以通过 etcd 查询集群内管理员的 token，然后用这个 token 访问 api server 接管集群。

    在启动 etcd 时，如果没有指定 --client-cert-auth 参数打开证书校验，并且没有通过iptables/防火墙等实施访问控制，etcd 的接口和数据就会直接暴露给外部黑客 "

    下载 https://github.com/etcd-io/etcd/releases/

    etcdctl --endpoints=https://etcd_ip:2379/ get / --prefix --keys-only
# 查询管理员 token
etcdctl --endpoints=https://etcd_ip:2379/ get / --prefix --keys-only | grep /secrets/
# 在 etcd 里查询管理员的 token，然后使用该 token 配合 kubectl 指令接管集群
etdctl --endpoints=https://etcd_ip:2379/ get /registry/secrets/default/admin-token-xxxxx
# 拿到 token 以后，用 kubectl 接管集群
kubectl --insecure-skip-tls-verify -s https://master_ip:6443/ --token="xxxxxx" get nodes

# 如果要求证书文件,需要将以下文件加入环境变量才能访问（如果有未授权，那么不用带证书都能访问）
export ETCDCTL_CERT=/etc/kubernetes/pki/etcd/peer.crt
export ETCDCTL_CACERT=/etc/kubernetes/pki/etcd/ca.crt
export ETCDCTL_KEY=/etc/kubernetes/pki/etcd/peer.key

中间人攻击

CVE-2020-8554

容器逃逸

目录挂载逃逸

挂载 /var/log 导致容器逃逸

  • 漏洞描述

    当 pod 以可写权限挂载了宿主机的 /var/log 目录，而且 pod 里的 service account 有权限访问该 pod 在宿主机上的日志时，攻击者可以通过在容器内创建符号链接来完成简单逃逸。

  • 相关文章

滥用CAP_DAC_READ_SEARCH（shocker攻击）导致容器逃逸

  • 漏洞描述

    在早期的 docker 中，容器内是默认拥有 CAP_DAC_READ_SEARCH 的权限的，拥有该 capability 权限之后，容器内进程可以使用 open_by_handle_at 系统调用来爆破宿主机的文件内容。

  • 相关文章

CVE-2017-1002101

  • 漏洞描述

    Kubernetes 在宿主机文件系统上解析了 Pod 滥用 subPath 机制创建的符号链接，故而宿主机上任意路径（如根目录）能够被挂载到攻击者可控的恶意容器中，导致容器逃逸。

  • 相关文章

CVE-2021-25741

CVE-2021-30465

CVE-2022-0811 容器逃逸漏洞

  • 漏洞描述

    CrowdStrike 的云威胁研究团队在 CRI-O(一个支撑 Kubernetes 的容器运行时引擎) 中发现了一个新的漏洞 (CVE-2022-0811)，被称为 “cr8escape”。攻击者在创建容器时可以从 Kubernetes 容器中逃离，并获得对主机的根访问权，从而可以在集群中的任何地方移动。调用 CVE-2022-0811 可以让攻击者对目标执行各种操作，包括执行恶意软件、数据外溢和跨 pod 的横向移动。

  • 影响范围

    CRI-O > 1.19.0

  • 相关文章

提权

CVE-2018-1002105

CVE-2020-8559

  • 漏洞描述

    CVE-2020-8559 是一个针对 Kubernetes 的权限提升漏洞，攻击者可以截取某些发送至节点 kubelet 的升级请求，通过请求中原有的访问凭据转发请求至其他目标节点，从而造成节点的权限提升.

  • 相关文章

横向

利用 Service Account 连接 API Server 执行指令

  • https://tttang.com/archive/1465/#toc_service-accountapi-server

    k8s 有两种账户：用户账户和服务账户，用户账户被用于人与集群交互（如管理员管理集群），服务账户用于 Pod 与集群交互（如 Pod 调用 api server 提供的一些 API 进行一些活动）

    如果我们入侵了一台有着高权限服务账户的 Pod，我们就可以用它对应的服务账户身份调用 api server 向集群下达命令。

    pod 的 serviceaccount 信息一般存放于 /var/run/secrets/kubernetes.io/serviceaccount/ 目录下

    CA_CERT=/var/run/secrets/kubernetes.io/serviceaccount/ca.crt
TOKEN=$(cat /var/run/secrets/kubernetes.io/serviceaccount/token)
NAMESPACE=$(cat /var/run/secrets/kubernetes.io/serviceaccount/namespace)
curl --cacert $CA_CERT -H "Authorization: Bearer $TOKEN" "https://api_server_ip:6443/version/"

DOS

相关文章

点击关注，共同学习！
安全狗的自我修养

github haidragon

https://github.com/haidragon

posted @ 2022-10-31 10:11  syscallwww  阅读(225)  评论(0)  编辑  收藏  举报