【独家】K8S漏洞报告 | 近期bug fix解读

安全漏洞CVE-2019-1002100

3月2日,kubernetes社区公布了一个中等程度的安全漏洞CVE-2019-1002100。

该漏洞最早由Carl Henrik Lunde发现,并于2月25日在kubernetes发布issue(#74534)。根据描述,具有patch权限的用户可以通过发送一个精心构造的patch请求来消耗apiserver的资源,最终会导致apiserver无法响应其他请求。

具体被构造的请求是一个json-patch类型的patch请求,比如kubectl patch --type json或"Content-Type: application/json-patch+json",大家可以通过构造类似的请求检查自己的apiserver是否有此漏洞。

kubernetes宣布这是一个中等严重程度的漏洞,并且很快发布了修复的版本,包括v1.11.8、v1.12.6、v1.13.4,大家可以升级到对应的版本以修复此漏洞。

当然,如果不想升级kubernetes版本的话,也可以规避掉这个问题。只给可信任的用户发放patch权限就行了。

最后,该漏洞对应的issue和修复pr信息如下,大家可以自行参考学习:

                                                              Scheduler相关bug fix分析

随着kubernetes的成熟,集群规模也越来越大,而在大规模集群中,scheduler似乎越来越成为整个集群的瓶颈。近期的bug fix都有不少是scheduler相关的问题。下面就根据这段时间scheduler相关的bug fix,分析大规模集群中调度器可能出问题的地方。

                                                                             #72754 修复
                                                         unscheduleable pod过多可能的调度问题

该问题的背景是#71486这个issue。加入大规模集群存在很多暂时不能调度的pod,当有事件更新
时,scheduler会将这些pod放到active队列重新进行调度,而新加入的pod也会进入这个队列。这就会导致这个队列过大,这个队列本身是按照pod优先级排列,这样新加入的pod可能会排到同优先级的其他不可调度的pod之后。

由于经常会有事件触发unscheduleable的pod重新调度,这就可能会导致有些pod一直排不到。

针对这个问题的修复方式就是修改优先级队列的排序逻辑,这个过程也经过了两轮优化,最终版本是:

  1. 默认按照pod优先级排序
  2. pod优先级相同的话使用pod的podTimestamp排序,时间越早,优先级越高。

而podTimestamp根据pod生命周期的不同会选择不同的时间标签:

  • 新创建的pod:CreationTimestamp
  • 已经成功调度过的pod:LastTransitionTime
  • 调度失败的pod:LastProbeTime
                                          #73296 防止pod调度到not ready的节点

该问题由issue#72129提出,因为scheduler调度时不再关心node状态(只根据node上的taint调度),而新创建的node虽然状态为not ready,但是没有被打上notready的taint,scheduler可能在节点ready之前就把pod调度到not ready的节点上,这显然不是我们期望的行为。

该bug fix对这个问题的解决方法是,添加一个名为nodetaint的admission controller,这样在节点创建时就会给节点添加一个taint,从而无差别的给新创建的node添加notready的taint。

                                          #73454 添加协程定时
                                 将不可调度的pod移动到active队列

scheduler之前的逻辑,是通过事件触发不可调度的pod移动到active队列重新调度。

这个逻辑在大部分场景下没什么问题,但是在大规模集群中,有可能出现有新的事件触发,但是scheduler没有及时同步这个事件,pod根据之前的信息放入不可调度的队列。而这时候事件已经发生过了,不会触发它重新调度。

这就有一定的概率导致pod可以被调度,但是放到了不可调度队列,又在很长一段事件不会重试。

本bug fix是通过添加一个协程,以1min为间隔,将不可调度队列中的pod放到active队列重新调度。

                                              kubernetes 1.13.2-1.13.4
                                                          bug fix数据分析

本周更新1/11-3/4期间的相关bug fix数据,正好是1.13.2-1.13.4两个版本间的数据。

总体来说,这两个版本更新的内容并不多,总共也才36条bug fix,去第三方云提供商相关的、test相关的,则只有20+条。其中比较严重的bug就更稀缺了。可见kubernetes核心组件已经愈趋稳定。

另外前几天社区公布了一个不大不小的漏洞,具体上文已经分析过了。大家可以根据自己的情况决定是否升级到最新版本。

下面是这段时间值得关注的一些pr,大家有兴趣的话可以自行前往社区查看原始pr学习:

#72754 #73296 #73454 #73562 #73909 #74102

最后,关于具体数据,还是查看图表吧:

bug严重程度统计
近期bug fix数据分析:

原文地址:https://blog.51cto.com/14051317/2359050

时间: 2024-10-16 06:06:07

【独家】K8S漏洞报告 | 近期bug fix解读的相关文章

【独家】K8S漏洞报告 | CVE-2019-1002101解读

kubectl cp漏洞CVE-2019-1002101分析 Kube-proxy IPVS添加flag ipvs-strict-arp 近期bug fix数据分析 --本期更新内容 kubectl cp漏洞 近期kubernetes的kubectl cp命令发现安全问题(CVE-2019-1002101),该问题严重程度比较高,建议将kubectl升级到Kubernetes 1.11.9,1.12.7,1.13.5或1.14.0版本以解决此问题. kubectl cp命令允许用户在容器和主机之

吐槽国内各大公司的漏洞报告平台

现在国内众测平台,越来越多.乌云,估计大家都知道,一提到漏洞平台,差不多瞬间想到的就是乌云吧,其他的也不是,威客众测,补天,TSRC,ASRC,BSRC.Sebug感觉现在都不行了,负面新闻太多了. 现在火的,估计也就是乌云,乌云核心白帽子多,粉多,喷子也多,所以就一直火.威客众测也不错,提交漏洞,还可以赚钱,还合法. 国内外有哪些漏洞信息发布平台? 高质量,更新及时,反应迅速的那种 比如:exploits-db.cve和赛门铁壳安全中心 或者说像乌云之类的安全应急响应平台 国内的主要包括: C

hive0.13权限bug fix

最近线上的hive升级到了0.13,遇到不少问题.权限上面,设置了hive.security.authorization.createtable.owner.grants 在hive0.13中,用户自己创建的表也没有权限.通过对源码的分析和debug找到了rc并fix,下面记录下. 1.首先在hive0.11中和hive0.13中分别做建表测试,通过查看数据库中的元数据,发现在hive0.11中如果设置了owner的参数在表创建之后,用户会有这个表的all的权限(具体可以分析db_privs ,

系统被入侵或收到漏洞报告才去事后补救的方式已然过时

道高一尺,魔高一丈,黑客攻击技术与手法层出不穷,以往的不重视产品自身安全而寄希望于安全防御手段的方式总是疲于应对,处于被动挨打的局面.过去这种在产品设计开发过程中不重视安全,直到收到漏洞报告才去补救的方式,已经难以适应新的攻击形式,比如:同样的漏洞重复出现.低级配置错误.人为设置弱口令等场景屡见不鲜. 只有从设计.开发.部署.运维这些阶段启用安全流程,并借助安全工具和漏洞检测技术提前发现风险,将风险消除在萌芽状态,从源头提高产品的安全性才能最大程度上降低产品所面临的安全风险. 通过安全体系的建立

教育行业漏洞报告平台(Beta)数据爬取分析

解决问题 对教育漏洞提交平台的漏洞相关数据进行分析. 内容与要求 爬取网站提交的漏洞的相关信息,对每年漏洞数量,漏洞类型变化,漏洞类型比例,提交漏洞排名,存在漏洞数最多等方面进行统计分析,并可视化 使用工具 Requests 用于爬取页面 BeautifulSoup用于页面分析 Pandas用于数据分析 Time 用于爬取时进度条显示进度 tqdm用于爬取时进度条显示进度 matplotlib用于数据可视化,绘制统计图 wordcloud 用于数据可视化,绘制云图 爬取数据 网站分析 1.网站为

hive可以drop所有表的bug fix

之前遇到的一个drop table的小问题,默认任何人都可以有使用drop db.table的权限这是一个bug, bugid:https://issues.apache.org/jira/browse/HIVE-2817 解决方法:可以通过设置 set hive.exec.drop.ignorenonexistent=false(Do not report an error if DROP TABLE/VIEW specifies a non-existent table/view, 这个值默

如何有效的报告一个BUG

无意中浏览到了这篇文章 非常感谢作者 这是原文链接 以下为原文: 引言 为公众写过软件的人,大概都收到过很拙劣的bug(计算机程序代码中的错误或程序运行时的瑕疵——译者注)报告,例如: 在报告中说“不好用”: 所报告内容毫无意义: 在报告中用户没有提供足够的信息: 在报告中提供了错误信息: 所报告的问题是由于用户的过失而产生的: 所报告的问题是由于其他程序的错误而产生的: 所报告的问题是由于网络错误而产生的: 这便是为什么“技术支持”被认为是一件可怕的工作,因为有拙劣的bug报告需要处理.然而并

爬虫练习之爬取绿盟漏洞报告的标题与地址

#coding:utf-8 # 作者@in2 #抓取完之后,将页面的编码调整为utf-8即可:) import urllib2,bs4 from bs4 import BeautifulSoup #导入相关模块 h = open('CVE.html','w') #打开CVE.html文件,不存在的话自动新建一个 for pages in range(1,30246): #取页数1到30246 strpage = str(pages) print "当前是第" + strpage +&q

SoYun社工库最新源码以及审计出的漏洞报告信息

本文作者:浅蓝 前段时间有人发过搜云的源码,都好长时间了. 这次我放出个最新的. 是在他换模板之前的源码.(现在的搜云后端基本没什么变化 换了个模板而已) 同时审计出来了一些漏洞.. 我里面的数据库配置信息等重要敏感信息换成了"马赛克" 以下附上审计出的漏洞 1.user.ph#sql注入 265行 $card = $_POST['card']; if ($_POST['card']) {     $sql = "select * from alipay where card