CNCF 发布第二季度技术雷达

近日,CNCF 发布了第二季度的 End User Technology Radar(最终用户技术雷达),此次 Technology Radar 的主题是可观察性

最终用户社区是一个由 140 多家顶级公司和初创公司组成的小组,他们定期讨论采用云原生技术时的挑战和最佳实践。CNCF 最终用户技术雷达的目标是共享最终用户正在积极使用的工具、推荐的工具以及相应的使用方式。在 2020 年 8 月,最终用户社区的成员做了“评估”“试用”以及“采用”的可观察性解决方案调查,以下是调查结果:

  • “ADOPT”(采用)中的五种工具是被广泛采用和推荐的。
  • “TRIAL”(用)中的技术被部分用户推荐,但没有得到广泛的“采用”票。
  • “ASSESS”(评估)中的项目缺乏明确的共识,虽然 OpenTelemetry、Kiali 和 Thanos 具有广泛的知名度,但只有少数用户建议采用。

以下是各项技术的得票数:

总体而言,总票数最多的五个工具是 Prometheus、Grafana、Elastic、Jaeger、OpenTelemetry,它们都是开源项目,而其中采用率最高的监视工具是 Prometheus、Grafana 和 Elastic。该结果表明,采用 Kubernetes 的 IT 团队比较偏向于开源工具。另外,该报告还指出,一半的受访者正在使用五个或更多工具来监控 Kubernetes 环境,三分之一的受访者具有使用十个或更多工具的经验。三分之二的受访者表示,他们正在使用 Grafana 以更好地可视化 Prometheus 收集的数据。

地址:radar.cncf.io/

Weave Scope 被用于攻击云环境

近日,网络犯罪团伙 TeamTNT 将合法的 Weave Scope 软件添加到其攻击工具包中,用于全面控制受害者的云基础架构。根据网络安全公司 Intezer 和 Microsoft 发布的最新报告,这可能是 Weave Scope 首次被用于基于云的攻击中

Weave Scope 是适用于 Docker、Kubernetes、分布式云操作系统(DC/OS)的开源可视化和监控软件,可以使用户通过专用界面观察云环境中容器运行过程和网络连接情况。该软件还允许管理员以 root 身份在集群中运行 Shell,并且默认情况下不需要身份验证。

有关研究人员解释了该事件的攻击流,TeamTNT 是通过一个公开的 Docker API 趁虚而入的。他们由此创建了一个 Ubuntu 容器,该容器被配置成可安装在受害者的服务器上,进而访问主机上的文件。然后,攻击者利用提升的权限设置了一个名为“hilde”的本地用户,并使用该用户通过 SSH 连接至服务器,后续安装了 Weave Scope 以进行下一步攻击。借助服务器上的这个实用程序,TeamTNT 可以通过 HTTP 经由端口 4040(Scope 应用程序端点的默认端口)连接至 Weave Scope 仪表板,从而获得控制权。

Intezer 在一份报告中指出:“攻击者安装该工具是为了直观地呈现受攻击的云环境,并执行系统命令,无需在服务器上部署恶意代码。”研究人员表示,如果关闭了 Docker API 端口或实施了受限访问策略,就可以避免这种攻击

K8s 三个开放标准实现技巧

现在 Kubernetes 运行着 86% 的容器集群,已成为云原生基础设施的事实标准。这意味着 IT 部门最要关心的不是 Kubernetes 是否有未来,而是确保要如何使用好 Kubernetes。对此,开放标准整合了开发人员对于 Kubernetes 的最佳实践,遵循该标准可以帮助团队避开意外的实施障碍,并确保 DevOps 团队顺利的学习过程。为此,组织在开放标准和 Kubernetes 实施方面应了解几件事:考虑现有标准的性质和限制、避免组织内的标准分散化以及开源社区合作制定、维护这些标准

了解现有标准

有两个组织负责设定主要的开放标准,以管理 Kubernetes 和容器的使用,并被大多数供应商和开发人员认可。第一个是开放容器计划(OCI),它为容器开发了 Runtime 和镜像规范,规范了如何包装和启动容器。确保容器符合 OCI 是运行容器集群的第一步。第二个是CNCF(Cloud Native Computing Foundation),该组织致力于培养云云原生社区,并且负责 Kubernetes 一致性认证计划(Certified Kubernetes Conformance Program),该认证会对产品进行测试,以确保它们符合 Kubernetes 发行标准。

避免标准分散

