当前位置:首页 > 数码 > K8s-不懂-轻松驾驭-CloudOS-的力量!-K8s (k8s不懂代码)

K8s-不懂-轻松驾驭-CloudOS-的力量!-K8s (k8s不懂代码)

admin7个月前 (05-13)数码34
容器技术的演进与趋势 容器技术概览 容器技术,以 Kubernetes(简称 K8s)为代表,是一种将软件打包和部署在独立、可移植环境中的技术。这种方法为应用程序提供了隔离和资源管理功能,从而简化了部署、扩展和维护。 容器技术在中国的发展阶段 在中国,容器技术经历了三个主要发展阶段: - 婴儿期(2014-2016 年):技术探索期,容器概念初入中国市场。 - 少儿期(2017-2018 年):行业试水期,企业开始试用容器技术。 - 少年期(2019 年至今):规模应用期,容器技术得到广泛采用。 容器技术带来的价值 容器技术的广泛使用已经证明了其价值,主要体现在以下方面: - 简化应用程序部署和管理 - 提高资源利用率 - 提供应用程序隔离和安全性 - 促进微服务架构的采用 - 构建自动化和一致的开发流程 容器技术的发展趋势 1. Kubernetes (K8s) 成为容器技术的实际标准:K8s 已成为容器编排的行业领导者,拥有广泛的支持和采用。 2. 越来越多的企业采用容器云:企业正在利用容器云平台简化容器管理和部署。 3. K8s 从容器编排工具转变为云原生操作系统(OS):K8s 的功能不断扩展,使其成为云原生环境的事实操作系统。 K8s 的复杂性 尽管 K8s 功能强大,但它也以其复杂性闻名,这主要体现在以下方面: - 陡峭的学习曲线 - 市场上 K8s 相关人才短缺 - 项目采用 K8s 的不确定性 - 高昂的项目切换成本 - 需要适应不同的工作模式 实际使用中的棘手问题 除了复杂性之外,在实际使用中,K8s 还会遇到一些棘手的问题,例如: - YAML 配置,开发和运维之间的分工协作 - ConfigMap/Secret 不支持版本控制 - 集群外部端口暴露 - 热更新 - 多 K8s 集群管理 - 集群备份和恢复 - 集群升级 - 资源规划 团队如何迁移至 K8s 对于企业来说,采用 K8s 已是大势所趋。团队迁移至 K8s 的策略应包含以下两个关键点: 1. 渐进式迁移:选择一个新项目,使用 K8s 进行开发和部署,并逐步扩大使用范围。 2. 分工和云原生产品:分工协作,并利用云原生产品来解决 K8s 的复杂性。 渐进式迁移 渐进式迁移包括以下步骤: - 选择一个特定项目和团队 - 采用原生 K8s 或第三方平台 - 在测试环境中部署 - 成功后再扩展到生产环境 分工和云原生产品 利用分工和云原生产品可以解决 K8s 的复杂性,主要方法如下: - 根据职责分工开发、测试和运维任务 - 利用云原生平台或工具简化集群管理、部署和配置 - 通过自动化工具实现持续集成和持续交付(CI/CD)流程 - 采用服务网格(Service Mesh)等技术提升安全性、可观察性和可管理性

Spring Cloud + Nacos + K8S 零影响发布方案

dev环境每次发布都导致服务一段时间不可用,前端同事群里嗷嗷叫,没办法联调了,运维暂时没时间解决,我们自己动手解决。

1、让新的服务先启动起来,注册到注册中心,等待客户端发现新服务。

2、把待下线的服务从注册中心下线,等待客户端刷新服务列表。

3、把待下线的服务优雅停机。

基于K8S滚动升级的机制,当新的POD准备就绪之后,旧的POD会被删除。在删除旧POD之前会调用容器preStop的钩子。

K8S容器本身有一个就绪探针配置,当就绪探针返回正常,则开始删除旧POD。

我们可以使用SpringBoot的 健康 检查actuator作为就绪探针。

核心的配置是initialDelaySeconds,当容器创建到第一次就绪检查的延迟时间。

initialDelaySeconds=服务启动完成耗时+客户端负责均衡刷新服务列表的时间(,默认是30s)。

2、把将要下线的服务从注册中心下线,等待客户端刷新服务列表。

