K8S 生态周报| 2019-06-03~2019-06-09

「K8S 生态周报」内容主要包含我所接触到的 K8S 生态相关的每周值得推荐的一些信息。欢迎订阅知乎专栏「k8s生态」。 Kubernetes CVE-2019-11245 漏洞 这是一个评分为 4.9 的漏洞,算是一个中等漏洞。 受此漏洞影响的版本为 v1.13.6 和 v1.14.2 ,所以本周也加紧发布了 v1.13.7 和 v1.14.3 版本,以避免受此漏洞影响。 如果有使用 v1.13.6 和 v1.14.2 版本的小伙伴,请尽快进行 升级 以免受到影响。 上面说了最直接的解决办法,接下来对此漏洞大致做下介绍: 这个漏洞影响了 v1.13.6 和 v1.14.2 版本的 kubelet,具体表现为, 1) 如果 Pod 中的容器,开始时是以某个非 root 用户启动的,但是当它重启后,则会以 root (uid 0) 的身份启动。2) 或者是 Node 节点上已经存在了启动容器所需的镜像。 第 2 个情况比较常见,不再具体介绍。我们来看下第 1 种情况。举个栗子: 通常情况下,如果我们使用 Docker 官方的 Redis 镜像进行部署的时候,默认情况下将会以 redis 用户启动;而如果受此漏洞影响,当容器重启后,则当前的用户可能会变成 root (uid 0) 。使用 root 用户启动服务可能带来的危害,这里也不再多进行展开了。 也存在例外,比如已经显式的通过 runAsUser 指定了运行用户,则不会受到此漏洞影响。

Docker 镜像构建三部曲

我最近在 GitChat 写了一些 Docker 构建镜像相关的文章,这个系列写了三篇,通过这三篇将 Docker 构建镜像相关的事情基本就讲明白了,感兴趣的朋友扫描二维码或者点击链接即可。 高效构建 Docker 镜像的最佳实践 Docker 可谓是开启了容器化技术的新时代,现在无论大中小公司基本上都对容器化技术有不同程度的尝试,或是已经进行了大量容器化的改造。伴随着 Kubernetes 和 Cloud Native 等技术和理念的普及,也大大增加了业务容器化需求。 而这一切的推进,不可避免的技术之一便是构建容器镜像。 在本场 Chat 中,会讲到如下内容: Docker 镜像是什么 Docker 镜像常规管理操作 如何构建 Docker 镜像 逐步分解构建 Docker 镜像的最佳实践 如何提升构建效率 适合人群: 对高效构建 Docker 镜像有兴趣的技术人员 地址:https://gitbook.cn/gitchat/activity/5cd527e864de19331ba79278 进阶:Dockerfile 高阶使用指南及镜像优化 在上次的 Chat 高效构建 Docker 镜像的最佳实践 中,我们重点深入内部介绍了 Docker 镜像是什么;以及构建 Docker 镜像的最佳实践等。 即将发布的 Docker 19.03 版本中 Dockerfile 及构建系统有了很多变化。 在本场 Chat 中,会讲到如下内容: Dockerfile 高阶使用及新特性解读 Docker 19.03 构建系统解读 Docker 镜像安全实践 发现并优化镜像大小 地址:https://gitbook.

K8S 生态周报| 2019-05-27~2019-06-02

「K8S 生态周报」内容主要包含我所接触到的 K8S 生态相关的每周值得推荐的一些信息。欢迎订阅知乎专栏「k8s生态」。 Kubernetes v1.15.0-beta.1 发布 随着 KubeCon EU 的结束,Kubernetes 的开发工作继续回归正常,本周相继发布了 v1.12.9 和 v1.15.0-beta.1。 随着 v1.15 的正式版临近,维护期的 Kubernetes 版本也将变成 1.12~1.15,请尽快升级。 这个版本的变化,等正式版发布时候再进行介绍好了,有兴趣可以先看 ReleaseNote Docker v19.03.0-beta5 发布 按照正常规律 Docker 19.03 正式版也将在近期进行发布,而最近的所有测试版本中,其实变化比较大的东西主要在 构建系统 上;构建系统的升级可以使构建速度更快,同时也增加了更多的安全特性。 这次的 beta5 也是常规修复,有兴趣可以先看 ReleaseNote Docker CVE-2018-15664 安全漏洞 在 5 月 29 日我看到了 CVE 的信息,这个漏洞会影响 Docker 的全部版本,漏洞攻击的主要途径是 docker cp 相关的操作。 但是不必太过紧张,因为这个漏洞的攻击范围其实不算太大;最主要可能被攻击的对象其实是公有云。对于普通用户而言,如果受此攻击,那前提是攻击者已经具备了机器的权限和 Docker 的操作权限(一般用户只要自行控制权限便可避免攻击的发生)。 漏洞发现者 Aleksa Sarai 开始提了一个 PR (他的实现方式是在 docker cp 操作的同时暂停容器),不过现在已经被一个新的 PR 给取代了,毕竟暂停容器意味着停止服务,这是难以接受的。 类似 Podman 之类的其实也存在相同的问题,不过现在也已经被修复了。

