微软在台剖析Kubernetes资安风险，近年K8s攻击技术手法有3大面向值得关注最新消息

微软2020年发布Kubernetes攻击威胁矩阵，今年上半改版，该公司首度在台探讨这项议题，他们的首席云端解决方案架构师李匡正揭露须关注的3大风险面，包含网络安全政策面、敏感资料面与应用程序面，图为应用程序面所对应的4项攻击技术手法。

随着轻量虚拟化的容器技术（container）成为热门应用，管理容器化的Kubernetes（K8s）系统也备受关注，而了解容器化环境的各种威胁与安全风险，更是成为近年瞩目焦点，特别的是，在2020年4月，微软仿效MITREATT&CK，发布了Kubernetes攻击威胁矩阵（Threat matrix for Kubernetes），期望剖析攻击面，并建立业界面对容器资安威胁的共通描述语言。

相隔一年，微软首度更新K8s攻击威胁矩阵，今年4月该公司首席云端解决方案架构师李匡正提出更多说明，阐释K8s值得关注的安全议题。

值得关注的安全议题，包含网络安全政策、敏感资料与应用程序面

基本上，K8s攻击威胁矩阵参考MITRE ATT&CK框架，将相关攻击技术手法系统予以归纳，各战略阶段名称几乎与ATT&CK相同，但与现行ATT＆CK相比，数量显然较少。

以K8s攻击威胁矩阵而言，目前最新版共画分10个阶段（第一版为9个阶段），从入侵初期、执行、权限提升、防御逃避、凭证存取、发现、横向移动、收集，以至最终的冲击，并统整归纳出48个技术手法（第一版为40项技术手法）。

而在这些统整的这些K8s攻击技术手法中，近年有那些安全议题值得关注？李匡正表示，可从三大面向着手，包括：网络安全政策、敏感资料保存与应用程序面。

首先，是在网络安全政策方面，以攻击手法而言，是列为发现阶段的Network Mapping，以及横向移动阶段的Clusterinternal networking。

对于网络安全政策面的资安风险，李匡正表示，部署于同一K8s丛集的Pod与Pod之间，预设是允许相互连线，也就是不会有任何拦阻，而这样的设计并不安全。

他进一步解释原因。以传统规划机房为例，每个网段可能会配置防火墙，操作系统本身有防火墙，而在云端每个虚拟网络的网段，也都会有类似网火墙的机制。

因此，在K8s 1.7版本之后，CNCF基金会开始定义Network policy规格，来因应这样的需求，而这等同于实体网络环境中防火墙的角色，可定义Pod与Pod之间流量进出规则，市面上，已有多套实作Network Policy的机制，李匡正表示，若以Azure Kubernetes Service（AKS）为例，微软本身的相关实作，称为Azure Network Policy，也支援Calico专案。

他特别提醒，虽然开发人员在测试环境中会尽量简化应用程序的架构，不过在正式营运环境中，需考虑到透过这样网络政策，预设就要挡掉所有对外及对内的流量，在依照政策规则，开放特定网络埠供特定的Pod来使用。

第二个常见的风险，在于敏感资料保存方面的K8s Secrets，而对应的攻击手法，主要是列于该威胁矩阵中，在凭证存取阶段的List K8s Secrets。

李匡正说，K8s提供给开发者用来存放敏感资讯的机制称为Secrets，可存放access token、账号密码与数据库连线字串等机密资讯，不过，由于K8sSecrets预设并没有加密，只是用Base64编码写入，因此懂得写程式的人，都能用Base64解码的方式将这些机密还原。

因此，在K8s的相关文件，已经强调须使用加密的方案来达到安全。李匡正表示，在Azure环境当中，他们提供了HSM硬件加密的Azure Key Vault，可与K8s Secrets结合应用。

同时，虽然套用加密，但在存取时还是会解密，因此，做到以角色为基础的存取控制（RBAC）就相当重要。他举例，在开发测试环境中，往往可能为了除错方便，而没有做到细部的存取管控，但是，到了正式环境，存取管控千万不能省略，不论是开发人员、系统管理人员的权限，都需要被定义清楚。

