Istio Service Mesh中的授权与鉴权概念详解

上周给大家分享了一篇必读!Istio Service Mesh中的流量管理概念解析,这次再给大家分享一篇Istio中重要功能和概念——授权(authorization)与鉴权(authentication)的解析。

将单体应用程序分解为微服务可提供各种好处,包括更好的灵活性、可伸缩性以及服务复用的能力。但是,微服务也有特殊的安全需求:

  • 为了抵御中间人攻击,需要流量加密。

  • 为了提供灵活的服务访问控制,需要双向 TLS 和细粒度的访问策略。

  • 要审核谁在什么时候做了什么,需要审计工具。

Istio Security 尝试提供全面的安全解决方案来解决所有这些问题。

本页概述了如何使用 Istio 的安全功能来保护您的服务,无论您在何处运行它们。特别是 Istio 安全性可以缓解针对您的数据,端点,通信和平台的内部和外部威胁。

640?wx_fmt=jpeg&tp=webp&wxfrom=5&wx_lazy=1&wx_co=1

Istio 安全概述

Istio 安全功能提供强大的身份,强大的策略,透明的 TLS 加密以及用于保护您的服务和数据的身份验证,授权和审计(AAA)工具。 Istio 安全的目标是:

  • 默认安全 : 应用程序代码和基础结构无需更改

  • 深度防御 : 与现有安全系统集成,提供多层防御

  • 零信任网络 : 在不受信任的网络上构建安全解决方案

访问我们的Mutual TLS Migration docs,开始在部署的服务中使用Istio安全功能。 请访问我们的安全任务,有关使用安全功能的详细说明。

如图所示,Istio 的 Citadel 用加载 Secret 卷的方式在 Kubernetes 容器中完成证书和密钥的分发。如果服务运行在虚拟机或物理机上,则会使用运行在本地的 Node agent,它负责在本地生成私钥和 CSR(证书签发申请),把 CSR 发送给 Citadel 进行签署,并把生成的证书和私钥分发给 Envoy。

顶层架构

Istio 中的安全性涉及多个组件:

  • Citadel 用于密钥和证书管理

  • Sidecar 和周边代理 实现客户端和服务器之间的安全通信

  • Pilot 将授权策略和安全命名信息分发给代理

  • Mixer 管理授权和审计

640?wx_fmt=jpeg&tp=webp&wxfrom=5&wx_lazy=1&wx_co=1

Istio 安全架构

在下面的部分中,我们将详细介绍 Istio 安全功能。

Istio 身份

身份是任何安全基础架构的基本概念。在服务到服务通信开始时,双方必须与其身份信息交换凭证以用于相互认证目的。 在客户端,根据安全命名信息检查服务器的标识,以查看它是否是该服务的授权运行程序。 在服务器端,服务器可以根据授权策略 确定客户端可以访问哪些信息,审核谁在什么时间访问了什么,根据服务向客户收费他们使用并拒绝任何未能支付账单的客户访问服务。

在 Istio 身份模型中,Istio 使用一流的服务标识来确定服务的身份。 这为表示人类用户,单个服务或一组服务提供了极大的灵活性和粒度。 在没有此类身份的平台上,Istio 可以使用可以对服务实例进行分组的其他身份,例如服务名称。

不同平台上的 Istio 服务标识:

  • Kubernetes: Kubernetes 服务帐户

  • GKE/GCE: 可以使用 GCP 服务帐户

  • GCP: GCP 服务帐户

  • AWS: AWS IAM 用户/角色 帐户

  • On-premises (non-Kubernetes): 用户帐户,自定义服务帐户,服务名称,istio 服务帐户或 GCP 服务帐户。

自定义服务帐户引用现有服务帐户,就像客户的身份目录管理的身份一样。

Istio 安全与 SPIFFE

SPIFFE 标准提供了一个框架规范,该框架能够跨异构环境引导和向服务发布身份。

Istio 和 SPIFFE 共享相同的身份文件:SVID (SPIFFE可验证身份证件)。 例如,在 Kubernetes 中,X.509 证书的 URI 字段格式为”spiffe:///ns//sa/“。 这使 Istio 服务能够建立和接受与其他 SPIFFE 兼容系统的连接。

Istio 安全性和 SPIRE,它是 SPIFFE 的实现,在 PKI 实现细节上有所不同。 Istio 提供更全面的安全解决方案,包括身份验证,授权和审计。

PKI

Istio PKI 建立在 Istio Citadel 之上,可为每个工作负载安全地提供强大的工作负载标识。 Istio 使用 X.509 证书来携带 SPIFFE 格式的身份。 PKI 还可以大规模自动化密钥和证书轮换。

Istio 支持在 Kubernetes pod 和本地计算机上运行的服务。 目前,我们为每个方案使用不同的证书密钥配置机制。

Kubernetes 方案

  1. Citadel 监视 Kubernetes apiserver,为每个现有和新的服务帐户创建 SPIFFE 证书和密钥对。Citadel 将证书和密钥对存储为 Kubernetes secret。

  2. 创建 pod 时,Kubernetes 会根据其服务帐户通过 Kubernetes secret volume将证书和密钥对挂载到 pod。

  3. Citadel 监视每个证书的生命周期,并通过重写 Kubernetes 秘密自动轮换证书。

  4. Pilot 生成安全命名信息,该信息定义了哪些 Service Account 可以运行哪些服务。Pilot 然后将安全命名信息传递给sidecar envoy。

本地机器方案

  1. Citadel 创建 gRPC 服务以获取证书签名请求(CSR)。

  2. 节点代理生成私钥和 CSR,并将 CSR 及其凭据发送给 Citadel 进行签名。

  3. Citadel 验证 CSR 承载的凭证,并签署 CSR 以生成证书。

  4. 节点代理将从 Citadel 接收的证书和私钥发送给 Envoy。

  5. 上述 CSR 过程会定期重复进行证书和密钥轮换。

代理程序代理节点(开发中)

在不久的将来,Istio 将在 Kubernetes 中使用节点代理进行证书和密钥提供,如下图所示。请注意,本地计算机的标识提供流程是相同的,因此我们仅描述 Kubernetes 方案。

640?wx_fmt=jpeg&tp=webp&wxfrom=5&wx_lazy=1&wx_co=1

PKI 与 Kubernetes 中的节点代理

流程如下:

  1. Citadel 创建一个 gRPC 服务来接受 CSR 请求。

  2. Envoy 通过 Envoy secret 发现服务(SDS)API 发送证书和密钥请求。

  3. 收到 SDS 请求后,节点代理会创建私钥和 CSR,并将 CSR 及其凭据发送给 Citadel 进行签名。

  4. Citadel 验证 CSR 中携带的凭证

  • 0
    点赞
  • 5
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值