如何缩小安全漏洞爆炸半径,实现服务间零信任安全?
近日国内外多家安全机构监测到 Apache Log4j 存在任意代码执行漏洞(漏洞编号:CVE-2021-44228),未取得身份认证的用户,可以从远程发送数据请求输入数据日志,轻松触发漏洞,最终在目标上执行任意代码。
服务网格技术的一个重要的价值主张就是它如何有效地保护应用的生产环境,同时又不降低开发人员的生产力。通过服务网格技术,为微服务架构采用零信任网络安全方法提供必要的基础,以此实现所有访问都经过强身份验证、基于上下文授权、记录监控等安全目标。使用这些网格功能,您可以为属于网格的所有应用程序提供安全控制能力,例如所有流量都已加密、到应用程序的所有流量都通过策略执行点(PEP)的验证等。
-
零信任的基础 - 工作负载身份;如何为云原生工作负载提供统一的身份;ASM 产品为服务网格下的每一个工作负载提供了简单易用的身份定义,并根据特定场景提供定制机制用于扩展身份构建体系, 同时兼容社区 SPIFFE 标准;
-
零信任的载体 - 安全证书,ASM 产品提供了如何签发证书以及管理证书的生命周期、轮转等机制,通过 X509 TLS 证书建立身份,每个代理都使用该证书。并提供证书和私钥轮换;
-
零信任的引擎 - 策略执行,基于策略的信任引擎是构建零信任的关键核心,ASM 产品除了支持 Istio RBAC 授权策略之外,还提供了基于 OPA 提供更加细粒度的授权策略;
-
零信任的洞察 - 可视化与分析,ASM 产品提供了可观测机制用于监视策略执行的日志和指标,来判断每一个策略的执行情况等;
01
为什么要使用服务网格
实现零信任?
Cloud Native
- Sidecar 代理的生命周期与应用程序保持独立,因此可以更轻松地管理这些 Sidecar 代理。
- 允许动态配置,更新策略变得更加容易,更新立即生效,而无需重新部署应用程序。
- 服务网格的集中控制架构使企业的安全团队可以构建、管理和部署适用于整个企业的安全策略,从而默认情况下就能确保应用开发人员构建的业务应用的安全。他们无需额外的工作即可立即使用这些安全策略。
- 服务网格提供了对附加到请求的终端用户凭据进行身份验证的能力如 JWT。
- 此外, 使用服务网格体系结构,可以将身份验证和授权系统作为服务部署在网格中。这样一来,如同网格中的其他服务一样,这些安全系统从网格中本身也可以得到安全保证,包括传输中的加密、身份识别、策略执行点、终端用户凭据的身份验证和授权等。
阿里云服务网格 ASM中的
零信任体系
Cloud Native
服务网格能够减小云原生环境中的被攻击面积,并提供零信任应用网络所需的基础框架。通过 ASM 管理服务到服务的安全性,可以确保服务网格的端到端加密、服务级别身份认证和细粒度授权策略。
- 在服务之间实施双向 TLS 认证或者面向 server 侧的 TLS 认证,支持证书的自动轮转等生命周期管理。网格内的通信都经过身份验证和加密处理。
-
启用基于身份的细粒度授权,以及基于其他维度参数的授权。基于角色访问控制 (RBAC) 的基础,支持 “最低权限” 的立场,也就是只有经过授权的服务才能根据 ALLOW/DENY 规则相互通信。
1
工作负载身份
数据面中的 Kubernetes 集群下的工作负载及其身份定义:
基于 WorkloadEntry 定义虚拟机工作负载及其身份定义:
认证指的是身份:这个服务是谁?这个最终用户是谁?我可以相信他们就是他们所说的那样吗?
ASM产品提供了两种身份验证:
-
对等身份验证 - 当两个微服务相互交互时,启用还是禁用双向TLS进行对等身份验证。
-
请求身份验证 - 允许最终用户和系统使用请求身份认证与微服务进行交互。通常使用JSON Web令牌(JWT)执行该操作。
按照入门指引(具体请见文末相关链接 3)安装部署 bookinfo 示例。
kubectl exec $(kubectl get pod -l app=productpage -o jsonpath={.items..metadata.name}) -c istio-proxy -- curl http://details:9080/details/1 -o /dev/null -s -w '%{http_code}\n'
接着,在命名空间 default 下定义对等身份认证。
在服务网格 ASM 控制台上,打开对应的 ASM 实例,在左侧导航栏中可以看到如下零信任安全下的对等身份认证。在右侧页面中,点击 “新建双向 mTLS 模式” 按钮,为工作负载 details 定义 mTLS 模式为 STRICT。
再次,使用 productpage pod 使用纯 HTTP 访问 details 服务时:
kubectl exec $(kubectl get pod -l app=productpage -o jsonpath={.items..metadata.name}) -c istio-proxy -- curl http://details:9080/details/1 -o /dev/null -s -w '%{http_code}\n'000command terminated with exit code 56
apiVersion: security.istio.io/v1beta1kind: PeerAuthenticationmetadata: name: details-strict namespace: defaultspec: mtls: mode: PERMISSIVE selector: matchLabels: app: details
3 请求身份验证
其中,issuer 值设置为"testing@secure.istio.io",jwks 的值取自 Istio 安装文件中的 security/tools/jwt/samples/jwks.json,对应如下
{ "keys":[ {"e":"AQAB","kid":"DHFbpoIUqrY8t2zpA2qXfCmr5VO5ZEr4RzHU_-envvQ","kty":"RSA","n":"xAE7eB6qugXyCAG3yhh7pkDkT65pHymX-P7KfIupjf59vsdo91bSP9C8H07pSAGQO1MV_xFj9VswgsCg4R6otmg5PV2He95lZdHtOcU5DXIg_pbhLdKXbi66GlVeK6ABZOUW3WYtnNHD-91gVuoeJT_DwtGGcp4ignkgXfkiEm4sw-4sfb4qdt5oLbyVpmW6x9cfa7vs2WTfURiCrBoUqgBo_-4WTiULmmHSGZHOjzwa8WtrtOQGsAFjIbno85jp6MnGGGZPYZbDAa_b3y5u-YpW7ypZrvD8BgtKVjgtQgZhLAGezMt0ua3DRrWnKqTZ0BJ_EyxOGuHJrLsn00fnMQ"}]}
接着, 尝试使用 productpage pod 使用纯 HTTP 访问 details 服务时,可以看到返回结果为 200。
export TOKEN=eyJhbGciOiJSUzI1NiIsImtpZCI6IkRIRmJwb0lVcXJZOHQyenBBMnFYZkNtcjVWTzVaRXI0UnpIVV8tZW52dlEiLCJ0eXAiOiJKV1QifQ.eyJleHAiOjQ2ODU5ODk3MDAsImZvbyI6ImJhciIsImlhdCI6MTUzMjM4OTcwMCwiaXNzIjoidGVzdGluZ0BzZWN1cmUuaXN0aW8uaW8iLCJzdWIiOiJ0ZXN0aW5nQHNlY3VyZS5pc3Rpby5pbyJ9.CfNnxWP2tcnR9q0vxyxweaF3ovQYHYZl82hAUsn21bwQd9zP7c-LS9qd_vpdLG4Tn1A15NxfCjp5f7QNBUo-KC9PJqYpgGbaXhaGx7bEdFWjcwv3nZzvc7M__ZpaCERdwU7igUmJqYGBYQ51vr2njU9ZimyKkfDe3axcyiBZde7G6dabliUosJvvKOPcKIWPccCgefSj_GNfwIip3-SsFdlR7BtbVUcqR-yv-XOxJ3Uc1MI0tz3uMiiZcyPV7sNCU4KRnemRIMHVOfuvHsU60_GhGbiSFzgPTAa9WTltbnarTbxudb_YEOx12JiwYToeX0DCPb43W1tzIBxgm8NxUg kubectl exec $(kubectl get pod -l app=productpage -o jsonpath={.items..metadata.name}) -c istio-proxy -- curl http://details:9080/details/1 -o /dev/null --header "Authorization: Bearer $TOKEN" -s -w '%{http_code}\n' 200
如果传递的是无效令牌,我们应该看到 “401: Unauthorized” 响应:
kubectl exec $(kubectl get pod -l app=productpage -o jsonpath={.items..metadata.name}) -c istio-proxy -- curl http://details:9080/details/1 -o /dev/null --header "Authorization: Bearer badtoken" -s -w '%{http_code}\n' 401
但是,如果我们根本不传递令牌,RequestAuthentication 则不会调用该策略。不使用 JWT Token 的请求, 同样也返回了 200。
kubectl exec $(kubectl get pod -l app=productpage -o jsonpath={.items..metadata.name}) -c istio-proxy -- curl http://details:9080/details/1 -o /dev/null -s -w '%{http_code}\n' 200
因此,除了此身份验证策略之外,我们还需要一个授权策略,该策略要求对所有请求进行 JWT。下一部分会讲述如何在 ASM 产品中定义授权策略。
4 授权策略
ASM 产品提供了授权策略,可以使用授权策略 AuthorizationPolicy 资源来激活微服务之间的授权机制,并使用以下内容建立适当的流量授权策略机制:
- 工作负载标签选择 selector 字段指定策略目标;
- action 字段指定是 ALLOW 还是 DENY 请求。如果您未指定操作,则操作默认设置为 ALLOW。为清晰起见,我们建议您始终指定操作。(授权政策还支持 AUDIT 和 CUSTOM 操作);
- rules 指定何时触发操作:
- rules 中的 from 字段指定请求的来源;
- rules 中的 to 字段指定请求的操作;
- when 字段指定为了应用规则所需满足的其他条件;
apiVersion: security.istio.io/v1beta1kind: AuthorizationPolicymetadata: name: require-jwt namespace: defaultspec: action: ALLOW rules: - from: - source: requestPrincipals: - testing@secure.istio.io/testing@secure.istio.io selector: matchLabels: app: details
再次不使用 JWT Token 发送请求,您现在应该看到 403 - Forbidden。这就是 AuthorizationPolicy 生效了,所有前端请求都必须有一个 JWT Token。
kubectl exec $(kubectl get pod -l app=productpage -o jsonpath={.items..metadata.name}) -c istio-proxy -- curl http://details:9080/details/1 -o /dev/null -s -w '%{http_code}\n'403
5 OPA 策略
作为由 CNCF(具体请见文末相关链接 4)托管的一个孵化项目,开放策略代理(OPA)(具体请见文末相关链接 5)是一个策略引擎,可用于为您的应用程序实现细粒度的访问控制。OPA 作为通用策略引擎,可以与微服务一起部署为独立服务。为了保护应用程序,必须先授权对微服务的每个请求,然后才能对其进行处理。为了检查授权,微服务对 OPA 进行 API 调用,以确定请求是否被授权。
具体可以参考《在ASM中实现动态更新OPA策略》(具体请见文末相关链接 6)
英特尔® 在全新的第三代英特尔® 至强® 可扩展处理器(ICELAKE)中引入众多我们称为 Crypto Acceleration 加解密加速技术和架构创新,大大提升了一些关键加解密算法的性能。第三代英特尔至强处理器和 Multi-Buffer 技术所使用的 AVX512 指令集,在阿里云第七代 ECS 服务器中提供了若干不同的实例类型。基于这些指令集, 加上融合了 MultiBuffer 技术的 Envoy 上游社区能力,阿里云服务网格 ASM 产品提供了基于 MB 技术的 TLS 加解密性能优化能力。
结合英特尔的开源软件库,例如 IPP 加密库、IPsec 多缓冲区加密库 (intel-ipsec-mb)、英特尔® QuickAssist 技术(英特尔® QAT)和 OpenSSL 引擎。这些解决方案显着改善了加密操作,例如 TLS 连接握手性能。这些新组件可以并行处理多个 TLS 私钥操作。借助 OpenSSL 和 BoringSSL 中都可用的异步私钥处理机制,应用程序软件可以提交握手私钥请求,而无需等待一个请求返回,然后才能提交另一个。反过来,一旦准备好,就会为每个请求调用一个回调。在下面,多缓冲区加密处理可以将 8 个这样异步提交的私钥操作,并使用 AVX512 SIMD(单指令多数据)指令并行处理,大大提高了整体应用性能。
在 KubeCon 2021 大会上阿里云服务网格 ASM 负责人王夕宁和英特尔软件和先进技术部云计算团队的胡伟将会给大家带来一次专题的技术分享,届时我们将会介绍更多的技术细节和实践的情况。(技术分享链接见文末 7)
总结及参考案例
Cloud Native
综上所示,服务网格 ASM 提供了以下用于增强安全性的组件:
- 提供具有完整证书生命周期管理的托管证书基础设施,解决了证书颁发和 CA 轮换的复杂性;
- 托管的控制面 API,用于向 Envoy 代理分发身份验证策略,授权策略和安全命名信息;
- Sidecar 代理通过提供策略执行点 PEP 来帮助确保网格的安全;
- Envoy 代理扩展允许遥测数据收集和审计;
1 参考案例
-
使用授权策略在入口网关上实施基于 IP 的访问控制(具体请见文末相关链接 8)、或者基于自定义外部授权的访问控制等,如下图所示云产品云原生应用交付平台 ADP(具体请见文末相关链接 9)基于阿里云服务网格ASM的网关授权策略实现。
- 某互联金融客户在解决跨集群多语言应用的访问权限控制方面,使用阿里云服务网格 ASM 提供的授权策略隔离外联区域和应用区域。同时可以结合出口网关来审计出网格的流量,配合上授权策略,还可以控制应用对第三方服务的访问权限。