Service Mesh实战：用Envoy Filter构建基于角色的访问控制（RBAC）

2025/8/19 17:43:20 131 0 0 0

Service Mesh实战：用Envoy Filter构建基于角色的访问控制（RBAC）

在微服务架构中，Service Mesh作为基础设施层，负责处理服务间的通信。而访问控制是Service Mesh中至关重要的一环，它决定了哪些服务可以访问哪些资源。本文将深入探讨如何在Service Mesh中，利用Envoy Filter实现基于角色的访问控制（RBAC），从而构建更安全、更灵活的微服务系统。

1. 什么是Envoy Filter？

Envoy 是一个高性能的代理，通常作为 Service Mesh 的数据平面。Envoy Filter 允许你在 Envoy 的请求处理流程中插入自定义逻辑，从而实现各种高级功能，例如：

流量修改: 修改请求头、请求体，实现流量染色、重定向等。
认证鉴权: 对请求进行身份验证和授权，例如 JWT 验证、RBAC 等。
可观测性: 收集请求指标、生成追踪数据，提升系统可观测性。
自定义协议支持: 支持自定义协议的解析和处理。

Envoy Filter 的强大之处在于其灵活性和可扩展性，你可以根据实际需求编写自定义 Filter，实现各种复杂的业务逻辑。

2. 为什么选择基于角色的访问控制（RBAC）？

传统的访问控制往往基于用户身份，但在微服务架构中，服务间的调用关系复杂，直接管理用户身份变得困难。RBAC 则将权限与角色关联，用户通过扮演不同的角色来获得相应的权限。RBAC 的优势在于：

简化权限管理: 角色作为权限的集合，降低了权限管理的复杂度。
提高可维护性: 当用户权限发生变化时，只需修改用户的角色，无需修改每个服务的访问控制策略。
增强安全性: 通过细粒度的角色划分，可以限制用户的访问范围，降低安全风险。

3. 如何使用 Envoy Filter 实现 RBAC？

实现基于角色的访问控制，通常需要以下几个步骤：

3.1. 身份验证（Authentication）

首先，需要验证请求的身份。常见的身份验证方式包括：

JWT (JSON Web Token): 服务可以使用 JWT 来传递身份信息。Envoy 可以配置 JWT 验证 Filter，从请求头或 Cookie 中提取 JWT，并验证其签名和有效期。

示例配置 (envoy.filters.http.jwt_authn):

http_filters:
- name: envoy.filters.http.jwt_authn
  typed_config:
    "@type": type.googleapis.com/envoy.extensions.filters.http.jwt_authn.v3.JwtAuthentication
    providers:
      auth_provider:
        issuer: "https://example.com/"
        jwks_uri: "https://example.com/.well-known/jwks.json"
        jwt_headers:
        - name: "Authorization"
          prefix: "Bearer "

Mutual TLS (mTLS): 服务可以使用 mTLS 来进行身份验证。Envoy 可以配置 mTLS 验证，验证客户端证书的有效性。
- 示例配置 (envoy.filters.http.tls_inspector):
```
http_filters:
- name: envoy.filters.http.tls_inspector
  typed_config:
    "@type": type.googleapis.com/envoy.extensions.filters.http.tls_inspector.v3.TlsInspector
```

3.2. 角色提取（Role Extraction）

身份验证成功后，需要从身份信息中提取用户的角色。角色的提取方式取决于身份验证的方式：

JWT: 可以从 JWT 的 payload 中提取角色信息。
- 例如，如果 JWT 的 payload 包含 "roles": ["admin", "user"]，则可以提取出 admin 和 user 两个角色。
mTLS: 可以从客户端证书的 Subject Alternative Name (SAN) 中提取角色信息。
- 例如，如果客户端证书的 SAN 包含 spiffe://example.com/ns/default/sa/admin，则可以提取出 admin 角色。

3.3. 授权（Authorization）

最后，需要根据用户的角色和请求的资源，判断用户是否具有访问权限。Envoy 可以配置 Authorization Filter，根据 RBAC 策略进行授权。

示例配置 (envoy.filters.http.rbac):

http_filters:
- name: envoy.filters.http.rbac
  typed_config:
    "@type": type.googleapis.com/envoy.extensions.filters.http.rbac.v3.RBAC
    rules:
      policies:
        "policy_admin":
          permissions:
          - any: true # 允许所有请求
          principals:
          - authenticated: # 必须经过身份验证
              principal_name:
                exact: "admin"
        "policy_user":
          permissions:
          - prefix: "/api/v1/"
          principals:
          - authenticated: # 必须经过身份验证
              principal_name:
                exact: "user"
    shadow_rules:
      policies:
        "policy_shadow":
          permissions:
          - any: true
          principals:
          - any: true