要确保 Kubernetes 部署符合开放标准,这需要团队对自己的部署有一个共识。很多组织犯下的常见错误就是部署了多个与标准不一致的 Kubernetes 堆栈。这一方面会导致处理不同堆栈的团队分散,另一方面由于差异,很难确保实施和维护通用标准。

参与 Kubernetes 开源社区

Kubernetes 是一个开源项目,OCI 和 CNCF 制定的标准来自于整个开源社区的讨论。这意味着了解社区中正在讨论的内容以及开发人员要解决的问题是掌握建立 Kubernetes 及其生态系统标准的关键。另外,通过参与开源社区,组织开源帮助制定 Kubernetes 标准,与更广泛的社区分享经验和见解,为改善标准作出贡献。

K8s 应用程序访问控制 5 种方法

随着 Kubernetes 采用率的增加,开发人员也需要更安全的访问控制和身份验证,以保护容器化应用程序,让我们来看一下实现身份验证保护的一些有效方法,以及如何与 Kubernetes 集成。

身份验证方法选项

LDAP

许多企业都有使用目录服务存储用户和其他组织信息的丰富经验。这样的系统大多遵循开放的轻型目录访问协议(LDAP)的协议标准。将应用程序与 LDAP 身份验证集成在一起,即可通过 IT 部门管理的信息进行无缝的用户验证。此外,LDAP 还允许基于特定的策略来实施访问控制。

OAuth 2.0

没有统一的身份验证解决方案,可能会使用户登录多个唯一帐户以访问第三方 Web 应用程序。为了解决此问题,OAuth 2.0 可以利用现有的身份提供者(例如 Google 帐户)来实现身份验证,同时还控制与第三方应用程序共享的数据。

JSON Web 令牌(JWT)

JSON Web 令牌已成为一种流行的身份验证方法,尤其是与 API 一起使用。JSON Web 令牌是 Base64URL 编码的 JSON 对象,它由标头 JSON 对象、有效荷载 JSON 对象和签名哈希串联而成。

相互 TLS

TLS 身份验证对于 Web 应用程序而言非常普遍。证书使网站和 Web 服务能够向客户证明其身份。使用双向 TLS 时,这种身份验证就能双向进行。

身份验证与 Kubernetes 应用程序集成

Kubernetes 在实现身份验证方法时提供了极大的灵活性,通过使用入口控制器(Ingress Controller)和认证服务器(Authentication Server)可以解决大多用例。

入口控制器(Ingress Controller)

如今,大多数开发人员都通过入口控制器与 Kubernetes 中的应用程序连接。特定的控制器需要不同的实现方式,开发人员要谨慎选择,比如要注意查看特定入口控制器支持的身份验证方法。

认证服务器(Authentication Server)

将正确的入口控制器与专用的认证服务器配合使用可以有效扩展 Kubernetes 中的应用程序身份验证功能。

本周 K8s 开源项目推荐rafter

  • 它可以用于存储和管理不同类型资产、文件。
  • github.com/kyma-project/rafter

kubekutr

  • 它可以通过自定义的 GitOps 目录结构来快速构建 Kubernetes 资源清单的配置。
  • github.com/mr-karan/kubekutr

kubectl-tree

  • 这是一个 kubectl 插件,可以将 Kubernetes 对象层次结构设置为树状
  • github.com/ahmetb/kubectl-tree

powerfulseal

  • 这是用于 Kubernetes 集群的强大测试工具,它会给 Kubernetes 集群增加了混乱以帮助我们尽早发现系统中的问题。
  • github.com/powerfulseal/powerfulseal

kubespy

  • 这是一个实时观察 Kubernetes 资源的工具。
  • github.com/pulumi/kubespy

wild-west-kubernetes

  • 这是一个用 Spring Boot 和 Phaser 游戏引擎编写的有趣应用程序。
  • github.com/gshipley/wild-west-kubernetes

Visual Studio Codespaces 将关闭 

近日,微软宣布 Visual Studio Codespaces 即将停止支持,其功能将被整合到 GitHub 5 月发布的 Codespaces 服务中。现在 Visual Studio Codespaces 用户可以申请搬到 GitHub Codespaces,而 Visual Studio Codespaces 将在 2021 年 2 月停止服务

对于此次产品关闭的原因,微软方面称:“仓库到代码空间的过渡是工作流程中最关键的一环,而且绝大多数人都喜欢丰富的集成、原生、一键式体验。GitHub 是 5000 万开发者的乐园,因此选择与他们合作解决这一问题。通过将当前的 Codespaces 体验进行整合,可以为用户简化体验,并更快速地解决客户反馈。”