istio访问授权

Istio授权功能是基于角色的访问控制（RBAC），支持在Istio Mesh中，为服务提供名称空间级别，服务级别和方法级别的访问控制。它具有以下特点：

• 基于角色的语义，简单易用。
• 支持服务到服务，以及终端用户到服务授权。
• 灵活性的自定义属性支持，例如角色和角色绑定中的条件。
• 高性能，Istio授权在Envoy上本地执行。
• 高兼容性，本地支持HTTP，HTTPS和HTTP2，以及任何普通的TCP协议。

1. 授权架构

Istio授权架构

上图显示了基本的Istio授权架构。运营商使用.yaml文件指定Istio授权策略。部署后，Istio将策略保存在中Istio Config Store。

Pilot监视Istio授权策略的更改。如果看到任何更改，它将获取更新的授权策略。Pilot将Istio授权策略分发给与服务实例位于同一位置的Envoy代理。

每个Envoy代理都运行一个授权引擎，该引擎在运行时对请求进行授权。当请求到达代理时，授权引擎根据当前的授权策略评估请求上下文，并返回授权结果ALLOW或DENY。

2.  启用授权

可以使用ClusterRbacConfig对象启用Istio授权。该ClusterRbacConfig 对象是集群范围内的单例，其固定名称值为default。在网格中只能使用ClusterRbacConfig一个实例。与其他Istio配置对象一样，ClusterRbacConfig被定义为Kubernetes CustomResourceDefinition （CRD）对象。

在ClusterRbacConfig对象中，操作员可以指定一个mode值，该值可以是：

• OFF：Istio授权已禁用。
• ON：已为网格中的所有服务启用Istio授权。
• ON_WITH_INCLUSION：仅对inclusion字段中指定的服务和名称空间启用Istio授权。
• ON_WITH_EXCLUSION注意：除在exclusion字段中指定的服务和名称空间外，将为网格中的所有服务启用Istio授权。

在以下示例中，为default 名称空间启用了Istio授权。

apiVersion: "rbac.istio.io/v1alpha1"
kind: ClusterRbacConfig
metadata:
  name: default
spec:
  mode: 'ON_WITH_INCLUSION'
  inclusion:
    namespaces: ["default"]

3.  授权策略

通过指定ServiceRole和 ServiceRoleBinding 来配置Istio授权策略。与其他Istio配置对象一样，它们是Kubernetes CustomResourceDefinition （CRD）对象。

• ServiceRole ：定义一组访问服务的权限。
• ServiceRoleBinding：将ServiceRole授予特定主题，例如用户，组或服务。

ServiceRole和ServiceRoleBinding组合规定：在什么条件下，谁被允许做什么。特别：

• Who：参考ServiceRoleBinding中的subjects。
• What：参考permissions的ServiceRole。
• Which condition：参考ServiceRole和ServiceRoleBinding是指conditions您可以在或中使用Istio属性指定的部分。

3.1.  ServiceRole

ServiceRole规范包括的rules的，AKA权限。每个规则都有以下标准字段：

• services：服务名称列表。可以将值设置为*，这样会包括指定名称空间中的所有服务。
• methods：HTTP方法列表。可以将值设置为*，这样会包括所有HTTP方法。不应为TCP和gRPC服务设置此字段。
• paths：HTTP路径或gRPC方法。gRPC方法必须采用/packageName.serviceName/methodName且区分大小写。

ServiceRole规格只适用于指定的命名空间。规格services字段是必须的，其他字段是可选的。如果未指定字段或将其值设置为*，则Istio将该字段应用于所有实例。

下面的示例显示一个简单的角色：service-admin，该角色对default名称空间中所有服务的具有完全访问权限。

apiVersion: "rbac.istio.io/v1alpha1"
kind: ServiceRole
metadata:
  name: service-admin
  namespace: default
spec:
  rules:
  - services: ["*"]

这里是另一个角色：products-viewer，对default命名空间下的products.default.svc.cluster.local服务，具有”GET”和”HEAD”访问权限。

apiVersion: "rbac.istio.io/v1alpha1"
kind: ServiceRole
metadata:
  name: products-viewer
  namespace: default
spec:
  rules:
  - services: ["products.default.svc.cluster.local"]
    methods: ["GET", "HEAD"]

此外，支持规则中所有字段的前缀匹配和后缀匹配。例如，可以tester在default名称空间中定义具有以下权限的角色：

