Cloud Native Weekly | Kubernetes 1.13发布

云原生一周精选

1——Kubernetes 1.13发布

2——Kubernetes首次出现重大安全漏洞

3——Docker和微软公司推出云原生应用的部署规范

4——谷歌推出beta版本的Cloud SCC

1 Kubernetes 1.13发布

Kubernetes在上周发布1.13版本，该版本继续关注Kubernetes的稳定性和可扩展性。在这个版本中，用于简化集群管理的kubeadm，容器存储接口（CSI）实现GA，CoreDNS替代kube-dns成为默认DNS。

1.1 使用kubeadm简化集群管理

大多数与Kubernetes亲密接触的人在某些时候都会亲自动手使用kubeadm。它是管理集群生命周期的重要工具，从创建到配置再到升级; 现在kubeadm正式成为GA。kubeadm处理现有硬件上的生产集群的引导，并以最佳实践方式配置Kubernetes核心组件，以便为新节点提供安全而简单的连接流程并支持轻松升级。这个GA版本值得注意的是现在已经毕业的高级功能，特别是可插拔性和可配置性。kubeadm旨在成为管理员和自动化的高级别系统的工具箱，这个版本是朝这个方向迈出的重要一步。

1.2 容器存储接口（CSI）

容器存储接口（CSI）在v1.9中作为alpha版本引入，在v1.10成为beta，在v1.13实现GA。通过CSI，Kubernetes存储变得真正可扩展。这为第三方存储提供商提供了编写与Kubernetes互操作而无需触及核心代码的插件的机会。这个规范本身也达到了1.0的状态。

随着CSI变得稳定，开发者可以按照自己的节奏,以out-of-tree的方式开发存储插件。 您可以在CSI文档中找到样例和产品驱动程序的列表。

1.3 CoreDNS成为默认DNS

CoreDNS在v1.11中实现GA。在v1.13中，CoreDNS替换kube-dns成为Kubernetes的默认DNS服务器。CoreDNS是一个通用的、权威的DNS服务器，提供与Kubernetes向后兼容但可扩展的集成。CoreDNS比以前的DNS服务器具有更少的移动部件，因为它是单个可执行文件和单个进程，并通过创建自定义DNS条目来支持灵活的用例。它也用Go编写，使其内存安全。

CoreDNS现在是Kubernetes 1.13+推荐的DNS解决方案。该项目已将常用测试基础架构切换为默认使用CoreDNS，建议用户进行切换。KubeDNS仍将至少支持到下一个版本，但现在是时候开始规划迁移了。许多OSS安装工具已经进行了切换，包括1.11中的Kubeadm。如果您使用托管解决方案，请与您的供应商合作，以了解这将如何影响您。

1.4 其他值得关注的功能更新

对第三方设备监控插件的支持已经作为alpha功能引入。这将从kubelet中删除当前设备相关的知识，以使将来设备相关的用例变为out-of-tree。

Kubelet设备插件注册逐渐稳定。这创建了一个通用的Kubelet插件发现模型，可以由不同类型的节点级插件（例如设备插件，CSI和CNI）用于与Kubelet建立通信通道。

拓扑感知卷调度现在是稳定的。这使调度器能够识别Pod的卷的拓扑约束，例如zone或node。

APIServer DryRun升级为测试版。这将“应用”和声明性对象管理从kubectl移动到apiserver，以便修复当前无法修复的许多现有bug。

Kubectl Diff升级为测试版。这允许用户运行kubectl命令来查看本地声明的对象配置与活动对象的当前状态之间的差异。

使用持久卷的原始块设备（Raw block device）升级为测试版。这使得原始块设备（非网络设备）可通过持久卷源进行消费。

2 Kubernetes 首次出现重大安全漏洞

Kubernetes出现了一个重大的的特权升级漏洞（CVE-2018-1002105）。攻击者通过构造特殊请求，可以在一个普通权限的链接上提升权限，向被代理的后端服务器发送任意请求。

该问题影响了几乎Kubernetes目前所有的版本，包括：

Kubernetes v1.0.x-1.9.x

Kubernetes v1.10.0-1.10.10 (fixed in v1.10.11)

Kubernetes v1.11.0-1.11.4 (fixed in v1.11.5)

Kubernetes v1.12.0-1.12.2 (fixed in v1.12.3)

2.1 什么样的集群可能被攻击？

集群启用了扩展API server，并且kube-apiserver与扩展API server的网络直接连通；

集群对攻击者可见，即攻击者可以访问到kube-apiserver的接口，如果你的集群是部署在安全的私网内，那么不会有影响；

集群开放了 pod exec/attach/portforward 接口，则攻击者可以利用该漏洞获得所有的kubelet API访问权限。

