基于 Istio 授权的 Micro-Segmentation

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

Jul 20, 2018 | 作者 Limin Wang

Micro-Segmentation 是一种安全技术，可在云部署中创建安全区域，并允许各组织将工作负载彼此隔离以单独保护它们。 Istio 的授权功能也称为 Istio 基于角色的访问控制，为 Istio 网格中的服务提供 Micro-Segmentation。它的特点是：

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

特点

RPC 级别授权

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

具有条件的基于角色的访问控制

授权是基于角色的访问控制（RBAC） 系统， 将此与基于属性的访问控制（ABAC） 系统对比。 与 ABAC 相比，RBAC 具有以下优势：

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

高性能

由于其简单的语义，Istio 授权直接在 Envoy 本地执行。在运行时，授权决策完全在 Envoy 过滤器内部完成，不依赖于任何外部模块。 这允许 Istio 授权实现高性能和可用性。

使用/不使用主要标识

与任何其他 RBAC 系统一样，Istio 授权具有身份识别功能。在 Istio 授权政策中，有一个主要的 身份称为 user，代表客户的主体。

除主要标识外，您还可以自己定义标识。例如，您可以将客户端标识指定为“用户 Alice 从 Bookstore 前端服务调用”，在这种情况下， 你有一个调用服务（Bookstore frontend）和最终用户（Alice）的组合身份。

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

示例

授权任务通过 Bookinfo 应用向您展示如何使用 Istio 的授权功能来控制命名空间级别 和服务级别的访问。在本节中，您将看到更多使用 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 ServiceRole，它允许对 bookstore 服务中的 /books/* 资源进行 READ 访问。

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 服务。授予 book-reader 角色到 bookstore-frontend 服务可以通过创建一个 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 认证功能一起提供最佳的安全性，也可以用于为没有身份验证的旧系统提供访问控制。

Share this post