• 访问所有前缀为”test-*”的服务，例如：test-bookstore，test-performance，test-api.default.svc.cluster.local。
• （”GET”）访问后缀为”*/reviews”的所有路径，例如：在default.svc.cluster.local服务中的/books/reviews，/events/booksale/reviews，/reviews。

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

在ServiceRole，组合namespace+ services+ paths+ methods定义了服务或服务如何被访问。在某些情况下，可能需要为规则指定其他条件。例如，规则可能仅适用于某个版本的服务，或仅适用于带有特定标签的服务（例如”foo”）。可以通过使用约束来实现上述的条件。

例如，以下ServiceRole定义添加了一个约束，该约束 request.headers[version]:”v1″或”v2″。约束和属性页面key中列出了约束的支持值。

apiVersion: "rbac.istio.io/v1alpha1"
kind: ServiceRole
metadata:
  name: products-viewer-version
  namespace: default
spec:
  rules:
  - services: ["products.default.svc.cluster.local"]
    methods: ["GET", "HEAD"]
    constraints:
    - key: request.headers[version]
      values: ["v1", "v2"]

3.2.  ServiceRoleBinding

ServiceRoleBinding规范包括两个部分：

• roleRef：引用相同名称空间中的ServiceRole资源。
• subjects：分配给角色的列表。

可以明确地为subjects指定一个user或带有一组属性的user。ServiceRoleBinding subjects的属性是类似于ServiceRole规范中的约束。可以通过属性使用条件来为角色分配帐户。属性它包含一个 key及其允许的值。

以下示例显示了一个名称为test-binding-products 的ServiceRoleBinding，它将两个主题绑定到名称为”product-viewer”的ServiceRole。

apiVersion: "rbac.istio.io/v1alpha1"
kind: ServiceRoleBinding
metadata:
  name: test-binding-products
  namespace: default
spec:
  subjects:
  - user: "service-account-a"
  - user: "istio-ingress-service-account"
    properties:
      request.auth.claims[email]: "a@foo.com"
  roleRef:
    kind: ServiceRole
    name: "products-viewer"

如果要使服务可以被公开访问，可以在subjects设置user: “*”。此值将分配ServiceRole给所有（经过身份验证和未经身份验证的）用户和服务，例如：

apiVersion: "rbac.istio.io/v1alpha1"
kind: ServiceRoleBinding
metadata:
name: binding-products-allusers
namespace: default
spec:
subjects:
- user: "*"
roleRef:
kind: ServiceRole
name: "products-viewer"

要将ServiceRole分配给仅通过身份验证的用户和服务，请source.principal: “*” 改用，例如：

apiVersion: "rbac.istio.io/v1alpha1"
kind: ServiceRoleBinding
metadata:
  name: binding-products-all-authenticated-users
  namespace: default
spec:
  subjects:
  - properties:
    source.principal: "*"
  roleRef:
    kind: ServiceRole
    name: "products-viewer"

4.  在纯TCP协议上使用Istio授权

服务角色和服务角色绑定的示例显示在服务上使用HTTP协议进行Istio授权的典型方法。在这些示例中，支持服务角色和服务角色绑定中的所有字段。Istio授权支持任何使用普通TCP协议（例如MongoDB）的服务，服务角色配置和服务角色绑定都是与HTTP协议一样。区别在于使用某些仅适用于HTTP服务的字段，约束和属性。这些字段包括：

• 服务角色配置对象中的paths和methods字段。
• 服务角色绑定配置对象中的group字段。

如果对TCP服务使用了仅支持HTTP的字段，则Istio会完全忽略服务角色或服务角色绑定自定义资源和策略。假设在端口27017上具有MongoDB服务，下面的示例仅允许bookinfo-ratings-v2访问MongoDB服务。

apiVersion: "rbac.istio.io/v1alpha1"
kind: ServiceRole
metadata:
name: mongodb-viewer
namespace: default
spec:
rules:
- services: ["mongodb.default.svc.cluster.local"]
constraints:
- key: "destination.port"
values: ["27017"]
---

apiVersion: "rbac.istio.io/v1alpha1"
kind: ServiceRoleBinding
metadata:
  name: bind-mongodb-viewer
  namespace: default
spec:
  subjects:
  - user: "cluster.local/ns/default/sa/bookinfo-ratings-v2"
  roleRef:
    kind: ServiceRole
    name: "mongodb-viewer"

作者简介：季向远，北京神舟航天软件技术有限公司。本文版权归原作者所有。