K8S 生态周报| 2019-05-20~2019-05-26

「K8S 生态周报」内容主要包含我所接触到的 K8S 生态相关的每周值得推荐的一些信息。欢迎订阅知乎专栏「k8s生态」。 KubeCon EU 举办 2019 年第一个 KubeCon + CloudNativeCon 于 5 月 20 ~ 23 日在巴塞罗那成功举办,这次大会吸引了七千多名参会者远超去年的参会人数。 这也从另一个侧面反映了 Kubernetes 和云原生在大大的普及 在大会上宣布了不少值得关注的信息, 我在此大致列一下我认为值得关注的信息(虽然有些内容之前已经关注到了): OpenTracing, OpenCensus 合并为 OpenTelemetry; 微软推出 Service Mesh Interface(SMI)规范; NGINX Ingress Controller 发布 1.5.0 版本; Google 宣布 GKE 将会支持 Windows Server Container; Helm 3 的发展历程;(推荐阅读我之前写的 初试 Helm 3) 当然,大会上公布的信息还有很多,还有一些 CNCF 的计划等,这里暂且不提,感兴趣的朋友可以自行搜索或者参加下个月在上海举办的 KubeCon + CloudNativeCon 微软推出 Service Mesh Interface (SMI) Service Mesh 也是一个趋势,但现在并没有一个统一的规范,各个厂商的实现也都各有不同。微软本次提出的 SMI 主要是为 Kubernetes 服务网格提供通用接口,以便能让 Service Mesh 有更加通用的规范 (就像当初 CNI/CRI 那样子)

云原生应用开发新体验:Kui

云原生(Cloud Native)应用是伴随着 Kubernetes 应用范围的扩大,基于云模型而提出的一种概念。 本文来介绍一个云原生应用开发的工具 Kui, 这是一款由 IBM 开源的工具,使用 Electron 提供 GUI 能力。 Kui Shell offers a new development experience for building cloud-native applications. By combining the power of familiar CLIs with visualizations in high-impact areas, Kui enables you to manipulate complex JSON and YAML data models, integrate disparate tooling, and provides quick access to aggregate views of operational data. 正如以上介绍中提到的,Kui 提供了一种新的开发体验(原先大多数时候我们是通过 kubectl 与 Kubernetes 中的资源进行交互),Kui 结合了原有 CLI 的强大功能,并提供一种可视化的方式,方便我们对 Kubernetes 中 YAML 或者 JSON 格式数据的处理。

K8S 生态周报| 2019-05-13~2019-05-19

「K8S 生态周报」内容主要包含我所接触到的 K8S 生态相关的每周值得推荐的一些信息。欢迎订阅知乎专栏「k8s生态」。 kind v0.3.0 正式发布 kind (Kubernetes In Docker) 是我很喜欢并且一直持续参与贡献的项目,本周发布了 v0.3.0 版本。关于 Kind 的介绍和基础使用,可以参考我之前写的文章 《使用 Kind 搭建你的本地 Kubernetes 集群》 本次的发布主要侧重于加速集群的启动速度及提高稳定性,优化镜像大小,以及对网络的优化和一些 bugfix 等;其中最主要的内容是将默认的 CRI 从 Docker 换成了 Containerd,以此可以缩小镜像体积,以及加快集群的启动。 v0.3.0 版本中,可以通过配置文件自行部署不同的 CNI,更有利于用户测试实际的集群情况;现在版本中已经将默认的 Kubernetes 版本升级到了最新的 v1.14.2 。 当然,也还有一些正在增加的特性,预计会在 v0.4.0 版本中发布,主要集中于 IPv6 和集群重启的支持(相信很快就可以完成了)。 顺便公布一个数据,Kind 目前的 star 数是 1.8k 还在持续增长中 :) 更多的细节和信息请参考 ReleaseNote Kubernetes v1.14.2 正式发布 这是一个常规的 bugfix 版本,但有个值得关注的点: 升级到了 golang v1.12.5 版本。 你可能要问为什么需要关注 golang 版本的升级?这是因为在此版本中 golang 有一些关于运行时的修改,尤其是其中关于二叉树查找部分的修改等部分的修改,可有效的降低 Kubernetes API server 的延迟。

初试 Helm 3

