Gitee 和 Linux 基金会达成合作

近日,Linux 基金会和 Gitee 达成合作关系,将逐步在 Gitee 建立基金会旗下项目的官方镜像,让国内开发者更近距离的认识和了解 Linux 基金会旗下项目,并参与其开源社区交流。在未来,会有更多 Linux 基金会项目在 Gitee 建立官方镜像,最终完成全部项目的官方镜像建立工作。首期在 Gitee 建立官方镜像的项目是边缘计算项目 Baetyl 和工业物联网边缘计算框架 EdgeX Foundry。

Baetyl 是 Linux Foundation Edge 旗下的边缘计算项目,旨在将云计算能力拓展至用户现场。提供临时离线、低延时的计算服务,包括设备接入、消息路由、数据遥传、函数计算、视频采集、AI推断、状态上报、配置下发等功能。

项目地址:gitee.com/baetyl

EdgeXFoundry 是一个面向工业物联网边缘计算开发的标准化互操作性框架,部署于路由器和交换机等边缘设备上,为各种传感器、设备或其他物联网器件提供即插即用功能并管理它们,进而收集和分析它们的数据,或者导出至边缘计算应用或云计算中心做进一步处理。

项目地址:gitee.com/EdgexFoundry

K8s 自动扩缩容 KEDA v2.0 发布

一年前,Kubernetes 自动扩缩容 KEDA v1.0 发布,近日官方发布了 KEDA v2.0,以支持更多种类的触发器,更方便地自动扩展 Kubernetes Deployment。

KEDA 旨在解决 Kubernetes 自动扩展的需求。Kubernetes 虽然提供了一个容器调度平台,但在默认的情况,Kubernetes 只能根据 CPU 和内存等系统指标进行扩展,而忽略了来自 Redis 和 Kafka 等外部指标,这代表系统回应事件可能存在延迟,导致扩展不够灵敏。KEDA 能够解决这个问题,KEDA 是一个以 Kubernetes 为基础的事件驱动自动扩缩容,用户可以根据需要处理的事件数量,来驱动 Kubernetes 中容器的扩展。通过使用简单一致的 API,KEDA 就能进行自动扩展 Deployment。

现在官方发布 v2.0,更新重点在于支持更多的触发器,也增加了许多新模式和新功能。KEDA v2.0 现在可以自动扩展 Deployment 负载和作业(Jobs)工作负载。今年 3 月 KEDA 项目发起厂商决定将 KEDA 捐献给 CNCF。KEDA 现为 CNCF 沙盒项目,官方预计在今年稍晚或是明年初,KEDA 将会进入孵化项目。

项目地址:github.com/kedacore/keda/tree/v2.0.0-beta

Helm v3.4 正式发布

Helm v3.4是一个特性更新版本,以下是版本更新的几个重点:

  • 11 月 13 日, Helm stable 和 incubator 仓库将到达终结日,这些 Chart 的归档将会存储到另外的位置,如果使用这两个仓库的话,Helm 将会先检查原先的位置,然后进行重定向。
  • #8543 helm lint 将检查名称长度的错误。
  • #8529 helm status 新增 --show-desc 参数,可用来展示描述。
  • #8874 让 helm create 创建的 chart 缩进保持一致。
  • #7970 helm lint 现在也可以检查依赖了。
  • #8438 helm show values 增加 jsonpath 输出的支持。
  • #8613 优化了 service ready 的判断逻辑,改成了判断是否有 ClusterIP。

更多版本更新可查看 ReleaseNote:github.com/helm/helm/releases/tag/v3.4.0

容器镜像安全 5 种最佳实践

大多数组织都知道,越早将安全性集成到开发过程中,应用程序在生产中就越安全。对于容器化的工作负载,在整个应用程序生命周期中确保容器镜像的安全是至关重要的部分,但是许多组织甚至没有遵循基本容器镜像安全做法。下面是五个最佳实践,专门针对确保容器镜像在整个应用程序生命周期中尽可能安全。

在生命周期的每个阶段嵌入镜像扫描

镜像扫描不是一次可以完成并从安全列表中检出的东西,相反,组织应在应用程序生命周期中尽可能合并镜像扫描,包括:

  • 生成镜像时,在 CI/CD 管道中。
  • 镜像在仓库中。
  • 连续运行镜像时。

