您好，登录后才能下订单哦！
密码登录
登录注册
点击 登录注册 即表示同意《亿速云用户服务条款》
点击下载《不一样的 双11 技术：阿里巴巴经济体云原生实践》
本文节选自《不一样的 双11 技术：阿里巴巴经济体云原生实践》一书，点击上方图片即可下载！
作者
杨宁（麟童） 阿里云基础产品事业部高级安全专家
刘梓溪（寞白） 蚂蚁金服大安全基础安全安全专家
李婷婷（鸿杉） 蚂蚁金服大安全基础安全资深安全专家
零信任安全最早由著名研究机构 Forrester 的首席分析师约翰.金德维格在 2010 年提出。零信任安全针对传统边界安全架构思想进行了重新评估和审视，并对安全架构思路给出了新的建议。
其核心思想是，默认情况下不应该信任网络内部和外部的任何人/设备/系统，需要基于认证和授权重构访问控制的信任基础。诸如 IP 地址、主机、地理位置、所处网络等均不能作为可信的凭证。零信任对访问控制进行了范式上的颠覆，引导安全体系架构从“网络中心化”走向“身份中心化”，其本质诉求是以身份为中心进行访问控制。
目前落地零信任概念包括 Google BeyondCorp、Google ALTS、Azure Zero Trust Framework 等，云上零信任体系，目前还是一个新兴的技术趋势方向，同样的零信任模型也同样适用于 Kubernetes，本文重点讲解一下 Kubernetes 下零信任安全架构的技术分析。
Azure 的零信任相对来说还是比较完善的，从体系角度来看涵盖了端、云、On-Permises、SaaS 等应用，下面我们分析一下相关的组件：
下面这张微软的图进行了更加细化的讲解，用户（员工、合作伙伴、用户等）包括 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 等各个层面，构建了一个大而全的零信任体系。
Google BeyondCorp 是为了应对新型网络威胁的一种网络安全解决方案，其实 Google BeyondCorp 本身并没有太多的技术上的更新换代，而是利用了持续验证的一种思路来做的，去掉了 *** 和不再分内外网。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 ）。
首先介绍一下容器下的网络零信任组件 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 的通信，并增加相关的控制策略；
再讲解 Istio 之前先讲一下微服务的一些安全需求和风险分析：
1、微服务被突破之后通过 Sniffer 监控流量，进而进行中间人***，为了解决这种风险需要对流量进行加密；
2、为了针对微服务和微服务之间的访问控制，需要双向 TLS 和细粒度的访问策略；
3、要审核谁在什么时候做了什么，需要审计工具；
分析了对应的风险之后，下面来解释一下 Istio 如何实现的零信任架构。首先很明显的一个特点就是全链路都是双向 mTLS 进行加密的，第二个特点就是微服务和微服务之间的访问也可以进行鉴权，通过权限访问之后还需要进行审计。Istio 是数据面和控制面进行分离的，控制面是通过 Pilot 将授权策略和安全命名信息分发给 Envoy，然后数据面通过 Envoy 来进行微服务的通信。在每个微服务的 Workload 上都会部署 Envoy，每个 Envoy 代理都运行一个授权引擎，该引擎在运行时授权请求。当请求到达代理时，授权引擎根据当前授权策略评估请求上下文，并返回授权结果 ALLOW 或 DENY。
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、访问控制执行点如何选择。
蚂蚁内部使用 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 将无法创建。如下图所示：
在解决了 Workload 身份定义的问题后，剩下的就是如何将身份转换成某种可校验的格式，在 Workload 之间的服务调用链路中透传。为了支持不同的使用场景，我们选择了 X.509 证书与 JWT 这两种格式。
对于 Service Mesh 架构的场景，我们将身份信息存放在 X.509 证书的 Subject 字段中，以此来携带 Workload 的身份信息。如下图所示：
对于其他场景，我们将身份信息存放在 JWT 的 Claims 中，而 JWT 的颁发与校验，采用了 Secure Sidecar 提供服务。如下图所示：
在项目落地的初期，使用 RBAC 模型来描述 Workload 间服务调用的授权策略。举例描述，应用 A 的某一个服务，只能被应用 B 调用。这种授权策略在大多数场景下都没有问题，不过在项目推进过程中，我们发现这种授权策略不适用于部分特殊场景。<br />我们考虑这样一个场景，生产网内部有一个应用 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 中。
在当前场景下，我们目前提供了 JAVA SDK，应用需要集成 SDK 来完成所有认证和授权相关的逻辑。与 Service Mesh 架构场景类似，所有 Identity 的颁发、校验，授权与 Secure Sidecar 交互，由 Secure Sidecar 完成。
零信任的核心是“Never Trust， Always Verify”，未来会继续深化零信任在整个阿里巴巴的实践，赋予不同的角色不同的身份，例如企业员工、应用、机器，并将访问控制点下沉到云原生基础设施的各个点，实现全局细粒度的控制，打造安全防护的新边界。本文从业界的零信任体系的落地最佳实践，到基于 Kubernetes 的零信任落地方式进行了简单的描述，本文只是抛砖引玉，希望能引发更多关于 Cloud Native 下的零信任架构体系的更多讨论和能看到更多的业界优秀的方案和产品能出现。
本书亮点
“阿里巴巴云原生关注微服务、Serverless、容器、Service Mesh 等技术领域、聚焦云原生流行技术趋势、云原生大规模的落地实践，做最懂云原生开发者的技术圈。”
免责声明：本站发布的内容（图片、视频和文字）以原创、转载和分享为主，文章观点不代表本网站立场，如果涉及侵权请联系站长邮箱：is@yisu.com进行举报，并提供相关证据，一经查实，将立刻删除涉嫌侵权内容。