经过了长时间的开发,Helm 3 终于在今天发布了第一个 alpha 版本。本文将简单介绍 Helm 3 新特性。 移除 Tiller Helm 2 是 C/S 架构,主要分为客户端 helm 和服务端 Tiller; 与之前版本相同,Helm 3 同样在 Release 页面提供了预编译好的二进制文件。差别在于原先的二进制包下载下来你会看到 helm 和 tiller 。而 Helm 3 则只有 helm 的存在了。 Tiller 主要用于在 Kubernetes 集群中管理各种应用发布的版本,在 Helm 3 中移除了 Tiller, 版本相关的数据直接存储在了 Kubernetes 中。 现在我们直接在一个新创建的集群上来使用 Helm。测试集群的创建可以参考我之前的文章 使用 Kind 搭建你的本地 Kubernetes 集群。 与之前版本相同,我们需要先执行 helm init 来进行初始化。但现在的初始化就简单了很多,不再需要给集群中部署 Tiller 了 (MoeLove) ➜ ~ export HELM_HOME=/tmp/helm3 (MoeLove) ➜ ~ helm3 init Creating /tmp/helm3/repository Creating /tmp/helm3/repository/cache Creating /tmp/helm3/plugins Creating /tmp/helm3/starters Creating /tmp/helm3/cache/archive Creating /tmp/helm3/repository/repositories.

K8S 生态周报| 2019-05-06~2019-05-12

「K8S 生态周报」内容主要包含我所接触到的 K8S 生态相关的每周值得推荐的一些信息。欢迎订阅知乎专栏「k8s生态」。 Alpine Linux Docker 镜像漏洞 CVE-2019-5021 本周比较吓人的是 CVE-2019-5021, 根据漏洞报告,自 Alpine Linux 3.3 版本开始的所有 Docker 镜像中,root 用户包含一个空密码,这可能会导致攻击者获得 root 权限,今儿造成攻击。 报告中称:受影响范围是 Alpine Linux Docker 镜像 3.3、3.4、3.5、3.6、3.7、3.8、3.9、edge 等全部版本。 要知道由于 Alpine Linux 镜像体积较小,所以在构建 Docker 镜像时,很多人都会推荐使用 Alpine Linux 作为基础镜像;包括很多 Docker 官方镜像也基本上都提供了基于 Alpine Linux 的镜像,甚至像 Docker 镜像等是只提供了使用 Alpine Linux 作为基础镜像的版本。 当前漏洞已经修复,更多内容请阅读 关于 Alpine Docker 镜像漏洞 CVE-2019-5021 。 istio-operator 发布 0.1.12 版本 banzaicloud/istio-operator 发布 0.1.12 版本,默认已支持 istio 1.1.5 。(虽然截至目前 istio 发布了 1.

关于 Alpine Docker 镜像漏洞 CVE-2019-5021

关于 CVE-2019-5021 带来的一点思考。 本周比较吓人的是 CVE-2019-5021, 根据漏洞报告,自 Alpine Linux 3.3 版本开始的所有 Docker 镜像中,root 用户包含一个空密码,这可能会导致攻击者获得 root 权限,进而造成攻击。 报告中称:受影响范围是 Alpine Linux Docker 镜像 3.3、3.4、3.5、3.6、3.7、3.8、3.9、edge 等全部版本。 要知道由于 Alpine Linux 镜像体积较小,所以在构建 Docker 镜像时,很多人都会推荐使用 Alpine Linux 作为基础镜像;包括很多 Docker 官方镜像也基本上都提供了基于 Alpine Linux 的镜像,甚至像 Docker 镜像等,是只提供了使用 Alpine Linux 作为基础镜像的版本。 报告一出,瞬间这个消息就被传播成了 “Alpine Linux Docker 镜像不安全”/“不要再使用 Alpine Linux 了”。当然 Google 的开发者也顺便推了一次自家的 distroless 镜像。 我们来看一下 CVE-2019-5021 到底是什么以及如何复现吧。 CVE-2019-5021 (MoeLove) ➜ ~ docker run --rm -it alpine:3.9 / # grep root /etc/passwd root❌0:0:root:/root:/bin/ash operator❌11:0:operator:/root:/bin/sh / # grep root /etc/shadow root:::0::::: / # 以上是一个 alpine:3.

K8S 生态周报| 2019-04-28~2019-05-05

「K8S 生态周报」内容主要包含我所接触到的 K8S 生态相关的每周值得推荐的一些信息。欢迎订阅知乎专栏「k8s生态」。 Docker Hub 只读维护 在上周的推送中,有写到 Docker Hub 用户隐私数据泄漏。受此事件影响,5 月 4 日 Docker Hub 进行升级维护,在此期间 Docker Hub 有一段时间处于只读模式,包括自动构建等服务不可用;在最后有小于 15 分钟的完全宕机时间,服务完全不可用。 如果只是看事情表面的话,可能这就是一个由于发现“安全问题”而进行的升级/维护;但如果仔细考虑下,作为云原生服务,升级为何会有宕机的情况,为何会有服务完全不可用的时候? 摘录一段来自本次维护的公告内容: Q: Is this maintenance related to recent Docker Hub data breach? A: While we discovered unauthorized access to a single Hub database storing a subset of non-financial user data last week, which has since been remediated, we are always looking at ways to improve and enhance our security practices to protect our customers and their data.