Istio v1.9.0 发布

Istio v1.9.0 已于近日发布。该版本是 Istio 在 2021 年发布的第一个版本,侧重于为在生产环境中运行 Istio 的用户改善操作体验。该版本的一些重点更新:

  • VM 集成(Beta 阶段):Istio 社区一直致力于使 VM 中运行的工作负载成为 Istio 服务网格的一部分,能够应用一致的策略,并在容器和 VM 之间收集 telemetry。经过不断的测试,社区在持续提升 Istio 与 VM 集成的稳定性及其文档,在此版本中,Istio 与 VM 集成的特性已提升到 Beta 阶段。
  • 请求分类(Beta 阶段):使网格 telemetry 收集更具可配置性。在此版本中,请求分类功能已提升到 Beta 阶段。该功能可使用户更精准地了解和监控其服务网格中的流量。
  • Kubernetes Service API 支持(Alpha 阶段):自 Istio v1.6 以来,使用 Kubernete Service API 配置 Istio 从而暴露 service 一直有着积极的开发进展。在该版本中,Kubernetes Service API 支持已提升为 Alpha 功能。使用这些 API,那些使用其他服务网格(支持这些 API)的用户将受益。
  • 与外部授权系统集成(实验功能):授权策略现在支持自定义 action,使用户可以更轻松地与外部身份验证系统(OPA、OAuth2 等)集成。该功能目前为实验功能。
  • 使用 gcr.io 镜像 Docker Hub:为了使用户不受 Docker Hub 限速政策的影响,Istio 现将其所有镜像都发布到了 gcr.io/istio-release 仓库。用户可以在安装步骤中选择将仓库设置为 gcr.io/istio-release,以绕过 Docker Hub 下载镜像失败的问题。注意,Docker Hub 仍然是 Istio 安装的默认 hub。
  • Istioctl 更新:Istioctl 工具有了重大更新,可提升用户的故障排查和 debug 能力。关键特性包括:1)新的 verify-install 命令,可通知用户安装配置过程中的错误;2)analyze 的子命令可检查是否使用了不建议使用或 Alpha 级别的注释。
详情见:https://istio.io/latest/news/releases/1.9.x/announcing-1.9/

针对 Kubernetes 的新恶意软件

近日,Unit 42 的研究人员检测到针对 Kubernetes 集群的新恶意软件活动。攻击者通过允许匿名访问的错误配置 kubelet,从而获得初始访问权限。当进入 Kubernetes 集群后,该恶意软件便尽可能在容器间传播,并最终进行加密劫持操作。根据攻击者使用的战术、技术和程序(TTP),这很有可能是 TeamTNT 发起的新攻击。此新恶意软件暂称为 Hildegard。

上图说明了攻击者是如何在进入后,横向移动并最终在多个容器中进行加密劫持。

  1. 攻击者首先利用互联网上不安全的 kubelet,然后搜索在 Kubernetes 节点内运行的容器。在节点 A 中找到容器 1 后,攻击者尝试在容器 1 中执行远程代码执行(RCE)。
  2. 攻击者下载了 tmate 并发出运行命令,从容器 1 向 tmate.io 建立了反向 shell。然后,攻击者通过此 tmate 继续进行攻击。
  3. 攻击者从容器 1 中使用 masscan 扫描 Kubernetes 内部网络,并在 Node B 和 Node C 中找到了不安全的 kubelet。然后,攻击者试图将恶意的加密挖掘脚本(xmr.sh)部署到由这些 kubelet 管理的容器中(容器 2-7)。
  4. 运行 xmr.sh 的容器启动了 xmrig 进程,并建立了一个返回 IRC C2 的 IRC 通道。
  5. 攻击者从其中一个容器(容器 4)创建另一个 tmate 会话。使用反向 shell,攻击者可以执行更多的手动观察和操作。
原文链接:https://unit42.paloaltonetworks.com/hildegard-malware-teamtnt/

如何保护 Kubernetes 安全

随着组织更多地使用容器,他们必须考虑 Kubernetes 的安全性。Kubernetes 有多安全?这是一个简单的问题,但没有简单的答案。在某些方面而言,Kubernetes 是非常安全的。它提供了各种内置的安全工具,并且可以轻松地与第三方安全平台集成。

