Kubernetes 下零信任安全架构分析

本文涉及的产品
服务治理 MSE Sentinel/OpenSergo,Agent数量 不受限
应用实时监控服务-应用监控,每月50GB免费额度
容器镜像服务 ACR,镜像仓库100个 不限时长
简介: 目前落地零信任概念包括 Google BeyondCorp、Google ALTS、Azure Zero Trust Framework 等,云上零信任体系,目前还是一个新兴的技术趋势方向,同样的零信任模型也同样适用于 Kubernetes,本文重点讲解一下 Kubernetes 下零信任安全架构的技术分析。

本文节选自《不一样的 双11 技术:阿里巴巴经济体云原生实践》一书

作者
杨宁(麟童) 阿里云基础产品事业部高级安全专家
刘梓溪(寞白) 蚂蚁金服大安全基础安全安全专家
李婷婷(鸿杉) 蚂蚁金服大安全基础安全资深安全专家

简介

零信任安全最早由著名研究机构 Forrester 的首席分析师约翰.金德维格在 2010 年提出。零信任安全针对传统边界安全架构思想进行了重新评估和审视,并对安全架构思路给出了新的建议。

其核心思想是,默认情况下不应该信任网络内部和外部的任何人/设备/系统,需要基于认证和授权重构访问控制的信任基础。诸如 IP 地址、主机、地理位置、所处网络等均不能作为可信的凭证。零信任对访问控制进行了范式上的颠覆,引导安全体系架构从“网络中心化”走向“身份中心化”,其本质诉求是以身份为中心进行访问控制。

目前落地零信任概念包括 Google BeyondCorp、Google ALTS、Azure Zero Trust Framework 等,云上零信任体系,目前还是一个新兴的技术趋势方向,同样的零信任模型也同样适用于 Kubernetes,本文重点讲解一下 Kubernetes 下零信任安全架构的技术分析。

传统零信任概念和目前落地情况

Microsoft Azure

Azure 的零信任相对来说还是比较完善的,从体系角度来看涵盖了端、云、On-Permises、SaaS 等应用,下面我们分析一下相关的组件:

  • 用户 Identity:然后通过 Identity Provider(创建、维护和管理用户身份的组件)的认证,再认证的过程中可以使用账号密码,也可以使用 MFA(Multi Factor Auth)多因素认证的方式,多因素认证包括软、硬 Token、SMS、人体特征等;
  • 设备 Identity:设备包含了公司的设备以及没有统一管理的设备,这些设备的信息,包含 IP 地址、MAC 地址、安装的软件、操作系统版本、补丁状态等存储到 Device Inventory;另外设备也会有相应的 Identity 来证明设备的身份;设备会有对应的设备状态、设备的风险进行判定;
  • Security Policy Enforcement:通过收集的用户 Identity 以及状态、设备的信息,状态以及 Identity 后,SPE 策略进行综合的判定,同时可以结合 Threat Intelligence 来增强 SPE 的策略判定的范围和准备性;策略的例子包括可以访问后面的 Data、Apps、Infrastructure、Network;
  • Data:针对数据(Emails、Documents)进行分类、标签、加密的策略;
  • Apps:可以自适应访问对应的 SaaS 应用和 On-Permises 应用;
  • Infrastructure:包括 IaaS、PaaS、Container、Serverless 以及 JIT(按需开启访问)和 GIT 版本控制软件;
  • Network:针对网络交付过程以及内部的微隔离进行策略打通。

1.png

下面这张微软的图进行了更加细化的讲解,用户(员工、合作伙伴、用户等)包括 Azure AD、ADFS、MSA、Google ID 等,设备(可信的合规设备)包括 Android、iOS、MacOS、Windows、Windows Defender ATP,客户端(客户端 APP 以及认证方式)包括浏览器以及客户端应用,位置(物理和虚拟地址)包括地址位置信息、公司网络等,利用 Microsoft 的机器学习 ML、实时评估引擎、策略等进行针对用户、客户端、位置和设备进行综合判定,来持续自适应的访问 On-Permises、Cloud SaaS Apps、Microsoft Cloud,包含的策略包括 Allow、Deny,限制访问、开启 MFA、强制密码重置、阻止和锁定非法认证等;从下图可以看出 Azure 已经打通了 On-Permises、Cloud、SaaS 等各个层面,构建了一个大而全的零信任体系。

