利用Istio与OIDC为GKE上的SSR应用实现零信任边缘认证授权

云原生

文章字数: 3.4k

阅读时长: 14 分

在真实项目中，为服务端渲染（SSR）应用实施认证授权总是一个棘手的平衡问题。传统的做法是将session管理、cookie解析、token验证等逻辑全部塞进SSR应用本身。这不仅污染了业务代码，而且在微服务架构下，当SSR应用需要调用下游服务时，如何安全地传递用户身份，又会引出一系列新的复杂性。我们的目标是将认证逻辑从应用中剥离，下沉到基础设施层，由服务网格在边缘完成所有验证，应用只消费一个可信的身份标识。这正是零信任网络的核心思想：永不信任，始终验证。

我们的战场是GKE，武器是Istio，身份标准是OIDC。挑战在于，Istio的JWT验证机制与SSR应用的请求生命周期并非天然契合。当一个请求到达Istio Ingress Gateway时，网格可以验证JWT，但随后呢？如何将验证后的用户身份安全、无感地传递给后端Next.js应用进行页面渲染？渲染过程中，Next.js服务又该如何以该用户的身份，向更后端的API服务发起请求？这便是我们今天要解决的全部问题。

技术痛点与初步构想

SSR应用的认证流程通常如下：

用户浏览器携带Cookie或Authorization头访问SSR页面。
SSR服务器（如Node.js）解析凭证，验证其有效性。
如果需要，服务器在渲染前调用内部API获取数据，此时需要携带某种凭证。
服务器渲染HTML并返回给用户。

这里的痛点很明显：

认证逻辑耦合：SSR应用必须包含完整的OIDC客户端库、密钥管理、token刷新逻辑。
凭证传递复杂：SSR服务器如何安全地为后端API调用创建或转发凭证？直接转发用户JWT可能导致安全风险和不必要的权限暴露。
策略不一致：每个应用都可能有一套略有不同的认证实现，难以统一实施安全策略，如要求特定的JWT scope。

我们的构想是利用Istio作为策略执行点（PEP），将上述流程改造为：

sequenceDiagram
    participant User as 用户浏览器
    participant Gateway as Istio Ingress Gateway
    participant SSR as SSR应用 (Next.js)
    participant API as 后端API服务

    User->>+Gateway: GET /dashboard (携带JWT)
    Gateway->>Gateway: 1. 验证JWT (OIDC)
    Note over Gateway: 检查签名, issuer, audience
    Gateway->>+SSR: GET /dashboard (注入用户身份头 `x-identity-payload`)
    SSR->>+API: GET /api/user-data
    Note over API: API仅需验证调用方是SSR服务 (mTLS)
    API-->>-SSR: 返回用户数据
    SSR->>SSR: 2. 使用数据渲染页面
    SSR-->>-Gateway: 返回HTML
    Gateway-->>-User: 返回HTML

在这个模型中：

Istio Ingress Gateway 负责所有入口流量的OIDC JWT验证。无效请求在进入网格前就被拒绝。
验证通过后，Istio将JWT中的关键claims提取出来，注入到一个安全的HTTP Header中，再转发给SSR应用。
SSR应用不再处理任何JWT验证逻辑。它完全信任上游（Istio Proxy）注入的Header，并将其作为用户身份的唯一来源。
当SSR应用需要调用后端API时，它不需要传递任何用户凭证。因为在Istio服务网格内，服务间的通信默认启用mTLS，后端API只需配置一个授权策略，允许来自SSR服务身份的调用即可。

这套架构将用户认证（Authentication）和应用内授权（Authorization）清晰地分离，实现了真正的零信任。

环境准备与应用部署

首先，一个标准的GKE集群是基础。为了更好地控制Istio，我们选择标准版集群而非Autopilot。

# 创建一个GKE标准集群
gcloud container clusters create "zero-trust-ssr" \
  --zone "asia-east1-b" \
  --machine-type "e2-standard-4" \
  --num-nodes "3" \
  --workload-pool "your-gcp-project.svc.id.goog"