2.2 具体影响的场景

集群使用了聚合API，只要kube-apiserver与聚合API server的网络直接连通，攻击者就可以利用这个漏洞向聚合API服务器发送任何API请求；

如果集群开启了匿名用户访问的权限，则匿名用户也利用这个漏洞。不幸的是K8s默认允许匿名访问，即kube-apiserver的启动参数”-- anonymous-auth=true”；

给予用户Pod的exec/attach/portforward的权限，用户也可以利用这个漏洞升级为集群管理员，可以对任意Pod做破坏操作；

Kubernetes已发布更新以解决该漏洞（v1.10.11，v1.11.5和v1.12.3）。

更多信息见社区Issue：

https://github.com/kubernetes/kubernetes/issues/71411

 

3 Docker和微软推出云原生应用部署规范

根据微软的新闻稿，微软和Docker联合宣布了一个新项目，旨在创建“一个用于打包和运行分布式应用程序的开源，云无关的规范”。

该项目的名称为云原生应用程序包（Cloud Native Application Bundle，CNAB），为开发人员提供了一种标准方法，可以在许多计算环境中打包和运行容器化应用程序，从工作站上的Docker到云实例中的Kubernetes。

CNAB的规范描述了构成应用程序的“包”或资源组。应用程序包还描述了如何安装，升级或删除应用程序，以及如何在不同环境之间移动应用程序，即使目标环境不在线（例如气隙系统）。微软宣称，即使底层技术本身不支持，也可以对应用程序包进行数字签名和验证。应用程序包可以部署在组织内部，也可以通过现有的分发系统（比如Docker Hub和DockerTrustRegistry）进行部署。

在容器环境中创建应用程序包的技术已经存在，例如Kubernetes的Helm，它描述了如何组合多个容器来定义应用程序堆栈。 CNAB针对的是更为全面的用例集，它不仅适用于Kubernetes，还适用于部署和管理容器的其他系统。

CNAB的另一个既定目标是减少创建应用程序定义所需的工具数量。 CNAB定义可以自动生成特定于部署目标的定义文件（例如，Helm图表或Compose模板），以便用户无需掌握多个工具集即可部署到多个目标。

Docker和微软都计划发布CNAB的开发工具。微软宣布将提供Visual Studio代码扩展，以便更容易创建CNAB包，以及实现CNAB规范的开源示例（“Duffle”）。 Docker打算将CNAB支持添加到Docker App工具的新版本中，以便可以在Docker Enterprise的实例中维护CNAB定义的应用程序。

4 谷歌推出beta版本的Cloud SCC

谷歌近日推出了一项新的测试版本的安全服务，作为信息技术团队的集中门户，统一安全漏洞数据，并在任何损害发生之前对潜在威胁采取行动。

该公司表示，Cloud SCC(Cloud Security Command Center)的测试版的发布使其成为第一家为漏洞和威胁提供“组织级可见性”的公有云提供商。

Cloud SCC于3月份启动alpha版本。当时，谷歌将其描述为云的“安全和风险平台”，通过收集数据和识别潜在威胁，防止它们造成任何损害。通过整合对App Engine，计算引擎，云存储和云数据存储等服务的可视性，它可以帮助管理员了解这些环境中的任何更改并减少未经授权的更改。

Cloud SCC的beta版涵盖了其他服务，包括云数据存储，云DNS，云负载平衡，云量计，容器注册，Kubernetes引擎和虚拟私有云。它还增加了新功能，包括13个新的身份访问管理角色，可用于控制对Google云资源的访问。

“借助Cloud SCC，您可以查看和监控云资产清单，发出安全异常警报，扫描云存储以发现存储敏感数据的位置，检测常见Web漏洞以及查看关键资源的访问权限，所有都通过一个集中的数据平台和仪表盘，Google产品经理Andy Chang在博客文章中写道。

Chang接着解释了可以使用Cloud SCC改善公司安全状况的三种方式。第一种方法是通过识别可公开访问的云存储桶或具有可能暴露给未授权人员的公共地址的虚拟机来发现潜在的安全风险。

Cloud SSC还允许管理员查看和处理对谷歌云平台资产所做的更改。 该服务执行持续的发现扫描，允许用户查看其资产历史记录，以准确了解其环境中发生的变化，并对未经授权的修改采取行动。

Chang表示，Cloud SSC可以与其他安全服务集成，其中包括Google的Data Loss Prevention API，Forseti和Cloud Security Scanner工具，以及来自Cavirin Systems，Cloudflare和Redlock等公司的第三方安全产品。

“通过将合作伙伴解决方案与Cloud SSC集成，您可以在一个地方全面了解风险和威胁，而无需单独使用控制台，”Chang说。