2.png

Google BeyondCorp

Google BeyondCorp 是为了应对新型网络威胁的一种网络安全解决方案,其实 Google BeyondCorp 本身并没有太多的技术上的更新换代,而是利用了持续验证的一种思路来做的,去掉了 VPN 和不再分内外网。Google 在 2014 年之前就预测到互联网和内网的安全性是一样危险的,因为一旦内网边界被突破的话,攻击者就很容易的访问企业的一些内部应用,由于安全意识的问题导致企业会认为我的内部很安全,就对内部的应用进行低优先级别的处理,导致大量内部的安全问题存在。现在的企业越来越多的应用移动和云技术,导致边界保护越来越难。所以 Google 干脆一视同仁,不分内外部,用一样的安全手段去防御。

从攻防角度来看一下 Google 的 BeyondCorp 模型,例如访问 Google 内部应用http://blackberry.corp.google.com ,它会跳转到https://login.corp.google.com/ 也就是 Google Moma 系统,首先需要输入账号密码才能登陆,这个登录的过程中会针对设备信息、用户信息进行综合判定,账号密码正确以及设备信息通过规则引擎验证之后,会继续跳转到需要 YubiKey 登录界面,每个 Google 的员工都会有 Yubikey,通过 Yubikey 来做二次验证。Yubikey 的价值,Google 认为是可以完全杜绝钓鱼攻击的。另外类似的就是 Amazon 的 Midway-Auth 方式 ( https://midway-auth.amazon.com/login?next=%2F )。
3.png

Kubernetes 下容器零信任模型

容器下网络零信任

首先介绍一下容器下的网络零信任组件 Calico,Calico 是针对容器,虚拟机和基于主机的本机 Workload 的开源网络和网络安全解决方案产品。Calico 支持广泛的平台,包括 Kubernetes、OpenShift、Docker EE、OpenStack 和裸金属服务。零信任最大的价值就是即使攻击者通过其他各种手法破坏应用程序或基础架构,零信任网络也具有弹性。零信任架构使得使攻击者难以横向移动,针对性的踩点活动也更容易发现。

在容器网络零信任体系下,Calico+Istio 目前是比较热的一套解决方案;先来看看两者的一些差别,从差别上可以看到 Istio 是针对 Pod 层 Workload 的访问控制,以及 Calico 针对 Node 层的访问控制:

Istio Calico
Layer L3-L7 L3-L4
实现方式 用户态 内核态
策略执行点 Pod Node

下面重点讲解一下 Calico 组件和 Istio 的一些技术细节,Calico 构建了一个 3 层可路由网络,通过 Calico 的 Felix(是运行在 Node 的守护程序,它在每个 Node 资源上运行。Felix 负责编制路由和 ACL 规则以及在该 Node 主机上所需的任何其他内容,以便为该主机上的资源正常运行提供所需的网络连接)运行在每个 Node 上,主要做路由和 ACL 的策略以及搭建网络;通过运行在 Node 上的 Iptables 进行细粒度的访问控制。可以通过 Calico 设置默认 Deny 的策略,然后通过自适应的访问控制来进行最小化的访问控制策略的执行,从而构建容器下的零信任体系;Dikastes/Envoy:可选的 Kubernetes sidecars,可以通过相互 TLS 身份验证保护 Workload 到 Workload 的通信,并增加相关的控制策略;

4.png

Istio

再讲解 Istio 之前先讲一下微服务的一些安全需求和风险分析:

1、微服务被突破之后通过 Sniffer 监控流量,进而进行中间人攻击,为了解决这种风险需要对流量进行加密;
2、为了针对微服务和微服务之间的访问控制,需要双向 TLS 和细粒度的访问策略;
3、要审核谁在什么时候做了什么,需要审计工具;