# 安装Istio
# 我们使用istioctl进行安装，以获得对配置文件的完全控制
istioctl install --set profile=demo -y

# 为默认命名空间启用Istio sidecar自动注入
kubectl label namespace default istio-injection=enabled

接下来，我们部署两个简单的示例服务：一个Next.js SSR应用和一个Express后端API。

SSR应用 (ssr-app/)

这是一个Next.js应用，它有一个需要登录才能访问的页面/profile。它会从BACKEND_API_URL环境变量指向的地址获取用户数据。

// ssr-app/pages/profile.js
import { Buffer } from 'buffer';

function Profile({ user }) {
  if (!user) {
    return <div>Loading or not authenticated...</div>;
  }
  return (
    <div>
      <h1>Profile Page</h1>
      <pre>{JSON.stringify(user, null, 2)}</pre>
    </div>
  );
}

export async function getServerSideProps(context) {
  // 关键：在服务端从Istio注入的Header中读取用户身份
  const identityHeader = context.req.headers['x-jwt-payload'];
  if (!identityHeader) {
    // 如果没有这个header，说明请求未通过Istio的认证，可以重定向或返回错误
    // 在生产环境中，应该返回一个更友好的页面或重定向到登录页
    return { props: { user: null } };
  }

  try {
    const claims = JSON.parse(Buffer.from(identityHeader, 'base64').toString('utf-8'));
    
    // SSR服务器调用后端API获取更多数据
    // 注意：这里的调用不需要附带任何认证信息
    // 因为服务间的认证由Istio的mTLS处理
    const backendApiUrl = process.env.BACKEND_API_URL || 'http://backend-api.default.svc.cluster.local:8080/data';
    const res = await fetch(`${backendApiUrl}?userId=${claims.sub}`);
    
    if (!res.ok) {
        throw new Error(`Backend API call failed with status: ${res.status}`);
    }

    const data = await res.json();

    return {
      props: {
        user: {
          claims_from_gateway: claims,
          data_from_backend: data,
        },
      },
    };
  } catch (error) {
    console.error("Error in getServerSideProps:", error);
    // 错误处理：在生产环境中，这里应该记录详细日志
    return { props: { user: null } };
  }
}

export default Profile;

这里的核心在于getServerSideProps。它不再关心cookie或token，而是直接读取x-jwt-payload头。这是一个重要的约定，SSR应用假设这个头是可信的，因为它只能由Istio注入。

后端API (backend-api/)

一个简单的Express服务器，它不需要任何认证逻辑。

// backend-api/index.js
const express = require('express');
const app = express();
const port = 8080;

app.get('/data', (req, res) => {
  const userId = req.query.userId;
  if (!userId) {
    return res.status(400).json({ error: 'userId is required' });
  }

  // 模拟从数据库获取数据
  console.log(`Fetching data for user: ${userId}`);
  res.json({
    userId: userId,
    sensitiveData: `This is sensitive data for user ${userId} fetched at ${new Date().toISOString()}`
  });
});

app.listen(port, () => {
  console.log(`Backend API listening on port ${port}`);
});

我们将这两个应用容器化并部署到GKE。

# kubernetes-manifests.yaml

apiVersion: v1
kind: Service
metadata:
  name: ssr-app
spec:
  selector:
    app: ssr-app
  ports:
    - protocol: TCP
      port: 80
      targetPort: 3000
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: ssr-app
spec:
  replicas: 1
  selector:
    matchLabels:
      app: ssr-app
  template:
    metadata:
      labels:
        app: ssr-app
    spec:
      containers:
        - name: ssr-app
          image: gcr.io/your-gcp-project/ssr-app:v1
          ports:
            - containerPort: 3000
          env:
            - name: BACKEND_API_URL
              value: "http://backend-api.default.svc.cluster.local:8080/data"
---
apiVersion: v1
kind: Service
metadata:
  name: backend-api
spec:
  selector:
    app: backend-api
  ports:
    - protocol: TCP
      port: 8080
      targetPort: 8080
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: backend-api
spec:
  replicas: 1
  selector:
    matchLabels:
      app: backend-api
  template:
    metadata:
      labels:
        app: backend-api
    spec:
      containers:
        - name: backend-api
          image: gcr.io/your-gcp-project/backend-api:v1
          ports:
            - containerPort: 8080

