ThreatStack:一季度 K8s 安全问题

随着 2020 年第一季度离我们远去,ThreatStack 近日公布了新一期安全报告,介绍了在 AWS 公共部署 Kubernetes 的组织所遇到的最常见的安全问题。该报告建议已部署 Kubernetes 的 IT 组织在使用 AWS EKS 时应解决以下问题:

一些 EKS 负载均衡器被分配了孤立的安全组

  • 问题:充当 EKS 入口控制器的负载均衡器被分配了默认安全组;
  • 建议:虽然 AWS 会在 90 天后自动清除这些权限,但仍建议管理员在不再使用这些负载均衡器后,应及时主动删除它们。

多租户 EKS 网络不匹配

  • 问题:EKS 集群会将 Amazon VPC CNI 插件用于 Kubernetes,从而使其能够代表 AWS 虚拟私有云(VPC)上的 Pod;
  • 建议:除非组织部署了 Calico 网络虚拟化软件实例,否则上述措施并不足以支持 Kubernetes 网络策略。考虑到 CNI 插件映射到 AWS ENI 的方式,CNI 的每个节点只能支持一个安全组。因此当 EKS 在同一节点上调度不相关的 Pod 时,可能会产生问题。

可疑用户通过 aws-iam-authenticator 入侵 EKS

  • 问题:可疑用户下载合法 aws-iam-authenticator 工具后,可通过 AWS CLI 访问 EKS 信息,并进一步深入集群;
  • 建议:在 Kubernetes 面前,大多数云提供商采用的网络安全分担责任方式都存在弱点。企业 IT 团队认为云提供商会负责保护云应用程序,但事实上他们只会保护基础设施,因此目前采用最佳 DevSecOps 实践仍是保障集群安全的一种重要方法。

报告认为,从理论上讲,容器化应用程序更安全,因为删除、替换有漏洞的容器要比修补整个应用容易得多。当然,鉴于容器安全专业知识的复杂性和相对缺乏,目前业内还会面临持续犯错。

2PyTorch 推出基于 K8s 的控制器

近日,机器学习框架 PyTorch 发布 1.5 版本更新,带来了大量功能升级,其中最受瞩目的是两个重磅工具:TorchServe 模型服务框架和 TorchElastic Kubernetes 控制器

据介绍,TorchServe 旨在为大规模部署 PyTorch 模型推理提供干净、兼容性好的工业级路径,它的能力覆盖安全部署、模型管理、模型归档、日志记录等,可以帮助企业更容易地将训练好模型投入到生产中。

TorchElastic 是个被 Facebook 等企业用于内部大规模训练深层神经网路的算法库,为了使用它,企业需要具备资源动态适应能力。此次 PyTorch 推出的 TorchElastic Kubernetes 控制器,可让开发人员快速使用 Kubernetes 集群,轻松创建容错、弹性的分布式训练作业,当新的运算资源上线时,能实现资源的迅速可用且易于扩展。

对于 PyTorch 的这次更新,很多业内人士指出这似乎是 Facebook 联手亚马逊宣战 TensorFlow 的一个举措,而他们的“主战场”正是企业级大型性能 AI 模型框架

谷歌:Istio 会被捐赠给基金会

去年 10 月,谷歌产品经理兼 Knative 指导委员会成员 Donna Malayeri 曾在高层战略公告中明确表示Knative 不会捐赠给任何基金会,引发极大负面反响。当时,前谷歌 Kubernetes 首席工程师 Joe Beda 认为谷歌这一想法也适用于 Istio,并称“这令人失望”。

上周,这一事件迎来反转。谷歌云首席执行官 Thomas Kurian 表示,尽管之前公司暗示过不想捐,但考虑到 Istio 已经成为 Kubernetes 平台的关键组成部分,未来它会被捐赠给某个基金会

Istio 是一种服务网格,用于控制负载均衡、访问控制、指标、日志记录以及服务到服务的通信。它有个相关的项目 Knative,该项目建立在 Istio 的基础上,提供事件和扩展服务。这两个项目均由谷歌赞助,并且都是开源的。

在去年 10 月发生的“拒绝捐赠”风波后,谷歌曾试图对这一决策进行辩解,他们指出 CNCF 诞生于人们不了解 Kubernetes 的时代,它的作用更多是在宣传 Kubernetes 而非管理,因此谷歌保留对 Istio 和 Knative 的运营无可厚非。

但显然这个说法说服不了广大社区开发者,特别是为这两个项目做出重大贡献的其他公司。更雪上加霜的是,作为 Istio 的重要客户,美国空军首席软件官 Nicholas Chaillan 在今年 1 月曾公开表示,如果谷歌不捐赠,今年起美国空军将不得不放弃对 Istio 的支持

因此上周 Thomas Kurian 的声明可以看作是谷歌对社区、开源合作伙伴和客户的一种让步,但由于他拒绝对目标基金会和捐赠时间透露更多内容,很多人猜测谷歌最后会选择一个类似 .NET 的基金会,保留对 Istio 的部分影响力。