Kubernetes 安全功能

作为核心平台的一部分,Kubernetes 提供了四种主要的安全工具类型:

  • Pod 安全策略:Kubernetes 提供了一个框架,用于定义 Pod 安全策略。这些策略可以强制执行规则,例如阻止容器在特权模式下运行或阻止它们访问资源。
  • 基于角色的访问控制:Kubernetes 的 RBAC 框架使管理员可以根据资源的角色来配置 Kubernetes 中运行的资源可以执行哪些操作。资源可以是用户,也可以是应用程序或者服务。
  • 网络策略:与 Pod 安全策略一样,网络策略可以定义有关网络上活动的某些限制。它们对于隔离容器和加强 Kubernetes 集群中的内部网络通信很有用。
  • secret 管理:Kubernetes 提供了一个内置的键值存储 etcd,用于存储应用程序可能需要操作的“secret”,例如密码和 SSH 密钥,这些可以被加密。

这些工具共同为管理 Kubernetes 中的安全性和防止某些类型的违规提供了基础。

填补安全漏洞

我们可以使用 Pod 安全策略、RBAC 策略、网络策略和 etcd 来帮助保护 Kubernetes 集群。但这些工具本身不足以保护所有类型的风险。因此,保护 Kubernetes 的安全还要求管理员采取额外的行动,有两种主要的解决方法。

第一是在管理集群和工作流的过程中定义和实施最佳实践。例如,避免将机密数据存储在容器镜像中或信任应用程序自行加密敏感数据等。

第二是利用有助于弥补 Kubernetes 安全漏洞的外部工具。容器镜像扫描将检查容器中是否存在恶意软件,我们可以将它们集成到 CI/CD 中,以便在部署过程中自动扫描容器。

K8s 最难理解的概念是什么?

众所周知,Kubernetes 的学习并不容易。近日有人在 Reddit 上对大家认为最难理解的概念进行了投票,共有 130 人参与。

  • 33 人选择了 Storage (PV、PVCs、SC)
  • 28 人选择了 Scheduling(Taints、Tolerations)
  • 23 人选择了 Services and LoadBalancing

另外,在评论中,不少人表示 CustomResourceDefinitions、operators、Network 同样是难点。大家认为在 Kubernetes 的学习中,什么是最难的呢?

Reddit 讨论链接:https://www.reddit.com/r/kubernetes/comments/l41czg/what_has_been_the_most_difficult_concept_to/

Rust 基金会成立

2 月 8 日,Rust 基金会宣布正式成立。Rust 基金会是一个独立的非盈利性组织,管理 Rust 编程语言及其生态系统,将为管理和开发 Rust 项目的 maintainer 提供支持。Rust 基金会的董事会成员由 5 位来自 AWS、华为、谷歌、微软、Mozilla 的董事和 5 名来自项目领导层的董事组成。

Rust 基金会的成立标志着 Rust 在多个方向的发展迈出了巨大的一步。还有重要的一点是,来自全球行业领先公司的资金投入,代表着 Rust 将成为企业级生产就绪的技术。

详情见:https://foundation.rust-lang.org/posts/2021-02-08-hello-world/

本周 K8s 开源项目推荐

checkov

  • 这是用于基础结构即代码的静态代码分析工具。
  • github.com/bridgecrewio/checkov/

version-checker

  • 它可用于观察集群中运行的镜像的当前版本以及上游可用的最新版本。
  • github.com/jetstack/version-checker

k8s-security-policies

  • 该存储库提供了一个安全策略库,用于保护 Kubernetes 集群配置。
  • github.com/raspbernetes/k8s-security-policies

kubei

  • 这是一个漏洞扫描和 CIS Docker 基准测试工具,它使用户能够对集群进行准确、即时的风险评估。
  • github.com/Portshift/Kubei

kotary

  • 它可以用于管理 Kubernetes 配额。
  • github.com/ca-gip/kotary

porter

  • 这是一个开放源代码的负载均衡器,用于裸机 Kubernetes 集群。
  • github.com/kubesphere/porter