配置Istio边缘认证

现在是核心部分。我们将配置Istio Ingress Gateway来处理OIDC认证。你需要一个OIDC提供商，如Auth0, Okta, 或Google Identity Platform。我们将以Google为例。

Gateway和VirtualService

首先，暴露ssr-app服务到公网。

# gateway.yaml
apiVersion: networking.istio.io/v1beta1
kind: Gateway
metadata:
  name: ssr-gateway
spec:
  selector:
    istio: ingressgateway # use istio default ingress gateway
  servers:
    - port:
        number: 80
        name: http
        protocol: HTTP
      hosts:
        - "*" # 在生产中应使用具体域名
---
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: ssr-vs
spec:
  hosts:
    - "*"
  gateways:
    - ssr-gateway
  http:
    - route:
        - destination:
            host: ssr-app
            port:
              number: 80

RequestAuthentication 和 AuthorizationPolicy

这是实现零信任边缘认证的关键。

RequestAuthentication：定义Istio如何验证JWT。
AuthorizationPolicy：定义哪些请求被允许或拒绝。

# auth.yaml
apiVersion: security.istio.io/v1beta1
kind: RequestAuthentication
metadata:
  name: jwt-on-gateway
  namespace: istio-system # 应用于Ingress Gateway
spec:
  selector:
    matchLabels:
      istio: ingressgateway
  jwtRules:
  - issuer: "https://accounts.google.com" # OIDC提供商的issuer
    jwksUri: "https://www.googleapis.com/oauth2/v3/certs" # OIDC提供商的JWKS地址
    # 关键：将JWT payload转发到上游服务
    # Istio会base64编码这个JSON payload
    outputPayloadToHeader: "x-jwt-payload"
---
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: require-jwt-for-profile
  namespace: default # 应用于ssr-app所在命名空间
spec:
  selector:
    matchLabels:
      app: ssr-app # 策略作用于ssr-app
  action: ALLOW
  rules:
  # 规则1: 允许对根路径'/'的无认证访问 (例如首页)
  - to:
    - operation:
        paths: ["/"]
        methods: ["GET"]
  # 规则2: 要求访问/profile路径必须有有效的JWT
  - to:
    - operation:
        paths: ["/profile"]
        methods: ["GET"]
    from:
    - source:
        # 这里的requestPrincipals: ["*"]表示只要JWT有效即可
        # 它会匹配RequestAuthentication中定义的issuer
        requestPrincipals: ["*"]

代码解析:

RequestAuthentication被部署在istio-system命名空间并作用于istio: ingressgateway，这意味着它只在流量入口处生效。
issuer和jwksUri是OIDC的核心元数据。Istio会用jwksUri获取公钥来验证JWT签名。你可以在OIDC提供商的.well-known/openid-configuration端点找到这些信息。
outputPayloadToHeader: "x-jwt-payload"是连接Istio和SSR应用的关键。它告诉Istio将验证通过的JWT载荷（claims）放入名为x-jwt-payload的Header中。这是一个常见的错误点，忘记这个配置，应用将无法获取用户身份。
AuthorizationPolicy在default命名空间，作用于ssr-app。它定义了两条规则：
- 对网站首页/的访问是无条件允许的。
- 对/profile的访问，必须from一个有效的requestPrincipals。"*"是一个通配符，表示只要请求中携带的JWT通过了RequestAuthentication的验证，就满足此条件。

应用这些YAML后，流量路径变为：

访问/：无需JWT，直接通过。
访问/profile无JWT：请求在Ingress Gateway被AuthorizationPolicy拒绝，返回403 Forbidden。
访问/profile有有效JWT：请求通过验证，Istio注入x-jwt-payload头，请求被转发到ssr-app。

服务间认证：从SSR到后端API

现在，SSR应用可以获取用户身份了。但当它调用backend-api时，我们如何确保这个调用是合法的？我们不能简单地让backend-api暴露在集群网络中任由调用。