我们要实现一个preStop钩子,把服务从注册中心下线,而且要等待秒时间,等待客户端刷新服务,把当前服务剔除。

我们用的nacos作为注册中心,AbstractAutoServiceRegistration是服务注册的抽象基类,stop方法可以从服务中心下线服务,NacosAutoServiceRegistration是实现类,所以我们只需要调用()即可下线服务。

我们自定义一个deregister的endpoint,让k8s的preStop去调用。

别忘记了要把endpoint注册到BeanFactory中。

最后我们需要定义K8S的preStop钩子

3、把待下线的服务优雅停机

Spring Boot 已经支持优雅停机。

我们需要添加下面的配置,超时需要根据平时请求的耗时来定,可以稍微大一点也没关系。

最后还有一个重要的K8S配置。

terminationGracePeriodSeconds要大于preStop+-per-shutdown-phase,可以设置大一点没什么关系。

快去试试吧。

什么是K8S?

不懂

k8s是什么?

Kubernetes 是一个可移植的,可扩展的开源容器编排平台,用于管理容器化的工作负载和服务,方便了声明式配置和自动化。它拥有一个庞大且快速增长的生态系统。Kubernetes 的服务,支持和工具广泛可用。

为什么现在流行使用容器?

早期: 在物理服务器上面部署应用程序存在资源分配问题,因为其不能在物理服务器中的应用程序定义资源边界,导致应用程序资源利用不足而无法扩展.

后来: 为了解决该问题,引入了虚拟化技术, 虚拟化技术是指允许你在单个物理服务器的 CPU 上运行多个虚拟机,可以让多个应用程序在虚拟机之间进行隔离,具有一定的安全性, 每一个虚拟机就是一台完整的计算机, 在虚拟化硬件之上运行所有组件.

现在: 多数在物理服务器上面部署应用程序都是采kubectl用容器的方式,容器类似于虚拟机,它们都具有自己的文件系统、CPU、内存、进程空间等, 且由于它们与基础架构分离,因此可以跨云和 OS 发行版本进行移植。基于此特点被企业大范围使用.

为什么需要使用k8s容器?

若出现这样一个环境: 在生产环境中如果一个容器发生故障,则我们需要手动去启动另外一个容器,这样的操作是对我们的管理员来说是不太方便的, 若一个容器出现故障,另一个容器可以自动启动容器接管故障的容器,这样是最好的.

k8s就可以实现该效果,Kubernetes 提供了一个可弹性运行分布式系统的框架。 Kubernetes 会满足你的扩展要求、故障转移、部署模式等。

k8s功能: 服务发现和负载均衡, 存储编排, 自动部署和回滚, 自动完成装箱计算, 自我修复, 密钥与配置管理

名词解释

Secret有三种类型:

k8s的组成

k8s是由组件,API,对象等组成.

包含所有相互关联组件的 Kubernetes 集群图如下:

组件

Kubernetes 控制面 的核心是 API 服务器。 API 服务器负责提供 HTTP API,以供用户、集群中的不同部分和集群外部组件相互通信。

对象

Kubernetes对象是Kubernetes系统中的持久实体。Kubernetes使用这些实体来表示集群的状态.

具体来说,他们可以描述:

Kubernetes 架构

Kubernetes 架构由节点,控制面到节点通信, 控制器, 云控制器管理器组成.

master 流程图

节点

节点可以是一个虚拟机或者物理机器,取决于所在的集群配置。 每个节点包含运行 Pods 所需的服务, 这些 Pods 由 控制面 负责管理.

节点上的组件包括 kubelet、 容器运行时以及 kube-proxy。

节点状态

可以使用 kubectl 来查看节点状态和其他细节信息:

kubectl describe node <�节点名称>

一个节点包含以下信息:

控制面到节点通信

控制器

在 Kubernetes 中,控制器通过监控集群 的公共状态,并致力于将当前状态转变为期望的状态。

举个例子: 当前室内温度为20度, 我们通过调节遥控器,使其温度上升至24度, 这20度到24度的变化即为让其从当前状态接近期望状态。

控制器模式分为直接控制和通过API服务器来控制.

云控制器管理器

云控制器管理器是指嵌入特定云的控制逻辑的 控制平面组件。 云控制器管理器允许您链接聚合到云提供商的应用编程接口中, 并分离出相互作用的组件与您的集群交互的组件。

