云计算安全+

2019年4月容器技术及安全动态


发布时间 2019-05-15  


1. Linkerd 2.3正式发布



Linkerd 2.3正式发布,为Kubernetes提供零接触、零信任网络,标志着mTLS已经由实验环境正式成长为一项全面支持功能,同时带来一系列重要的安全基元。最重要的是,Linkerd 2.3在默认设置下即可在网格服务之间提供经过身份验证的保密通信能力。


保护各Kubernetes服务之间的通信内容,是实现零信任网络体系的重要一步。在零信任方法当中,Linkd不再对数据中心安全边界做出种种不切实际的假设,而是将与身份验证、授权以及机密性相关的要求“落地”至各个单元。在Kubernetes术语当中,这意味着上述要求将运行在各集群内以验证、授权并加密对应通信内容。


实现流程描述:


1) 控制平面中附带证书颁发机制(简称为「身份」)。
2) 数据平面各代理从身份服务处接收TLS证书,该证书与代理所归属的Kubernetes服务账户绑定,且每24小时进行一次轮换。
3) 数据平面各代理会自动对网格服务间的通信进行升级,从而利用证书实现TLS连接的验证与加密。

由于控制平面同样运行在数据平面之上,因此控制平面各组件之间的通信也将以同样的方式得到保护。


以上提到的一切都将默认启用,不需要额外配置。换言之,从2.3版本开始,Linkerd将为全部网格服务之间提供经过加密以及身份验证的通信通道。虽然单凭这一次升级还无法实现Kubernetes中建立零信任网络的全部要求,但这仍然是一次重要的开端与尝试。



2. Fluentd 从 CNCF 毕业



CNCF(云原生计算基金会)在美国时间 2019 年 4 月 11 日宣布 Fluentd 正式毕业了。这是从 CNCF 毕业的第 6 个项目,之前已经毕业的项目为 Kubernetes、Prometheus、Envoy 、CoreDNS 和 containerd。



Fluentd 自 2011 年由 Treasure Data 公司的联合创始人 Sadayuki “Sada” Furuhashi 创建,作为构建统一记录层的开源数据收集器,统一记录层,统一收集采集和消费,以便更好的使用和理解数据。在 2016 年 11 月,Fluentd 也是第 6 个成为 CNCF 托管项目的。


Fluentd 可以从多种数据源采集事件,并将它写入文件,RDBMS,NoSQL,IaaS,SaaS,Hadoop 等等各类的目标地址。



3. Google发布Cloud Run和Traffic Director



在上周于旧金山举办的 Google Cloud Next 2019 大会上,Google Cloud 正式发布了Cloud Run和Traffic Director。


Cloud Run是业界第一个基于Knative + Kubernetes + gVisor体系的Serverless 服务。允许开发者在完全受管理的无服务器执行环境中,运行无状态 HTTP 驱动的容器。它负责所有基础架构,涵盖配置、扩展和服务器管理,其能够在‘几秒钟内’自动向上或向下扩展、甚至将资源占用降低为零,因此用户只需为实际使用的资源而付费。Cloud Run 同时提供全托管和GKE两种部署模式,在全托管模式中基于knative 在Google的内部实现和gVisor安全容器运行,GKE模式中则完全基于开源knative来实现。两个knative实现在API层一致。


此外,Cloud Run的计费模型也颇具创新性:它不是完全按照任务数和资源收费,而是将所有并发的请求算在一个计费单位内,这有望大大减低用户需要支付的成本。


Traffic Director是一个与 AWS App Mesh 对标的 Service Mesh 产品。Traffic Director 通过 xDS 协议与数据平面的 Envoy 进行通讯,可分别与 Google Cloud 的MIG和NEG两款产品结合去提供 Service Mesh 的能力。Traffic Director的功能与开源Istio项目中的 Pilot-discovery 相似,也复用了Istio 的不少技术实现(比如,通过 iptables 完成流量透明拦截)。Traffic Director 支持全球负载均衡、集中式的集群健康检查、流量驱动的自动扩缩容等功能,帮助客户在全球部署与管理高弹性的无状态应用。



4. 开源项目Kubecost



大多数Kubernetes管理工具都侧重于易用性,监控,对pod行为的洞察等。但是如何监控与运行Kubernetes相关的成本?