我们将使用Istio的mTLS和服务身份来解决这个问题。

# backend-api-auth.yaml
apiVersion: security.istio.io/v1beta1
kind: PeerAuthentication
metadata:
  name: default-mtls
  namespace: default
spec:
  # 在整个命名空间强制开启严格mTLS模式
  mtls:
    mode: STRICT
---
apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: backend-api-access-control
  namespace: default
spec:
  selector:
    matchLabels:
      app: backend-api # 此策略只作用于backend-api服务
  action: ALLOW
  rules:
  - from:
    - source:
        # 关键: 只允许来自特定服务账户的请求
        # 'cluster.local/ns/default/sa/default'是ssr-app Pod默认使用的服务账户
        # 在生产环境中，应该为每个应用创建专门的服务账户
        principals: ["cluster.local/ns/default/sa/default"]
    to:
    - operation:
        methods: ["GET"]
        paths: ["/data"]

代码解析:

PeerAuthentication设置为STRICT模式，强制default命名空间内的所有服务间通信都必须使用mTLS加密。任何非mTLS的请求都会被拒绝。
AuthorizationPolicy (backend-api-access-control) 非常关键。它规定只有source.principals中列出的身份才能访问backend-api。
- cluster.local/ns/default/sa/default是Kubernetes服务账户的SPIFFE ID格式。它唯一标识了default命名空间中使用default服务账户运行的Pod。由于我们的ssr-app没有指定serviceAccountName，它就使用这个默认账户。
- 这意味着，只有ssr-app的Pod发出的请求才会被backend-api接受。集群内其他任何Pod，即使知道backend-api的地址，其请求也会因为身份不匹配而被Istio sidecar拒绝。

至此，我们完成了端到端的零信任链路。用户身份在边缘验证，服务身份在网格内部验证。backend-api完全不需要知道”用户”是谁，它只需要信任调用方是合法的ssr-app服务即可。

方案局限性与未来展望

这个方案优雅地解决了认证逻辑与业务逻辑的解耦，但它并非万能药。在真实项目中，需要考虑以下几点：

Token生命周期管理: x-jwt-payload头只是JWT声明的一个快照。如果原始JWT在用户的浏览器端过期，SSR应用是无感的。已建立的服务端会话（如果存在）可能会继续使用过期的身份信息。这个方案更适合无状态、请求级别的授权，而不是长会话管理。
Header大小: 如果JWT的claims非常多，x-jwt-payload头可能会很大，对网络传输造成轻微影响。应确保只在JWT中存放必要的身份信息。
服务账户粒度: 在示例中我们使用了default服务账户，这是一个坏习惯。生产环境中，必须为每个微服务创建专用的Kubernetes ServiceAccount，并在AuthorizationPolicy中精确地指定，以实现最小权限原则。
更复杂的授权逻辑: 如果后端API的授权逻辑依赖于用户的具体角色或权限（例如，只有”admin”角色的用户才能调用某个接口），那么ssr-app就需要解析x-jwt-payload，并将用户的角色信息通过另一种方式（如另一个Header）传递给backend-api。此时，backend-api需要重新信任ssr-app传递的这个角色信息。整个信任链条需要被仔细设计。

一个可能的演进方向是，引入一个内部的安全令牌服务（STS）。ssr-app在收到带有x-jwt-payload的请求后，可以调用内部STS，用这个payload去换取一个生命周期更短、权限更受限的内部令牌，然后用这个内部令牌去调用下游服务。这种方式增加了系统的复杂性，但提供了更精细的访问控制和更好的安全隔离。

SSR Istio GCP GKE OpenID Connect (OIDC)

利用CDC与Docker Swarm实现由MariaDB驱动的Gatsby站点增量构建

2023-10-27 数据工程与DevOps

MariaDB GitHub Gatsby Docker Swarm Debezium Kafka CDC

构建基于 Django 动态模型的低代码平台及其 Qwik 前端渲染与 PostCSS 隔离样式方案

2023-10-27 架构设计

Django Qwik PostCSS 数据处理