浅谈云上攻防——Kubelet 访问控制机制与提权方法研究

关注

发布于: 22 小时前

本文翻译整理自：https://rhinosecuritylabs.com/cloud-security/kubelet-tls-bootstrap-privilege-escalation/

背景

近些年针对 kubernetes 的攻击呈现愈演愈烈之势，一旦攻击者在 kubernetes 集群中站稳脚跟就会尝试渗透集群涉及的所有容器，尤其是针对访问控制和隔离做的不够好的集群受到的损害也会越大。例如由 unit 42 研究人员检测到的 TeamTNT 组织的恶意软件 Siloscape 就是利用了泄露的 AWS 凭证或错误配置从而获得了 kubelet 初始访问权限后批量部署挖矿木马或窃取关键信息如用户名和密码，组织机密和内部文件，甚至控制集群中托管的整个数据库从而发起勒索攻击。根据微步在线的统计上一次遭受其攻击的 IP 地址 90%以上属于中国，因此需要安全人员及时关注并提前规避风险。Siloscape 具体攻击流程如图 1 所示。

图 1-Siloscape 攻击流程

Kubernetes 集群中所有的资源的访问和变更都是通过 kubernetes API Server 的 REST API 实现的，所以集群安全的关键点就在于如何识别并认证客户端身份并且对访问权限的鉴定，同时 K8S 还通过准入控制的机制实现审计作用确保最后一道安全底线。除此之外 K8S 还配有一系列的安全机制（如 Secret 和 Service Account 等）共同实现集群访问控制的安全，具体请求如图 2 所示：

图 2-Kubernetes API 请求

其中用户所控制的 kubectl 即每个 Node 节点都会启用的进程，可以把 kubelet 理解成【Server-Agent】架构中的 agent，用来处理 Master 节点下发到本节点的任务，管理 Pod 和其中的容器，比如创建容器、Pod 挂载数据卷、下载 secret、获取容器和节点状态等工作。Kubelet 会在 API Server 上注册节点信息，定期向 Master 汇报节点资源使用情况。如果没有做好相关的权限管控或其遭受了任何的攻击都可能导致对 k8s 集群更广泛的危害。如以下图 3 操作。

图 3-Kubectl 操作

K8S 认证鉴权

认证阶段（Authentication）

认证阶段即判断用户是否为能够访问集群的合法用户，API Server 目前提供了三种策略多种用户身份认证方式，他们分别如下表 1：

表 1-认证

其中 X509 是 kubernetes 组件间默认使用的认证方式，同时也是 kubectl 客户端对应的 kube-config 中经常使用到的访问凭证，是一种比较安全的认证方式。

鉴权阶段（Authorization）

当 API Server 内部通过用户认证后，就会执行用户鉴权流程，即通过鉴权策略决定一个 API 调用是否合法，API Server 目前支持以下鉴权策略

表 2-鉴权

其中 Always 策略要避免用于生产环境中，ABAC 虽然功能强大但是难以理解且配置复杂逐渐被 RBAC 替代，如果 RBAC 无法满足某些特定需求，可以自行编写鉴权逻辑并通过 Webhook 方式注册为 kubernetes 的授权服务，以实现更加复杂的授权规则。而 Node 鉴权策略主要是用于对 kubelet 发出的请求进行访问控制，限制每个 Node 只访问它自身运行的 Pod 及相关 Service、Endpoints 等信息。

准入控制（Admission Control）

突破了如上认证和鉴权关卡之后，客户端的调用请求还需要通过准入控制的层层考验，才能获得成功的响应，kubernetes 官方标准的选项有 30 多个，还允许用户自定义扩展。大体分为三类验证型、修改型、混合型，顾名思义验证型主要用于验证 k8s 的资源定义是否符合规则，修改型用于修改 k8s 的资源定义，如添加 label，一般运行在验证型之前，混合型及两者的结合。

AC 以插件的形式运行在 API Server 进程中，会在鉴权阶段之后，对象被持久化 etcd 之前，拦截 API Server 的请求，对请求的资源对象执行自定义（校验、修改、拒绝等）操作。

Kubelet 认证鉴权

认证

Kubelet 目前共有三种认证方式:

1.允许 anonymous，这时可不配置客户端证书

authentication:    anonymous:        enabled: true

复制代码

2.webhook，这时可不配置客户端证书

authentication:    webhook:      enabled: true

复制代码

3.TLS 认证，也是目前默认的认证方式，对 kubelet 的 HTTPS 端点启用 X509 客户端证书认证。

authentication:    anonymous:        enabled: false    webhook:      enabled: false    x509:      clientCAFile: xxxx

复制代码

然而在实际环境当你想要通过 kubectl 命令行访问 kubelet 时，无法传递 bearer tokens，所以无法使用 webhook 认证，这时只能使用 x509 认证。

鉴权

kubelet 可配置两种鉴权方式分别为 AlwaysAllow 和 Webhook，默认的及安全模式 AlwaysAllow，允许所有请求。而 Webhook 的鉴权过程时委托给 API Server 的，使用 API Server 一样的默认鉴权模式即 RBAC。

通常在实际环境中需要我们通过 TBAC 为用户配置相关权限，包括配置用户组以及其相对应的权限。并最终将用户和角色绑定完成权限的配置。

TLS bootstrapping

TLS 在实际实现的时候成本较高，尤其集群中众多的 kubelet 都需要与 kube-API Server 通信，如果由管理员管理证书及权限，很有可能会因为证书过期等问题出现混乱。这时候 Kubelet TLS Bootstrapping 就应运而生了。其主要实现两个功能第一，实现 kubelet 与 kube-API Server 之间的自动认证通信；第二，限制相关访问 API Server 的权限。

K8s 目前默认通过 TLS bootstrapping 这套机制为每个 kubelet 配置签名证书确保与 API Server 的交互安全。其核心思想是由 kubelet 自已生成及向 API Server 提交自已的证书签名请求文件（CSR），k8s-master 对 CSR 签发后，kubelet 再向 API Server 获取自已的签名证书，然后再正常访问 API Server。具体如图所示：