Kubecost能够按照 Kubernetes的原生 API,比如 Pod,Deployment,Service,Namespace 等概念逐层监控并详细的计算和展现出每一层上你的真实花费。更重要的是,无论你下层用的是 AWS 还是 GCP,Kubecost 内置的成本模型都可以应对自如。


如使用实时Kubernetes指标以及从主要云提供商上运行的集群派生的实际成本信息,以提供每个集群部署的每月成本的仪表板视图。内存,CPU,GPU和存储的成本都由Kubernetes组件(容器,容器,服务,部署等)分解。


Kubecost还可以跟踪“群集外”资源(例如S3存储桶)的成本,尽管目前仅限于AWS。成本数据甚至可以共享回Prometheus,因此可以使用数据以编程方式更改群集行为。



5. kubernetes近期漏洞



CVE-2019-1002101 kubectl cp漏洞


近期kubernetes的kubectl cp命令发现安全问题(CVE-2019-1002101),该问题严重程度比较高,建议将kubectl升级到Kubernetes 1.11.9,1.12.7,1.13.5或1.14.0版本以解决此问题。


kubectl cp命令允许用户在容器和主机之间复制文件,其基本原理是:


1) 在源地址将文件打包。
2) 打包输出内容作为stream流通过网络传递给目标地址。
3) 传递路径包括:apiserver、kubelet、runtime

4) stream流在目的地址作为tar的输入,解压。


具体执行过程可以参考kubernetes/pkg/kubectl/cmd/cp.go文件中的copyToPod和copyFromPod两个函数。


在这个过程中,如果容器中的tar二进制文件是恶意的,它可以运行任何代码并输出意外的恶意结果。当调用kubectl cp时,攻击者可以使用它将文件写入用户计算机上的任何路径,仅受本地用户的系统权限限制。


Kube-proxy IPVS添加flag ipvs-strict-arp


kube-proxy的ipvs模式会将clusterIP/externalIP等绑定到节点上名为kube-ipvs0的dummy设备,以确保节点上的ipvs规则可以对访问这些地址的流量作转发。


在1.13版本中,引入一个操作


echo 1 >/proc/sys/net/ipv4/conf/all/arp_ignore

echo 2 > /proc/sys/net/ipv4/conf/all/arp_announce


以禁止IPVS模式下对kube-ipvs0 dummy设备上绑定的ip的ARP回复,具体可参考pr #70530,该改动是为了修复ipvs模式下load banlancer类型service不能正常使用的问题(issue:#59976)。


而本次的buf fix则是跟前面的改动有关,因为前面的改动虽然解决了loadbalancer的问题,但是又引入了其他问题:有些CNI插件在主机和容器间的连接会用到ARP协议。因此我们看到有些用户升级到1.13后反馈下面的问题:


issue#72779:kube-proxy v1.13.0 and 1.13.1 brokes services with externalIPs

issue#71555:kube-proxy/IPVS: arpignore and arpannounce break some CNI plugins


而本bug fix也很简单,就是为kube-proxy加了一个启动参数ipvs-strict-arp,默认为0,即不改变节点上的ARP配置,如果需要改变,则设置该参数值为1。


CVE-2019-3874


这个安全漏洞最早由红帽的工程师Matteo Croce,Natale Vinto和Andrea Spagnolo发现。当Kubernetes中的Pod以Root用户运行时,它可以绕过cgroup内存隔离,通过SCTP网络传输,创建一个潜在的DoS攻击,此问题本身与Kubernetes无关,但是涉及到Kubernetes调用的内核模块。问题的严重性被定义为中等,社区建议将SCTP内核模块列入黑名单来规避此问题。用户可以通过执行如下命令来测试是否会到此类攻击。


modprobe sctp; lsmod | grep sctp


用户可以通过执行如下命令来把SCTP列入内核模块的黑名单。


echo "install sctp /bin/true" > /etc/modprobe.d/sctp.conf


相关推荐
重要看点
工业互联网
工业互联网

工业自动化控制系统,主要利用电子、电气、机械、软件组合实现,广泛用于电力、水利、能源、数据采集等关键基础设施领域,包括SCADA、DCS、PLC等工业控制系统的安全问题。