因此，对于K8s Secrets的基本安全防护，他提醒，必须使用加密解决方案，以及制定严谨存取权限管控。

第三个常见的K8s资安风险面向，是在应用程序方面，对应的攻击技术手法有4项，分别是入侵初期阶段的Using cloud credentials、Compromised images in registry与Application vulnerability，以及横向移动阶段的Container service account。

在云端环境中，系统管理员对于整个丛集的管控上，用户验证机制如何设定？是否开启多因素验证？都是至关重要的事情，还有恶意映像档的风险，包括：下载来历不明的映像档，或是容器映像档建立时本身已经被发现有资安漏洞，当用户从网络上的免费Docker Hub下载这些映像档使用，有可能会造成严重的问题，而上述面向，经常是攻击发起点。

李匡正也提醒大家注意应用程序的弱点，虽然这与容器无关，不过，当应用程序有弱点，且一并进到K8s环境之际，这些弱点也会浮现。

需仰赖多重防护配合，以达到安全性要求

对于上述K8s攻击面的防护，虽然初期测试环境可能很简单，但在正式环境下需要注意一些细节，因为要做到相关的要求，背后其实是要有多重防护的配合。

以Azure环境而言，例如：包含Azure Firewall Subnet、Azure App Gateway Subnet，可控制由内往外的网络流量、搭配网站应用程序防火墙（WAF）保护，以及在Azure　Kubernetes Serveice Subnet中，将透过内部负载平衡器来连接，并借由Calico提供网络政策给Kubernetes使用，透过Azure AD Pod Identity，让Pod存取各项Azure服务。之后，再经过Azure VNET内部私有IP地址，存取Azure File与Azure Container Registry。

李匡正特别强调，要让人员经手接触机密资讯的机会降低，透过CI/CD工具将整个环节串起来，而微软本身也使用WhiteSource公司发展的Bolt，来执行开放源代码软件套件的资安监控。此外，他也提醒，开发测试与正式营运应完全分开，避免共同环境底下的资安风险。

李匡正表示，企业若要防护K8s攻击，需注意多种机制的搭配，顾及许多细节才能要做到相关的要求，他并以Azure环境下来说明。同时，他也提醒，开发测试与正式营运的作业区应完全分开，避免因共同环境而产生资安风险。

新增8项攻击技术手法，以Sidecar injection最受关注

由于今年微软K8s攻击威胁矩阵改版，对于相关攻击技术手法的统整，作了更动，当中删除3项并额外增加8项，似乎透露K8s在基本安全性的提升，以及新的威胁趋势，当中有哪些变化值得关注？。

李匡正表示，在本次改版当中，微软已经移除了仪表板相关的攻击手法，包括：Exposed Kubernetes Dashboard，以及Access Kubernetes dashboard。

主要原因是，对于K8s仪表板方面的威胁，之前微软已经建议，不要在互联网上暴露Kubernetes仪表板，同时，只应授与仪表板服务账号必要的权限等。

以实际状况来看，包括微软AKS，以及Google Kubernetes Engine（GKE）等服务，现在都关闭K8s仪表板，用户需从Azure Portal、Google CloudConsole来检视资讯。同时，在新版K8s攻击框架中，也用涵盖范围更广泛的exposed sensitive interfaces，取代相关威胁。

至于Access tiller endpoint项目被移除，主要是K8s应用程序管理工具Helm第3版中，不再需要使用API通讯工具Tiller。换言之，若是现在仍继续使用Helm第2版与Tiller，在安全面是有疑虑的。

关于新增的攻击手法中，何者特别值得关注？李匡正表示，以Sidecar injection为例，目前Kubernetes边车模式（Sidecar）大量用在Service Mesh，而在Service Mesh扮演边车Proxy的Pod，如果被注入恶意软件，代表主程式的所有网络存取，都可能会被这类资安威胁拦截，如此将造成很严重的问题。