Safe: 14-Kubernetes安全
- TAGS: Safe
主要内容:
- k8s介绍
- k8s组件介绍
- k8s安全机制讲解
- k8s安全加固
- 云原生安全
- 云安全架构
#安装 Docker Desktop 镜像加速 https://registry.docker-cn.com Windows打开Powershell git clone https://github.com/AliyunContainerService/k8s-for-docker-desktop cd k8s-for-docker-desktop ./load_images.sh #启动kubernetes 界面点击 #创建 kubernetes-dashboard cd k8s-for-docker-desktop kubectl create -f kubernetes-dashboard.yaml #授权`kube-system`默认服务账号 kubectl apply -f kube-system-default.yaml # 开启转发 kubectl proxy # 访问kubernetes-dashboard http://127.0.0.1:8001/api/v1/namespaces/kubernetes-dashboard/services/https:kubernetes-dashboard:/proxy
K8S威胁矩阵
初始访问
初始访问策略包括用于获取资源访问权的技术。在容器化环境中,这些技术可以首先访问集群。这种访问可以直接通过集群管理层实现,也可以通过访问部署在集群上的恶意或易受攻击的资源来实现。
- 使用云凭据
如果 Kubernetes 集群部署在公共云中(例如,Azure 中的 AKS、GCP 中的 GKE 或 AWS 中的 EKS),受损的云凭证可能导致集群接管。有权访问云帐户凭据的攻击者可以访问集群的管理层。 - 恶意镜像注入
在集群中运行恶意镜像可能会损害集群。访问私有注册中心的攻击者可以在注册表中植入他们自己的受损镜像。然后后者可以由用户拉取。此外,用户经常使用来自可能是恶意的公共注册中心(例如 Docker Hub)的不受信任的镜像。
基于不受信任的基础镜像构建镜像也会导致类似的结果。
- 解决
- 谨慎使用公共镜像
- 建立私有镜像仓库,有准入
- 基础镜像由sre运维统一生成,基于此镜像结合自研代码构建镜像并上传到镜像仓库。
- 公共仓库镜像上传到私有镜像仓库
- 基础镜像由sre运维统一生成,基于此镜像结合自研代码构建镜像并上传到镜像仓库。
- 谨慎使用公共镜像
- 解决
- Kubeconfig 文件
kubectl 也使用 kubeconfig 文件,其中包含有关 Kubernetes 集群的详细信息,包括它们的位置和凭据。如果集群托管为云服务(例如 AKS 或 GKE),则此文件通过云命令下载到客户端(例如,AKS 的“az aks get-credential”或GKE 的“gcloud container clusters get-credentials” )。
如果攻击者可以访问此文件,例如通过受感染的客户端,他们可以使用它来访问集群。 - 易受攻击的应用程序
在集群中运行面向公众的易受攻击的应用程序可以启用对集群的初始访问。运行易受远程代码执行漏洞 (RCE) 攻击的应用程序的容器可能会被利用。如果将服务帐户挂载到容器(Kubernetes 中的默认行为),攻击者将能够使用此服务帐户凭据向 API 服务器发送请求。 - 暴露的敏感接口
将敏感接口暴露给互联网会带来安全风险。一些流行的框架并不打算暴露在互联网上,因此默认情况下不需要身份验证。因此,将它们暴露在互联网上会允许未经身份验证地访问敏感接口,这可能会导致恶意行为者在集群中运行代码或部署容器。例如 Kubernetes 仪表板。
执行
执行策略包括攻击者用来在集群内运行代码的技术。
- 执行到容器中
拥有权限的攻击者可以使用 exec 命令(“kubectl exec”)在集群中的容器中运行恶意命令。在这种方法中,攻击者可以使用合法的镜像,例如操作系统镜像(例如,Ubuntu)作为后门容器,并通过“kubectl exec”远程运行他们的恶意代码。 - 新容器
攻击者可能会尝试通过部署容器在集群中运行他们的代码。有权在集群中部署 pod或控制器(例如DaemonSet\ReplicaSet\Deployment)的攻击者可以创建新的资源来运行他们的代码。 - 应用程序利用
部署在集群中且容易受到远程代码执行漏洞或最终允许执行代码的漏洞的应用程序,使攻击者能够在集群中运行代码。如果将服务帐户挂载到容器(Kubernetes 中的默认行为),攻击者将能够使用此服务帐户凭据向 API 服务器发送请求。 - 在容器内运行的 SSH 服务器
在容器内运行的 SSH 服务器可能会被攻击者使用。如果攻击者获得容器的有效凭据,无论是通过蛮力尝试还是通过其他方法(例如网络钓鱼),他们都可以使用它通过 SSH 远程访问容器。 - Sidecar 注入
Kubernetes Pod 是一组具有共享存储和网络资源的一个或多个容器。Sidecar 容器是一个术语,用于描述位于主容器旁边的附加容器。例如,服务网格代理在应用程序的 pod 中作为 sidecar 运行。攻击者可以通过向集群中的合法 pod 注入 sidecar 容器来运行他们的代码并隐藏他们的活动,而不是在集群中运行他们自己的独立 pod。
持久性
持久性策略由攻击者用来保持对集群的访问权的技术组成,以防他们失去最初的立足点。
- 后门容器
攻击者在集群中的容器中运行他们的恶意代码。通过使用 Kubernetes 控制器(例如 DaemonSets 或Deployments),攻击者可以确保在集群中的一个或所有节点中运行恒定数量的容器。 - 可写 hostPath 挂载
hostPath 卷将目录或文件从主机安装到容器。有权在集群中创建新容器的攻击者可能会创建一个具有可写hostPath 卷的容器,并在底层主机上获得持久性。例如,后者可以通过在主机上创建一个 cron 作业来实现。 - Kubernetes 定时任务
Kubernetes Job 是一个控制器,它创建一个或多个 Pod,并确保指定数量的 Pod 成功终止。Kubernetes Job 可用于运行为批处理作业执行有限任务的容器。Kubernetes CronJob 用于调度 Jobs。攻击者可能会使用 Kubernetes CronJob 来安排恶意代码的执行,这些代码将作为集群中的容器运行。
- 恶意准入控制器
准入控制器是一个 Kubernetes 组件,它拦截并可能修改对 Kubernetes API 服务器的请求。有两种类型的准入控制器:验证控制器和变异控制器。顾名思义,变异准入控制器可以 修改拦截的请求并更改其属性 。Kubernetes 有一个名为 MutatingAdmissionWebhook的内置通用准入控制器。此准入控制器的行为由用户在集群中部署的准入webhook 确定。攻击者可以使用此类 webhook 来获得集群中的持久性。例如,攻击者可以拦截和修改集群中的Pod 创建操作,并将其恶意容器添加到每个创建的 Pod 中。
权限提升
权限提升策略包括攻击者用来在环境中获得比他们当前拥有的权限更高的权限的技术。在容器化环境中,这可能包括从容器访问节点、在集群中获得更高的权限,甚至访问云资源。
- 特权容器
特权容器是具有主机所有功能的容器,它消除了常规容器的所有限制。实际上,这意味着特权容器几乎可以直接在主机上执行的所有操作。获得对特权容器的访问权限或有权创建新的特权容器(例如,通过使用受感染 pod 的服务帐户)的攻击者可以访问主机的资源。 - 集群管理员绑定
基于角色的访问控制 (RBAC) 是 Kubernetes 中的一项关键安全功能。RBAC 可以限制集群中各种身份的允许操作。Cluster-admin 是 Kubernetes 中内置的高权限角色。有权在集群中创建绑定和集群绑定的攻击者可以创建与集群管理员 ClusterRole 或其他高权限角色的绑定。 - 主机路径挂载
攻击者可以使用 hostPath 挂载来访问底层主机,从而从容器访问到主机。 - 访问云资源
如果 Kubernetes 集群部署在云中,在某些情况下,攻击者可以利用他们对单个容器的访问权来访问集群外的其他云资源。例如,在 AKS 中,每个节点都包含存储在/etc/kubernetes/azure.json中的服务主体凭据。AKS 使用此服务主体来创建和管理群集操作所需的 Azure 资源。
默认情况下,服务主体在集群的资源组中具有参与者权限。访问此服务主体文件(例如,通过 hostPath 挂载)的攻击者可以使用其凭据来访问或修改云资源。
防御规避
防御规避策略包括攻击者用来避免检测和隐藏其活动的技术。
- 清除容器日志
攻击者可能会删除受感染容器上的应用程序或操作系统日志,以试图阻止检测到他们的活动。 - 删除 Kubernetes 事件
Kubernetes 事件是记录集群中资源状态更改和故障的 Kubernetes 对象。示例事件是容器创建、图像拉取或节点上的 pod 调度。
Kubernetes 事件对于识别集群中发生的更改非常有用。因此,攻击者可能想要删除这些事件(例如,通过使用:“kubectl delete events- all”)以避免在集群中检测到他们的活动。 - Pod/容器名称相似度
由 Deployment 或 DaemonSet 等控制器创建的 Pod 在其名称中具有随机后缀。攻击者可以利用这一事实并命名他们的后门 pod,因为它们是由现有控制器创建的。例如,攻击者可以创建一个名为coredns-{random suffix}的恶意 pod ,它看起来与 CoreDNS 部署相关。
此外,攻击者可以将他们的容器部署在管理容器所在的 kube-system 命名空间中。 - 从代理服务器连接
攻击者可能会使用代理服务器来隐藏其原始 IP。具体来说,攻击者经常使用匿名网络(例如 TOR)进行活动。这可用于与应用程序本身或 API 服务器进行通信。
凭证访问
凭据访问策略包括攻击者用来窃取凭据的技术。
在容器化环境中,这包括正在运行的应用程序的凭证、身份、存储在集群中的机密或云凭证。
- 列出 Kubernetes 机密
Kubernetes 机密是一个对象,它允许用户存储和管理敏感信息,例如集群中的密码和连接字符串。可以在 pod 配置中通过引用来使用 Secret。有权从 API 服务器检索机密的攻击者(例如,通过使用 pod 服务帐户)可以访问敏感信息,其中可能包括各种服务的凭据。 - 挂载服务主体
当集群部署在云中时,在某些情况下,攻击者可以利用他们对集群中容器的访问来获取云凭证。例如,在 AKS中,每个节点都包含服务主体凭据。(详见“4:访问云资源”。) - 访问容器服务帐号
服务帐户 (SA) 代表 Kubernetes 中的应用程序身份。默认情况下,SA 会挂载到集群中创建的每个 pod。使用 SA,pod 中的容器可以向 Kubernetes API 服务器发送请求。访问 Pod 的攻击者可以访问 SA 令牌(位于/var/run/secrets/kubernetes.io/serviceaccount/token)并根据 SA 权限在集群中执行操作。如果未启用 RBAC,则 SA 在集群中具有无限权限。如果启用了 RBAC,则其权限由与其关联的 RoleBindings \ ClusterRoleBindings 确定。 - 配置文件中的应用程序凭据
开发人员将机密存储在 Kubernetes 配置文件中,例如 pod 配置中的环境变量。此类行为在 Azure 安全中心监控的群集中很常见。有权访问这些配置的攻击者,通过查询 API 服务器或访问开发人员端点上的这些文件,可以窃取存储的秘密并使用它们。 - 访问托管身份凭据
托管身份是由云提供商管理的身份,可以分配给云资源,例如虚拟机。这些身份用于向云服务进行身份验证。身份的秘密完全由云提供商管理,无需管理凭据。应用程序可以通过访问实例元数据服务 (IMDS) 来获取身份的令牌。访问 Kubernetes pod 的攻击者可以利用他们对 IMDS 端点的访问权来获取托管身份的令牌。使用令牌,攻击者可以访问云资源。 - 恶意准入控制器
除了持久性之外,恶意准入控制器还可用于访问凭据。Kubernetes 中的内置准入控制器之一是ValidatingAdmissionWebhook。与MutatingAdmissionWebhook一样,此准入控制器也是通用的,其行为由部署在集群中的准入 webhook 决定。攻击者可以使用此 Webhook 拦截对 API 服务器的请求、记录机密和其他敏感信息。
发现
发现策略包括攻击者用来探索他们获得访问权限的环境的技术。这种探索有助于攻击者执行横向移动并获得对额外资源的访问权限。
- 访问 Kubernetes API 服务器
Kubernetes API 服务器是集群的网关。通过向 RESTful API 发送各种请求来执行集群中的操作。集群的状态,包括部署在上面的所有组件,可以由 API 服务器检索。攻击者可能会发送 API 请求来探测集群并获取有关集群中容器、机密和其他资源的信息。 - 访问 Kubelet API
Kubelet 是安装在每个节点上的 Kubernetes 代理。Kubelet 负责正确执行分配给节点的 pod。Kubelet 公开了一个不需要身份验证的只读 API 服务(TCP 端口 10255)。对主机具有网络访问权限的攻击者(例如,通过在受感染的容器上运行代码)可以向 Kubelet API 发送 API 请求。具体查询https://[NODE IP]:10255/pods/会检索节点上正在运行的 pod。https://[NODE IP]:10255/spec/检索有关节点本身的信息,例如 CPU 和内存消耗。 - 网络映射
攻击者可能会尝试映射集群网络以获取有关正在运行的应用程序的信息,包括扫描已知漏洞。默认情况下,Kubernetes 中对 Pod 通信没有限制。因此,获得单个容器访问权限的攻击者可能会使用它来探测网络。 - 访问 Kubernetes 仪表板
Kubernetes 仪表板是一个基于 Web 的 UI,用于监控和管理 Kubernetes 集群。仪表板允许用户使用其服务帐户(kubernetes-dashboard)在集群中执行操作,权限由该服务帐户的绑定或集群绑定确定。获得集群中容器访问权限的攻击者可以使用其对仪表板 pod 的网络访问。因此,攻击者可以使用仪表板的身份检索有关集群中各种资源的信息。 - 实例元数据 API
云提供商提供实例元数据服务,用于检索有关虚拟机的信息,例如网络配置、磁盘和 SSH 公钥。虚拟机可以通过只能从虚拟机内部访问的不可路由的 IP 地址访问此服务。获得容器访问权限的攻击者可能会查询元数据 API 服务以获取有关底层节点的信息。
横向移动
横向移动策略包括攻击者用来在受害者环境中移动的技术。在容器化环境中,这包括通过对一个容器的给定访问权获得对集群中各种资源的访问权,从容器获得对底层节点的访问权,或获得对云环境的访问权。
- 访问云资源
攻击者可能会从受感染的容器转移到云环境。 - 容器服务帐号
获得集群中容器访问权限的攻击者可以使用挂载的服务帐户令牌向 API 服务器发送请求,并获得对集群中其他资源的访问权限。 - 集群内部网络
Kubernetes 网络行为允许集群中 pod 之间的流量作为默认行为。获得对单个容器的访问权限的攻击者可以使用它来实现对集群中另一个容器的网络可达性。 - 配置文件中的应用程序凭据
开发人员将机密存储在 Kubernetes 配置文件中,例如,作为 pod 配置中的环境变量。使用这些凭据,攻击者可以访问集群内外的其他资源。 - 主机上挂载可写卷
攻击者可能会尝试从受感染的容器中获取对底层主机的访问权限。 - 访问 Kubernetes 仪表板
有权访问 Kubernetes 仪表板的攻击者可以管理集群资源,还可以使用仪表板的内置“exec”功能在集群中的各种容器上运行他们的代码。 - CoreDNS 中毒
CoreDNS 是用 Go 编写的模块化域名系统 (DNS) 服务器,由云原生计算基金会 (CNCF) 托管。CoreDNS 是Kubernetes 中使用的主要 DNS 服务。CoreDNS 的配置可以通过一个名为 corefile 的文件进行修改。在Kubernetes 中,此文件存储在位于 kube-system 命名空间的 ConfigMap 对象中。如果攻击者拥有修改ConfigMap 的权限,例如使用容器的服务帐户,他们就可以改变集群 DNS 的行为,毒化它,并获取其他服务的网络身份。 - ARP中毒和IP欺骗
Kubernetes 有许多可以在集群中使用的网络插件(容器网络接口或 CNI)。Kubenet 是基本的,在许多情况下是默认的网络插件。在此配置中,在每个节点 (cbr0) 上创建一个网桥,各种 pod 使用 veth 对连接到该网桥。跨 Pod流量通过一个 2 级组件的网桥这一事实意味着在集群中执行 ARP 中毒是可能的。因此,如果攻击者访问了集群中的某个 pod,就可以进行 ARP 毒化,并欺骗其他 pod 的流量。通过使用这种技术,攻击者可以在网络级别执行多种攻击,从而导致横向移动,例如 DNS 欺骗或窃取其他 pod 的云身份。
影响
影响策略包括攻击者用来破坏、滥用或破坏环境正常行为的技术。
- 数据销毁
攻击者可能会尝试破坏集群中的数据和资源。这包括删除部署、配置、存储和计算资源。 - 资源劫持
攻击者可能滥用受损资源来运行任务。一种常见的滥用行为是使用受损资源来运行数字货币挖掘。有权访问集群中的容器或有权创建新容器的攻击者可以将它们用于此类活动。 - 拒绝服务
攻击者可能会尝试执行拒绝服务攻击,从而使合法用户无法使用该服务。在容器集群中,这包括尝试阻止容器本身、底层节点或 API 服务器的可用性。
采集(Collection)
在 Kubernetes 中,采集由攻击者用来从集群或通过使用集群收集数据的技术组成。
- 来自私人注册表的图像
集群中运行的镜像可以存储在私有注册中心中。为了拉取这些镜像,容器运行时引擎(例如 Docker 或containerd)需要具有这些注册中心的有效凭据。
如果注册中心由云托管商提供,则在 Azure Container Registry (ACR) 或 Amazon Elastic Container Registry(ECR) 等服务中,云凭证用于对注册中心进行身份验证。
如果攻击者获得对集群的访问权,在某些情况下,他们可以获得对私有注册中心的访问权并拉取其镜像。例如,攻击者可以使用“访问托管身份凭证”技术中描述的托管身份令牌。同样,在 EKS 中,攻击者可以使用默认绑定到节点的 IAM 角色的 AmazonEC2ContainerRegistryReadOnly 策略。
K8S安全加固
Pod安全策略
Kubernetes Pod 安全策略的例子
apiVersion: policy/v1beta1 kind: PodSecurityPolicy metadata: name: restricted annotations: seccomp.security.alpha.kubernetes.io/allowedProfileNames:'docker/default,runtime/default' apparmor.security.beta.kubernetes.io/allowedProfileNames: 'runtime/default' seccomp.security.alpha.kubernetes.io/defaultProfileName: 'runtime/default' apparmor.security.beta.kubernetes.io/defaultProfileName: 'runtime/default' spec: privileged: false # 需要防止升级到 root allowPrivilegeEscalation: false requiredDropCapabilities: - ALL volumes: - 'configMap' - 'emptyDir' - 'projected' - 'secret' - 'downwardAPI' - 'persistentVolumeClaim' # 假设管理员设置的 persistentVolumes 是安全的 hostNetwork: false hostIPC: false hostPID: false runAsUser: rule: 'MustRunAsNonRoot' # 要求容器在没有 root 的情况下运行 seLinux rule: 'RunAsAny' # 假设节点使用的是 AppArmor 而不是 SELinux supplementalGroups: rule: 'MustRunAs' ranges: # 禁止添加到 root 组 - min: 1 max: 65535 runAsGroup: rule: 'MustRunAs' ranges: # 禁止添加到 root 组 - min: 1 max: 65535 fsGroup: rule: 'MustRunAs' ranges: # 禁止添加到 root 组 - min: 1 max: 65535 readOnlyRootFilesystem: true
增加审计策略
apiVersion: audit.k8s.io/v1 kind: Policy rules: - level: RequestResponse # 这个审计策略记录了 RequestResponse 级别的所有审计事件
云原生安全架构
Istio 安全功能提供强大的身份、强大的策略、透明的 TLS 加密以及身份验证、授权和审计 (AAA) 工具来保护您的服务和数据。Istio 安全的目标是:
- 默认安全性:无需更改应用程序代码和基础架构
- 纵深防御:与现有安全系统集成,提供多层防御
- 零信任网络:在不信任网络上构建安全解决方案
istio 是什么
Istio 提供一种简单的方式来为已部署的服务建立网络,该网络具有负载均衡、服务间认证、监控等功能,而不需要对服务的代码做任何改动。
- istio 适用于容器或虚拟机环境(特别是 k8s),兼容异构架构。
- istio 使用 sidecar(边车模式)代理服务的网络,不需要对业务代码本身做任何的改动。
- HTTP、gRPC、WebSocket 和 TCP 流量的自动负载均衡。
- istio 通过丰富的路由规则、重试、故障转移和故障注入,可以对流量行为进行细粒度控制;支持访问控制、速率限制和配额。
- istio 对出入集群入口和出口中所有流量的自动度量指标、日志记录和跟踪。
Istio 中的安全性涉及多个组件:
- 用于密钥和证书管理的证书颁发机构 (CA)
- 配置 API 服务器分发给代理:
- 身份验证策略
- 授权策略
- 安全命名信息
- 身份验证策略
- Sidecar 和外围代理作为策略执行点 (PEP) 来保护客户端和服务器之间的通信。
- 一组 Envoy 代理扩展来管理遥测和审计