Istio 授权下的微分段

描述 Istio 的授权功能以及如何在各种用例中使用它。

2018 年 7 月 20 日 | 作者：王丽敏

微分段是一种安全技术，它在云部署中创建安全区域，并允许组织将工作负载相互隔离并分别对其进行保护。Istio 的授权功能，也称为 Istio 基于角色的访问控制，为 Istio 网格中的服务提供微分段。其特点包括

在这篇博文中，您将了解主要的授权功能以及如何在不同情况下使用它们。

特性

RPC 级别授权

授权在单个 RPC 的级别执行。具体来说，它控制“谁可以访问我的 bookstore 服务”，或“谁可以访问我的 bookstore 服务中的 getBook 方法”。它并非旨在控制对特定于应用程序的资源实例的访问，例如访问“存储桶 X”或访问“第二层架上的第三本书”。目前，这种特定于应用程序的访问控制逻辑需要由应用程序本身处理。

基于角色的访问控制及条件

授权是一个基于角色的访问控制 (RBAC) 系统，与基于属性的访问控制 (ABAC) 系统形成对比。与 ABAC 相比，RBAC 具有以下优势

另一方面，Istio 的授权系统不是传统的 RBAC 系统。它还允许用户使用属性组合定义条件。这使 Istio 能够灵活地表达复杂的访问控制策略。事实上，Istio 授权采用的“RBAC + 条件”模型具有 RBAC 系统的所有优点，并支持 ABAC 系统通常提供的灵活性级别。您将在下面看到一些示例。

高性能

由于其简单的语义，Istio 授权作为本机授权支持在 Envoy 上执行。在运行时，授权决策完全在 Envoy 过滤器内部本地完成，无需依赖任何外部模块。这使 Istio 授权能够实现高性能和可用性。

使用/不使用主身份

与任何其他 RBAC 系统一样，Istio 授权也是身份感知的。在 Istio 授权策略中，有一个名为 user 的主身份，它代表客户端的主体。

除了主身份之外，您还可以指定任何定义身份的条件。例如，您可以将客户端身份指定为“来自 Bookstore 前端服务的 Alice 用户”，在这种情况下，您拥有调用服务 (Bookstore 前端) 和最终用户 (Alice) 的组合身份。

为了提高安全性，您应该启用身份验证功能，并在授权策略中使用已验证的身份。但是，使用授权不需要强身份验证。Istio 授权在有或没有身份的情况下都能工作。如果您正在使用遗留系统，则可能没有为您的网格设置双向 TLS 或 JWT 身份验证。在这种情况下，识别客户端的唯一方法是，例如，通过 IP。您仍然可以使用 Istio 授权来控制允许哪些 IP 地址或 IP 范围访问您的服务。

示例

授权任务 向您展示了如何使用 Istio 的授权功能来使用Bookinfo 应用程序控制命名空间级别和服务级别的访问。在本节中，您将看到更多有关如何使用 Istio 授权实现微分段的示例。

通过 RBAC + 条件实现命名空间级别分段

假设您在 frontend 和 backend 命名空间中拥有服务。您希望允许 frontend 命名空间中的所有服务访问 backend 命名空间中标记为 external 的所有服务。

apiVersion: "rbac.istio.io/v1alpha1"
kind: ServiceRole
metadata:
  name: external-api-caller
  namespace: backend
spec:
  rules:
  - services: ["*"]
    methods: ["*”]
    constraints:
    - key: "destination.labels[visibility]”
      values: ["external"]
---
apiVersion: "rbac.istio.io/v1alpha1"
kind: ServiceRoleBinding
metadata:
  name: external-api-caller
  namespace: backend
spec:
  subjects:
  - properties:
      source.namespace: "frontend”
  roleRef:
    kind: ServiceRole
    name: "external-api-caller"

上面的 ServiceRole 和 ServiceRoleBinding 表达了“谁被允许在哪些条件下执行什么”（RBAC + 条件）。具体来说

使用/不使用主身份的服务/方法级别隔离

这是另一个示例，演示了在服务/方法级别进行更细粒度的访问控制。第一步是定义一个 book-reader 服务角色，该角色允许对 bookstore 服务中的 /books/* 资源进行读取访问。

apiVersion: "rbac.istio.io/v1alpha1"
kind: ServiceRole
metadata:
  name: book-reader
  namespace: default
spec:
  rules:
  - services: ["bookstore.default.svc.cluster.local"]
    paths: ["/books/*”]
    methods: ["GET”]

使用已验证的客户端身份

假设您想将此 book-reader 角色授予您的 bookstore-frontend 服务。如果您已为您的网格启用了双向 TLS 身份验证，则可以使用服务帐户来识别您的 bookstore-frontend 服务。授予 bookstore-frontend 服务 book-reader 角色可以通过创建如下所示的 ServiceRoleBinding 来完成

apiVersion: "rbac.istio.io/v1alpha1"
kind: ServiceRoleBinding
metadata:
  name: book-reader
  namespace: default
spec:
  subjects:
  - user: "cluster.local/ns/default/sa/bookstore-frontend”
  roleRef:
    kind: ServiceRole
    name: "book-reader"

您可能希望通过添加一个条件来进一步限制此操作：“只有属于 qualified-reviewer 组的用户才能阅读书籍”。qualified-reviewer 组是由JWT 身份验证验证的最终用户身份。在这种情况下，客户端服务身份 (bookstore-frontend) 和最终用户身份 (qualified-reviewer) 的组合在授权策略中使用。

apiVersion: "rbac.istio.io/v1alpha1"
kind: ServiceRoleBinding
metadata:
  name: book-reader
  namespace: default
spec:
  subjects:
  - user: "cluster.local/ns/default/sa/bookstore-frontend"
    properties:
      request.auth.claims[group]: "qualified-reviewer"
  roleRef:
    kind: ServiceRole
    name: "book-reader"

客户端没有身份

强烈建议在授权策略中使用已验证的身份来提高安全性。但是，如果您有一个不支持身份验证的遗留系统，则可能没有服务的已验证身份。即使没有已验证的身份，您仍然可以使用 Istio 授权来保护您的服务。以下示例显示您可以在授权策略中指定允许的源 IP 范围。

apiVersion: "rbac.istio.io/v1alpha1"
kind: ServiceRoleBinding
metadata:
  name: book-reader
  namespace: default
spec:
  subjects:
  - properties:
      source.ip: 10.20.0.0/9
  roleRef:
    kind: ServiceRole
    name: "book-reader"

总结

Istio 的授权功能提供命名空间级别、服务级别和方法级别的授权粒度。它采用“RBAC + 条件”模型，使其易于用作 RBAC 系统并易于理解，同时提供 ABAC 系统通常提供的灵活性级别。Istio 授权在 Envoy 上本地执行，因此可以实现高性能。虽然它通过与Istio 身份验证功能协同工作来提供最佳安全性，但 Istio 授权也可用于为没有身份验证的遗留系统提供访问控制。

分享此文章