管道和注册表中的内联扫描还可以提供更好的安全性和控制力,只需在环境中进行本地扫描,而无需在外部共享镜像内容或注册表凭证。

不要以根目录运行镜像

今年夏天 Sysdig 发布了《2020 容器安全快照》,调查发现58% 的镜像都以 root 用户身份运行。以根用户身份运行镜像是最简单的,但非常危险。如果镜像以 root 用户身份运行,意味着代码将以 root 用户身份运行,具有 root 访问权限的攻击者可以在容器内执行恶意进程。尽管内核隔离可以阻止攻击者使用 root 用户特权来访问基础结构的其他部分,但不能阻止攻击者通过网络利用那些服务。

扫描 OS 和非 OS 软件包

关于容器安全性的一个常见误解是仅需要扫描操作系统程序包,这是不正确的,容器中运行的所有内容,无论是开源的还是商业的,OS 还是非 OS 的,都需要进行扫描,因为 OS 和非 OS 软件包中都可能发现漏洞,并且攻击者可以利用该漏洞。

注意镜像来源

来自公共存储库的镜像本质上不如私人存储库的镜像安全。例如,Docker Hub 仅认证了其近 300 万个托管镜像中不足 1% 的部分。容器镜像具有许多层,如果镜像的任何一层中包含漏洞,都可能发生安全问题。不过全面禁止使用公共存储库也不是一个好主意。实际上,从公共存储库中提取镜像时,我们必须注意有多少人在使用它:被提取三次的镜像比被使用了 2000 万次的镜像风险要大得多。

保持镜像尽可能小

在安全性方面,镜像越小越好。从安全角度来看,理想的情况是运行单个进程的镜像。组织最好删除不需要的镜像,尽量使用静态链接,减少使用动态库或配置文件,这样可以尽可能减少攻击面。

CyberArk 披露 K8s 安全问题

CyberArk 近日发布了一份报告,详细介绍了网络犯罪分子如何利用连接 Kubernetes Pod 的容器网络接口(CNI)的弱点。

具体来说,诸如地址解析协议(ARP)中毒和 DNS 欺骗之类的攻击技术都针对 CNI 插件。这些攻击表明,攻击者有可能绕过 Kubernetes 环境中对网络功能的操纵,从而绕过不同的 Kubernetes 集群安全控制,例如用于设置 Linux 防火墙实用程序和对节点操作系统进行加固的 iptables 规则。CyberArk 安全研究团队负责人 Nir Chako 表示,使用这些技术,可以从 Kubernetes 工作节点上的 Pod 发起 DNS 欺骗攻击。该攻击媒介冒充了 DNS 服务器,并对从同一工作节点上的 Pod 发送的 DNS 查询返回错误答案。攻击者可以将 Pod 的通信与所需的域定向到他们选择的 IP 地址。此攻击要求攻击者操纵数据包。我们可以从应用程序中删除 NET_RAW 功能,这将阻止攻击者使用原始套接字。另一个选择是使用 iptables 设置防火墙配置,该配置不允许将 DNS 响应从非 DNS 服务器的 Pod 传输到另一个 Pod。针对 CNI 插件的第二类攻击是利用网络覆盖(例如 VXLAN)通过从 Pod 删除 NET_RAW 功能,在 Pod 的设备上添加反向路径过滤并规避网络防火墙策略来绕过安全策略。这些攻击很难检测到,因为跨这些网络传输的数据包通常是加密的。

Chako 表示这些问题可能不会减慢 Kubernetes 的采用速度,但是它们肯定会给 IT 安全团队带来许多新的挑战,我们需要对此做好准备。

本周 K8s 开源项目推荐

gitkube

  • 这是用于使用 Kubernetes git push 构建和部署 Docker 镜像的工具。
  • github.com/hasura/gitkube

kopf

  • 它是是一个 Python 框架可通过几行 Python 代码编写 Kubernetes operator。
  • github.com/nolar/kopf

k8s-security-policies

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

shell-operator

  • 这是用于在Kubernetes集群中运行事件驱动脚本的工具。
  • github.com/flant/shell-operator

kubectl-build

  • 它可以在 Kubernetes 集群中构建 dockerfile。
  • github.com/kvaps/kubectl-build

couler

  • 它旨在提供一个统一的界面,用于在不同的工作流引擎(例如 Argo Workflows、Tekton Pipelines 和 Apache Airflow)上构建和管理工作流。
  • github.com/couler-proj/couler