随着轻量虚拟化的容器技术（container）成为热门应用，管理容器化的Kubernetes（K8s）系统也备受关注，而了解容器化环境的各种威胁与安全风险，更是成为近年瞩目焦点，特别的是，在2020年4月，微软仿效MITRE ATT&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环境下来说明。同时，他也提醒，开发测试与正式运营的作业区应完全分开，避免因共同环境而产生安全风险。
另外值得一提的是，由于今年微软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，如果被注入恶意软件，代表主程序的所有网络访问，都可能会被这类安全威胁拦截，如此将造成很严重的问题。
微软Azure团队于今年3月针对K8s威胁矩阵进行首度改版，相关汇集整理技术手法有些变化，添加8项并删除3项。（图片来源：微软）