云控制器管理器中的控制器包括:

Kubernetes 安全性

云原生安全

云原生安全4个C: 云(Cloud)、集群(Cluster)、容器(Container)和代码(Code)

云原生安全模型的每一层都是基于下一个最外层,代码层受益于强大的基础安全层(云、集群、容器)。我们无法通过在代码层解决安全问题来为基础层中糟糕的安全标准提供保护。

基础设施安全

Kubetnetes 基础架构关注领域

建议

通过网络访问 API 服务(控制平面)

所有对 Kubernetes 控制平面的访问不允许在 Internet 上公开,同时应由网络访问控制列表控制,该列表包含管理集群所需的 IP 地址集。

通过网络访问 Node(节点)

节点应配置为 仅能 从控制平面上通过指定端口来接受(通过网络访问控制列表)连接,以及接受 NodePort 和 LoadBalancer 类型的 Kubernetes 服务连接。如果可能的话,这些节点不应完全暴露在公共互联网上。

Kubernetes 云访问提供商的 API

每个云提供商都需要向 Kubernetes 控制平面和节点授予不同的权限集。为集群提供云提供商访问权限时,最好遵循对需要管理的资源的最小特权原则。Kops 文档提供有关 IAM 策略和角色的信息。

访问 etcd

对 etcd(Kubernetes 的数据存储)的访问应仅限于控制平面。根据配置情况,你应该尝试通过 TLS 来使用 etcd。更多信息可以在 etcd 文档中找到。

etcd 加密

在所有可能的情况下,最好对所有驱动器进行静态数据加密,但是由于 etcd 拥有整个集群的状态(包括机密信息),因此其磁盘更应该进行静态数据加密。

集群组件安全

容器安全

代码安全

Kubernetes架构常见问题

Kubernetes ATTACK 矩阵

信息泄露

云账号AK泄露

API凭证(即阿里云AccessKey)是用户访问内部资源最重要的身份凭证。用户调用API时的通信加密和身份认证会使用API凭证.

API凭证是云上用户调用云服务API、访问云上资源的唯一身份凭证。

API凭证相当于登录密码,用于程序方式调用云服务API.

k8s configfile泄露

kubeconfig文件所在的位置:

$HOME//config

Kubeconfig文件包含有关Kubernetes集群的详细信息,包括它们的位置和凭据。

云厂商会给用户提供该文件,以便于用户可以通过kubectl对集群进行管理. 如果攻击者能够访问到此文件(如办公网员工机器入侵、泄露到Github的代码等),就可以直接通过API Server接管K8s集群,带来风险隐患。

Master节点SSH登录泄露

常见的容器集群管理方式是通过登录Master节点或运维跳板机,然后再通过kubectl命令工具来控制k8s。

云服务器提供了通过ssh登陆的形式进行登陆master节点.

若Master节点SSH连接地址泄露,攻击者可对ssh登陆进行爆破,从而登陆上ssh,控制集群.

容器组件未鉴权服务

Kubernetes架构下常见的开放服务指纹如下:

注:前六个重点关注: 一旦被控制可以直接获取相应容器、相应节点、集群权限的服务

了解各个组件被攻击时所造成的影响

组件分工图:

假如用户想在集群里面新建一个容器集合单元, 流程如下:

攻击apiserver

apiserver介绍:在Kubernetes中,对于未鉴权对apiserver, 能访问到 apiserver 一般情况下就能获取了集群的权限.

在攻击者眼中Kubernetes APIServer

默认情况下apiserver都有鉴权:

未鉴权配置如下:

对于这类的未鉴权的设置来说,访问到 apiserver 一般情况下就获取了集群的权限:

如何通过apiserver来进行渗透,可参考:攻击kubelet

每一个Node节点都有一个kubelet(每个节点上运行的代理)服务,kubelet监听了,,等端口。

端口,是kubelet与apiserver进行通信对主要端口, 通过该端口,kubelet可以知道当前应该处理的任务.该端口在最新版Kubernetes是有鉴权的, 但在开启了接受匿名请求的情况下,不带鉴权信息的请求也可以使用提供的能力, 在Kubernetes早期,很多挖矿木马基于该端口进行传播.

在配置文件中,若进行如下配置,则可能存在未授权访问漏洞.

/var/bin/kubulet/config/yaml