本周国外博客推荐

人人都看得懂的 Knative 指南

  • 摘要:在安装了 Knative 和 Gloo 作为网关之后,我决定将我的一个宠物项目移至该集群中,以了解在其上运行一些服务所需的感觉。
  • https://bsideup.github.io/posts/knative_custom_domains/

请不要驱逐我的 Pod:priority & disruption budget

  • 摘要:Pod 优先级、QoS 类和清除策略在 K8s 集群中创建了一个平衡组合。如果添加新对象而不考虑对其他对象的影响,将破坏集群状态的稳定,并可能导致灾难。
  • https://itnext.io/please-dont-evict-my-pod-priority-disruption-budget-e099da7b93d2

Kubernetes API 操作员:为 Istio 微服务应用 API 管理

  • 摘要:服务网格的主要目标是处理内部服务到服务的通信,而 API 网关处理外部客户端到服务的通信。我们需要对服务网格中的微服务应用 API 管理。尽管它们在某些情况下重叠,但是服务网格的重点和 API 管理的重点是不同的。
  • https://hackernoon.com/kubernetes-api-operator-apply-api-management-for-istio-microservices-qs5e3yrq

Kubernetes 节点本地 DNS 缓存

  • 摘要:当时,我正在玩自己的 Kubernetes 集群,并尝试使用 Node Local DNS Cache。这是一款非常酷的软件,它通过在节点本地 DNS 上缓存大多数响应来帮助 DNS 加载,可以解决因 Linux conntrack 争用导致的某些 DNS 请求的 5s 间歇性延迟问题。
  • https://povilasv.me/kubernetes-node-local-dns-cache/

本周 K8s 开源项目推荐

kind-boilerplate

  • 这是一组有用的脚本集,可帮助开发者设置简单集群样板,包括多个节点、ingress 和仪表板。
  • github.com/xantrix/kind-boilerplate?utm_sq=gdl0gawghk

kubenvz

  • 这个工具可充当 kubectl、helm、helmfile 和 kustomize 的版本管理器。
  • github.com/nutellinoit/kubenvz

kube-iptables-tailer

  • 这个工具可以检测 iptables 拒绝的流量,并通过 Kubernetes 事件将相应的信息提供给受影响的 Pod。
  • github.com/box/kube-iptables-tailer

Stolon

  • 这是一个云原生 PostgreSQL 管理器,使用 Kubernetes API Server 作为高可用数据存储来选举领导者。
  • github.com/sorintlab/stolon

kubelive

  • 它重新设计了 kubectl 工具,使其更具交互性。
  • github.com/ameerthehacker/kubelive

helm-kubeval

  • 这是一个 Helm 插件,用于根据 Kubernetes schemas 验证 Charts。
  • github.com/instrumenta/helm-kubeval

2019 年 Go 开发者调查

上周,Go 社区发布 2019 年开发者调查报告结果。此次社区共收到 10975 份回复,较去年增长了近一倍,社区也在调研中设置了许多有关使用者的问题,以更好地了解受访者的画像。

如上图所示,本次调研的大多数受访者使用 Go 不到两年(56%),整体资历较浅,将 Go 用在工作中的比例占所有受访者的 72%,有 62% 的人把 Go 用在工作之外,专业使用 Go 的受访者比例似乎每年都在上升。

官方表示,2018 年将 Go 用在工作或工作外的比例都较前一年大幅增加,但是今年得到的结果与之前不同,更多受访者较倾向在工作外使用 Go,而在工作使用另一种语言。

在使用层面,构建 API/RPC 服务(71%)和 CLI(62%)仍然是 Go 的最常见场景。问卷调查也询问了受访者使用 Go 的领域,到目前为止,最常见的领域是 Web 开发(66%),其他常见的领域包括数据库(45%)、网络编程(42%)、系统编程(38%)和 DevOps 任务(37%)。

对于使用 Go 时设计的开发技术,绝大多数受访者表示他们依赖文本日志进行调试(88%),因为替代工具难以有效使用。本地调试工具、性能分析和使用竞争检测器进行测试也非常长见,约有 50% 的受访者依赖其中至少一种技术。

而对于 Go 的痛点,受访者表示无法使用 Go 的主因(56%)是项目在使用另一种语言,还有一部分是因为团队喜欢使用其他语言(37%),同时 Go 本身也缺乏一些关键功能(25%)。针对关键功能欠缺,有 79% 指出泛型是最受他们关注的缺失功能,22% 的人希望错误处理能持续改进,13% 的人要求更多的函数式编程特性,特别是内置的 map/filter/reduce 功能。

完整调查结果,请见:https://studygolang.com/articles/28217?fr=sidebar

原文请点击:https://mp.weixin.qq.com/s/7aVns5CzJx3t8VJRLIOBxA