解释:
- rules.policies 定义了 RBAC 策略。
- permissions 定义了允许访问的资源。可以使用 any: true 允许所有资源，也可以使用 prefix、path 等匹配特定的 URL。
- principals 定义了允许访问的用户。可以使用 authenticated: true 允许所有经过身份验证的用户，也可以使用 principal_name 匹配特定的用户名或角色。
- shadow_rules 定义了影子规则，用于在不强制执行策略的情况下收集 RBAC 策略的执行情况。

4. 示例：基于 JWT 的 RBAC

假设我们有一个微服务 product-service，需要根据用户的角色来控制访问权限。

角色:
- admin: 可以访问所有 API。
- user: 只能访问 /api/v1/products。
步骤:
1. 配置 JWT 验证 Filter: 在 product-service 的 Envoy 配置中，添加 JWT 验证 Filter，验证请求中的 JWT。
2. 配置 RBAC Filter: 在 JWT 验证 Filter 之后，添加 RBAC Filter，根据用户的角色和请求的 URL 进行授权。

Envoy 配置示例:

static_resources:
  listeners:
  - name: listener_0
    address:
      socket_address:
        address: 0.0.0.0
        port_value: 8080
    filter_chains:
    - filters:
      - name: envoy.filters.network.http_connection_manager
        typed_config:
          "@type": type.googleapis.com/envoy.extensions.filters.network.http_connection_manager.v3.HttpConnectionManager
          stat_prefix: ingress_http
          route_config:
            name: local_route
            virtual_hosts:
            - name: local_service
              domains:
              - "*"
              routes:
              - match:
                  prefix: "/api/v1/products"
                route:
                  cluster: product_service
              - match:
                  prefix: "/"
                route:
                  cluster: product_service
          http_filters:
          - name: envoy.filters.http.jwt_authn
            typed_config:
              "@type": type.googleapis.com/envoy.extensions.filters.http.jwt_authn.v3.JwtAuthentication
              providers:
                auth_provider:
                  issuer: "https://example.com/"
                  jwks_uri: "https://example.com/.well-known/jwks.json"
                  jwt_headers:
                  - name: "Authorization"
                    prefix: "Bearer "
                  payload_in_metadata: "jwt_payload"
          - name: envoy.filters.http.rbac
            typed_config:
              "@type": type.googleapis.com/envoy.extensions.filters.http.rbac.v3.RBAC
              rules:
                policies:
                  "policy_admin":
                    permissions:
                    - any: true
                    principals:
                    - any: true # 允许所有经过身份验证的用户
                  "policy_user":
                    permissions:
                    - prefix: "/api/v1/products"
                    principals:
                    - any: true # 允许所有经过身份验证的用户
              shadow_rules:
                policies:
                  "policy_shadow":
                    permissions:
                    - any: true
                    principals:
                    - any: true
  clusters:
  - name: product_service
    connect_timeout: 0.25s
    type: STRICT_DNS
    lb_policy: ROUND_ROBIN
    load_assignment:
      cluster_name: product_service
      endpoints:
      - lb_endpoints:
        - endpoint:
            address:
              socket_address:
                address: 127.0.0.1
                port_value: 9000

测试:
1. 生成 JWT: 生成包含 "roles": ["admin"] 的 JWT，发送到 product-service 的任何 API，应该可以访问。
2. 生成 JWT: 生成包含 "roles": ["user"] 的 JWT，发送到 product-service 的 /api/v1/products，应该可以访问。发送到其他 API，应该被拒绝。

5. 常见问题与解决方案

RBAC 策略过于复杂: 可以将 RBAC 策略分解为更小的、更易于管理的策略。
性能问题: RBAC 策略的评估会消耗一定的资源。可以通过缓存 RBAC 策略评估结果来提高性能。
调试困难: 可以使用 Envoy 的 tracing 功能来跟踪请求的 RBAC 策略评估过程。

6. 总结

通过 Envoy Filter，我们可以轻松地在 Service Mesh 中实现基于角色的访问控制（RBAC）。RBAC 可以帮助我们构建更安全、更灵活的微服务系统。本文详细介绍了 Envoy Filter 的概念、RBAC 的原理，以及如何配置 Envoy Filter 来实现 RBAC。希望本文能够帮助你更好地理解和应用 Envoy Filter，构建更强大的 Service Mesh。

希望这篇文章能够帮助你理解如何在 Service Mesh 中使用 Envoy Filter 实现 RBAC。理解了这些，你就能更好地保护你的微服务应用了！

Envoy探索者 Service Mesh Envoy Filter RBAC

Service Mesh实战：用Envoy Filter构建基于角色的访问控制（RBAC）