若端口存在未授权访问漏洞,我们可以直接访问/pods进行查看

根据在pods中获取的信息,我们可以在容器中执行命令

curl -Gks{namespace}/{podname}/{containername} \-d input=1 -d output=1 -d tty=1 \-d command=whoami

上述命令得到websocket地址,连接websocket得到命令结果:

使用wscat工具连接websocket

wscat -c “{websocket}” --no-check

即可得到我们执行命令的结果.

获取token

/var/run/secrets//serviceaccount

然后即可访问kube-api server,获取集群权限

curl -ks -H Authorization: Bearer \ ttps://master:6443/api/v1/namespaces/{namespace}/secrets

攻击kubelet总体步骤如下:

攻击dashboard

dashboard登陆链接如下:

界面如下:

dashboard是Kubernetes官方推出的控制Kubernetes的图形化界面.在Kubernetes配置不当导致dashboard未授权访问漏洞的情况下,通过dashboard我们可以控制整个集群。

默认情况下, dashboard是需要进行鉴权操作的,当用户开启了enable-skip-login时可以在登录界面点击Skip跳过登录进入dashboard.

通过skip登陆的dashboard默认是没有操作集群的权限,因为Kubernetes使用RBAC(Role-based access control)机制进行身份认证和权限管理,不同的serviceaccount拥有不同的集群权限。

但有些开发者为了方便或者在测试环境中会为Kubernetes-dashboard绑定cluster-admin这个ClusterRole(cluster-admin拥有管理集群的最高权限).

为Kubernetes-dashboard绑定cluster-admin 设置如下:

后通过skip登陆dashboard便有了管理集群的权限.

创建Pod控制node节点,该pod主要是将宿主机根目录挂载到容器tmp目录下。

新建一个Pod如下:

通过该容器的tmp目录管理node节点的文件

攻击etcd

Kubernetes默认使用了etcd v3来存储数据, 若能naetcd对内暴露2379端口,本地127.0.0.1可免认证访问. 其他地址要带—endpoint参数和cert进行认证。

未授权访问流程:

攻击docker remote api(Docker daemon公网暴露)

2375是docker远程操控的默认端口,通过这个端口可以直接对远程的docker 守护进程进行操作。Docker 守护进程默认监听2375端口且未鉴权.

当机器以方式启动daemon时,可以在外部机器对该机器的docker daemon进行直接操作:

docker daemon -H=0.0.0.0:2375

之后依次执行systemctl daemon-reload、systemctl restart docker

外部主机使用 即可操作暴露2375端口的主机.

因此当你有访问到目标Docker API 的网络能力或主机能力的时候,你就拥有了控制当前服务器的能力。我们可以利用Docker API在远程主机上创建一个特权容器,并且挂载主机根目录到容器.

检测目标是否存在docker api未授权访问漏洞的方式也很简单,访问路径是否含有ContainersRunning、DockerRootDir等关键字。

攻击kubectl proxy

二次开发所产生的问题

管理Kubernetes无论是使用 kubectl 或 Kubernetes dashboard 的UI功能,其实都是间接在和 APIServer 做交互.

如果有需求对k8s进行二次开发的话,大部分的开发功能请求了 APIServer 的 Rest API 从而使功能实现的。

例如:

  • DELETE类似于这样去调用apiserver, 攻击者若修改namespace、pod和容器名, 那么即可造成越权.

    推荐工具

    Kube-Hunter扫描漏洞

    kube-hunter是一款用于寻找Kubernetes集群中的安全漏洞扫描器

    下载地址:强推)

    CDK是一款为容器环境定制的渗透测试工具,在已攻陷的容器内部提供零依赖的常用命令及PoC/EXP。集成Docker/K8s场景特有的 逃逸、横向移动、持久化利用方式,插件化管理。

    下载地址:参考链接

免责声明:本文转载或采集自网络,版权归原作者所有。本网站刊发此文旨在传递更多信息,并不代表本网赞同其观点和对其真实性负责。如涉及版权、内容等问题,请联系本网,我们将在第一时间删除。同时,本网站不对所刊发内容的准确性、真实性、完整性、及时性、原创性等进行保证,请读者仅作参考,并请自行核实相关内容。对于因使用或依赖本文内容所产生的任何直接或间接损失,本网站不承担任何责任。

标签: CloudOS