分析了对应的风险之后,下面来解释一下 Istio 如何实现的零信任架构。首先很明显的一个特点就是全链路都是双向 mTLS 进行加密的,第二个特点就是微服务和微服务之间的访问也可以进行鉴权,通过权限访问之后还需要进行审计。Istio 是数据面和控制面进行分离的,控制面是通过 Pilot 将授权策略和安全命名信息分发给 Envoy,然后数据面通过 Envoy 来进行微服务的通信。在每个微服务的 Workload 上都会部署 Envoy,每个 Envoy 代理都运行一个授权引擎,该引擎在运行时授权请求。当请求到达代理时,授权引擎根据当前授权策略评估请求上下文,并返回授权结果 ALLOW 或 DENY。

5.png

微服务下的 Zero Trust API 安全

42Crunch( https://42crunch.com/ )将 API 安全从企业边缘扩展到了每个单独的微服务,并通过可大规模部署的超低延迟微 API 防火墙来进行保护。 42Crunch API 防火墙的部署模式是以 Kubernetes Pod 中以 Sidecar 代理模式部署,毫秒级别的性能响应。 这省去了编写和维护单个 API 安全策略过程,并实施了零信任安全体系结构,提升了微服务下的 API 安全性。42Crunch 的 API 安全能力包括:审核:运行 200 多个 OpenAPI 规范定义的安全审核测试,并进行详细的安全评分,以帮助开发人员定义和加强 API 安全;扫描:扫描实时 API 端点,以发现潜在的漏洞;保护:保护 API 并在应用上部署轻量级,低延迟 Micro API Firewall。

蚂蚁零信任架构体系落地最佳实践

随着 Service Mesh 架构的演进,蚂蚁已经开始在内部落地 Workload 场景下的服务鉴权能力,如何建设一套符合蚂蚁架构的 Workload 间的服务鉴权能力,我们将问题分为一下三个子问题:

1、Workload 的身份如何定义,如何能够实现一套通用的身份标识的体系;
2、Workload 间访问的授权模型的实现;
3、访问控制执行点如何选择。

Workload 身份定义 & 认证方式

蚂蚁内部使用 SPIFFE 项目中给出的 Identity 格式来描述 Workload 的身份,即:

spiffe://<domain>/cluster/<cluster>/ns/<namespace>

不过在工程落地过程中发现,这种维度的身份格式粒度不够细,并且与 K8s 对于 namespace 的划分规则有较强的耦合。蚂蚁的体量较大,场景较多,不同场景下 namespace 的划分规则都不完全一致。因此我们对格式进行了调整,在每一场景下梳理出能够标识一个 Workload 示例所须要的一组必备属性(例如应用名,环境信息等),并将这些属性携带在 Pod 的 Labels 中。调整后的格式如下:

spiffe://<domain>/cluster/<cluster>/<required_attr_1_name>/<required_attr_1_value>/<required_attr_2_name>/<required_attr_2_value>

配合这个身份格式标准,我们在 K8s API Server 中添加了 Validating Webhook 组件,对上述 Labels 中必须携带的属性信息进行校验。如果缺少其中一项属性信息,则实例 Pod 将无法创建。如下图所示:

6.png

在解决了 Workload 身份定义的问题后,剩下的就是如何将身份转换成某种可校验的格式,在 Workload 之间的服务调用链路中透传。为了支持不同的使用场景,我们选择了 X.509 证书与 JWT 这两种格式。

对于 Service Mesh 架构的场景,我们将身份信息存放在 X.509 证书的 Subject 字段中,以此来携带 Workload 的身份信息。如下图所示:

7.png

对于其他场景,我们将身份信息存放在 JWT 的 Claims 中,而 JWT 的颁发与校验,采用了 Secure Sidecar 提供服务。如下图所示:

8.png

授权模型

在项目落地的初期,使用 RBAC 模型来描述 Workload 间服务调用的授权策略。举例描述,应用 A 的某一个服务,只能被应用 B 调用。这种授权策略在大多数场景下都没有问题,不过在项目推进过程中,我们发现这种授权策略不适用于部分特殊场景。
我们考虑这样一个场景,生产网内部有一个应用 A,职责是对生产网内部的所有应用在运行时所需要使用的一些动态配置提供中心化的服务。这个服务的定义如下:A 应用 - 获取动态配置的 RPC 服务:

message FetchResourceRequest {
// The appname of invoker
string appname = 1;
// The ID of resource
string resource_id = 2;
}
message FetchResourceResponse {
string data = 1;
}
service DynamicResourceService {
rpc FetchResource (FetchResourceRequest) returns (FetchResourceResponse) {}
}

在此场景下,如果依然使用 RBAC 模型,应用 A 的访问控制策略将无法描述,因为所有应用都需要访问 A 应用的服务。但是这样会导致显而易见的安全问题,调用方应用 B 可以通过该服务获取到其它应用的资源。因此我们将 RBAC 模型升级为 ABAC 模型来解决上述问题。 我们采用 DSL 语言来描述 ABAC 的逻辑,并且集成在 Secure Sidecar 中。

访问控制执行点的选择

在执行点选择方面,考虑到 Service Mesh 架构推进需要一定的时间,我们提供了两不同的方式,可以兼容 Service Mesh 的架构,也可以兼容当前场景。

在 Service Mesh 架构场景下,RBAC Filter 和 ABAC Filter(Access Control Filter)集成在 Mesh Sidecar 中。

9.png

在当前场景下,我们目前提供了 JAVA SDK,应用需要集成 SDK 来完成所有认证和授权相关的逻辑。与 Service Mesh 架构场景类似,所有 Identity 的颁发、校验,授权与 Secure Sidecar 交互,由 Secure Sidecar 完成。

10.png

结语

零信任的核心是“Never Trust, Always Verify”,未来会继续深化零信任在整个阿里巴巴的实践,赋予不同的角色不同的身份,例如企业员工、应用、机器,并将访问控制点下沉到云原生基础设施的各个点,实现全局细粒度的控制,打造安全防护的新边界。本文从业界的零信任体系的落地最佳实践,到基于 Kubernetes 的零信任落地方式进行了简单的描述,本文只是抛砖引玉,希望能引发更多关于 Cloud Native 下的零信任架构体系的更多讨论和能看到更多的业界优秀的方案和产品能出现。

ban.jpg

本书亮点

  • 双11 超大规模 K8s 集群实践中,遇到的问题及解决方法详述
  • 云原生化最佳组合:Kubernetes+容器+神龙,实现核心系统 100% 上云的技术细节
  • 双 11 Service Mesh 超大规模落地解决方案

阿里巴巴云原生关注微服务、Serverless、容器、Service Mesh 等技术领域、聚焦云原生流行技术趋势、云原生大规模的落地实践,做最懂云原生开发者的技术圈。”

相关实践学习
通过Ingress进行灰度发布
本场景您将运行一个简单的应用,部署一个新的应用用于新的发布,并通过Ingress能力实现灰度发布。
容器应用与集群管理
欢迎来到《容器应用与集群管理》课程,本课程是“云原生容器Clouder认证“系列中的第二阶段。课程将向您介绍与容器集群相关的概念和技术,这些概念和技术可以帮助您了解阿里云容器服务ACK/ACK Serverless的使用。同时,本课程也会向您介绍可以采取的工具、方法和可操作步骤,以帮助您了解如何基于容器服务ACK Serverless构建和管理企业级应用。 学习完本课程后,您将能够: 掌握容器集群、容器编排的基本概念 掌握Kubernetes的基础概念及核心思想 掌握阿里云容器服务ACK/ACK Serverless概念及使用方法 基于容器服务ACK Serverless搭建和管理企业级网站应用
相关文章
|
17天前
|
运维 Kubernetes Cloud Native
智联招聘 × 阿里云 ACK One:云端弹性算力颠覆传统 IDC 架构,打造春招技术新范式
在 2025 年春季招聘季的激战中,智联招聘凭借阿里云 ACK One 注册集群与弹性 ACS 算力的深度融合,成功突破传统 IDC 机房的算力瓶颈,以云上弹性架构支撑千万级用户的高并发访问,实现招聘服务效率与稳定性的双重跃升。
|
2月前
|
人工智能 自然语言处理 数据可视化
两大 智能体框架 Dify vs Langchain 的全面分析,该怎么选?资深架构师 做一个彻底的解密
两大 智能体框架 Dify vs Langchain 的全面分析,该怎么选?资深架构师 做一个彻底的解密
两大 智能体框架 Dify vs Langchain 的全面分析,该怎么选?资深架构师 做一个彻底的解密
|
3月前
|
人工智能 运维 安全
AI 安全架构概述
AI 安全架构涵盖数据采集、模型训练、推理部署等阶段,确保安全性、隐私与合规。其核心组件包括数据层、模型层、推理层、应用层和运维层,针对数据安全威胁(如数据投毒)、模型窃取、对抗攻击及系统漏洞等风险,提出数据加密、对抗训练、联邦学习等防御策略,并强调开发前、开发中和部署后的最佳实践,以降低 AI 解决方案的安全风险。
336 13
|
弹性计算 Kubernetes 数据处理
KubeRay on ACK:更高效、更安全
阿里云 ACK 以托管组件化的方式给客户提供快速搭建Ray集群的能力,并通过结合使用阿里云的调度,存储,日志与监控,给用户提供更佳使用体验。
|
1月前
|
机器学习/深度学习 人工智能 算法
大型多模态推理模型技术演进综述:从模块化架构到原生推理能力的综合分析
该研究系统梳理了大型多模态推理模型(LMRMs)的技术发展,从早期模块化架构到统一的语言中心框架,提出原生LMRMs(N-LMRMs)的前沿概念。论文划分三个技术演进阶段及一个前瞻性范式,深入探讨关键挑战与评估基准,为构建复杂动态环境中的稳健AI系统提供理论框架。未来方向聚焦全模态泛化、深度推理与智能体行为,推动跨模态融合与自主交互能力的发展。
121 13
大型多模态推理模型技术演进综述:从模块化架构到原生推理能力的综合分析
|
18天前
|
运维 监控 数据可视化
一文详解:工业软件“低代码开发平台”技术架构研究与分析
本文围绕工业软件低代码开发平台的机遇与挑战,提出基于自动化引擎的技术架构,由工具链、引擎库、模型库、组件库、工业数据网关和应用门户组成。文章分析了其在快速开发、传统系统升级中的应用模式及价值,如缩短创新周期、降低试错成本、解决资源缺乏和提升创新可复制性,为我国工业软件产业发展提供参考和支持。
|
18天前
|
负载均衡 Java API
基于 Spring Cloud 的微服务架构分析
Spring Cloud 是一个基于 Spring Boot 的微服务框架,提供全套分布式系统解决方案。它整合了 Netflix、Zookeeper 等成熟技术,通过简化配置和开发流程,支持服务发现(Eureka)、负载均衡(Ribbon)、断路器(Hystrix)、API网关(Zuul)、配置管理(Config)等功能。此外,Spring Cloud 还兼容 Nacos、Consul、Etcd 等注册中心,满足不同场景需求。其核心组件如 Feign 和 Stream,进一步增强了服务调用与消息处理能力,为开发者提供了一站式微服务开发工具包。
|
2月前
|
监控 安全 数据安全/隐私保护
销售易CRM:技术架构与安全性能的深度解析
销售易CRM基于云计算与微服务架构,融合高可用性、弹性扩展及模块化开发优势,为企业提供灵活定制化的客户关系管理解决方案。系统采用多层次安全防护机制,包括数据加密、细粒度权限控制和实时监控审计,确保数据安全与隐私保护。某金融机构的成功案例表明,销售易CRM显著提升了数据安全性和系统性能,同时满足行业合规要求。作为数字化转型的利器,销售易CRM助力企业实现可持续发展与市场竞争力提升。
|
3月前
|
监控 安全 Cloud Native
企业网络架构安全持续增强框架
企业网络架构安全评估与防护体系构建需采用分层防御、动态适应、主动治理的方法。通过系统化的实施框架,涵盖分层安全架构(核心、基础、边界、终端、治理层)和动态安全能力集成(持续监控、自动化响应、自适应防护)。关键步骤包括系统性风险评估、零信任网络重构、纵深防御技术选型及云原生安全集成。最终形成韧性安全架构,实现从被动防御到主动免疫的转变,确保安全投入与业务创新的平衡。

相关产品

  • 容器服务Kubernetes版
  • 推荐镜像

    更多