Kubernetes LTS 版本：稳定性与灵活性的平衡 Kubernetes 频繁升级带来的挑战 Kubernetes（K8s）以其快速的发展速度而闻名，但频繁的升级也给运维团队带来了巨大的挑战。虽然 K8s 社区提供广泛的支持，但许多组织发现频繁的升级操作令人难以忍受。 服务中断：升级过程中的错误配置或组件故障可能导致服务中断，给企业造成巨大损失。 抽象而生硬的修复选项：默认的修复选项往往过于抽象，难以理解，导致集群在不知情的情况下升级并中断服务。 团队难以跟进节奏：K8s 的发布周期为 15 周，每个版本支持 14 个月。对于资源有限的中小型团队来说，跟上升级节奏几乎是不可能的。 为何 Kubernetes 需要 LTS 版本 LTS（长期支持）版本是 Kubernetes 稳定版本，旨在为用户提供长期稳定和持续的支持。以下是一些 LTS 版本的好处： 稳定可靠的基础：LTS 版本为用户提供了一个稳定的基础，可以长期使用 Kubernetes，而无需频繁升级。 减少服务中断风险：经过全面测试和验证的 LTS 版本比常规版本更稳定，降低了服务中断的风险。 简化维护：通过减少升级次数，LTS 版本简化了 Kubernetes 集群的维护，释放了团队资源。 LTS 版本的替代方案 虽然 LTS 版本是解决 Kubernetes 升级挑战的理想解决方案，但也有其他替代方案可以考虑： 第三方工具：第三方工具可以帮助验证集群状态并自动执行升级过程。但是，这些工具需要持续维护和更新，增加了额外的复杂性。 新建集群：创建新集群并迁移服务可以避免升级现有的集群。这种方法涉及大量的重复和资源浪费。 让集群落后：团队可以有意让集群落后几个版本，以避免频繁升级。这会带来安全风险，因为落后的版本可能易受已知漏洞的攻击。 LTS 版本的未来 尽管 K8s 社区长期以来一直对 LTS 版本持抵触态度，但企业对稳定性的需求与日俱增。随着 K8s 在关键业务应用程序中变得更加普遍，LTS版本的需求只会增加。 创建和维护 LTS 版本需要大量的资源和协调。社区需要找到一种方法来平衡对稳定性和灵活性的需求，同时保持 K8s 作为创新平台的优势。 结论 Kubernetes LTS 版本对于那些优先考虑稳定性和服务可靠性的组织来说是至关重要的。虽然目前还没有官方的 LTS 版本，但替代方案可以让团队管理 K8s 升级的挑战。随着 K8s 在企业中的采用不断增长，LTS 版本很可能成为未来 K8s 生态系统的重要组成部分。

---

将JVM从JDK11迁移到JDK16的问题

我们的后端网络服务运行在Java SE 11（JDK11）上。JDK11有很多现代化的功能，得到了Oracle和OpenJDK开发团队的长期支持，而且一直非常非常稳定，只有一个例外。内存尖峰管理。我们有一个数据密集型的ETL进程，每天晚上运行。它从我们的数据科学团队的系统中把我们新计算出来的声誉分数加载到MongoDB集合中，以便于实时查询。一个Kubernetes实例对所有实例处理的工作进行排队，使ETL工作并行。我们的客户自然在同一时间安排了一些数据密集型的Reputation Score报告。这造成了内存激增，JDK11的废品收集器除了分配更多的内存外，无法处理。堆经常增长，超过了虚拟机上的可用内存，这导致Kubernetes回收排队的ELT作业的pod，这种数据损失随之而来。

Java SE 16（JDK16）默认启用了Z废品收集器（ZGC）。ZGC在根据需要释放内存方面做得更好，与应用程序并行工作，因此内存高峰得到了缓解。在JDK16下运行pod可以解决这个问题，我们的数据现在每天晚上都能成功加载。

现在我们已经看到了JDK16的强大功能，而且Java SE 17（JDK17）现在已经推出，并有一个长期的支持计划，我们决定将我们的代码库和构建系统迁移到JDK16，以利用它的许多好处。

JDK17，即下一个长期发布的JDK，已经发布。我们计划尽快迁移到JDK17。下面是对我们在过渡期间遇到的问题的总结，以及未来升级的路径。当时使用的框架JDK11、Maven 3.6、Spring Boot 2.4.3、Groovy 2.5 和 3.7。所需的框架版本JDK16、Maven 3.8.1、Spring Boot 2.4.8、Groovy 当时不可用。

JDK 16 安装 操作系统OpenJDK18 现在是 Homebrew 中的默认 OpenJDK。安装JDK16：brew install openjdk@16OpenJDK 是 Ubuntu 中的默认 JDK，可能是预安装的。sudo apt install openjdk-16-jdk openjdk-16-source如果安装了多个 JDK（可能是因为当前工作已经安装了 openjdk-11），请使用 update-alternatives 管理 JDK 版本：

原文：将JVM从JDK11迁移到JDK16的问题 - reputation

什么是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场景特有的 逃逸、横向移动、持久化利用方式，插件化管理。

  下载地址:参考链接