基于Istio结合Firebase实现GKE后端JWT终端用户认证方案咨询

Hey there! Let's break down how to implement Firebase token validation with Istio on your GKE cluster—since you've found Ingress-GCE can't handle this requirement, Istio's auth capabilities are exactly what you need. You're already using GLCB for path-based routing, so we'll layer Istio's token checking on top to ensure only valid requests reach your backends.

Prerequisites First #

• Make sure your GKE cluster has Istio installed (use istioctl or the Istio Operator, and confirm sidecar injection is enabled for your backend namespaces)
• Have your Firebase project ID handy, plus a service account key for Istio to communicate with Firebase (if needed for advanced use cases)
• Ensure your backend services have Istio sidecars injected—check with kubectl get pods to see the istio-proxy container in each pod

Step 1: Configure Istio to Validate Firebase JWT Tokens #

Istio has built-in JWT validation, and we can point it directly at Firebase's public keys to verify tokens. Firebase's JWT issuer is https://securetoken.google.com/<YOUR-FIREBASE-PROJECT-ID>, and Istio can automatically fetch its public keys.

Create a RequestAuthentication resource to define the validation rules:

apiVersion: security.istio.io/v1beta1
kind: RequestAuthentication
metadata:
  name: firebase-jwt-validator
  namespace: <YOUR-BACKEND-NAMESPACE> # Replace with your backend's namespace
spec:
  selector:
    matchLabels:
      app: <YOUR-BACKEND-APP-LABEL> # Target your backend service via labels
  jwtRules:
  - issuer: "https://securetoken.google.com/<YOUR-FIREBASE-PROJECT-ID>"
    jwksUri: "https://www.googleapis.com/service_accounts/v1/metadata/x509/securetoken@system.gserviceaccount.com"
    fromHeaders:
    - name: Authorization
      prefix: "Bearer "
    # Optional: Pass token payload to backend in a header
    outputPayloadToHeader: "X-Firebase-User-Payload"

This tells Istio's sidecar to pull the Bearer token from the Authorization header, verify it against Firebase's public keys, and confirm the issuer matches your Firebase project.

Step 2: Enforce Authentication with an Authorization Policy #

Validating the token is half the battle—we need to block any request that fails validation. Create an AuthorizationPolicy to allow only authenticated requests:

apiVersion: security.istio.io/v1beta1
kind: AuthorizationPolicy
metadata:
  name: require-firebase-token
  namespace: <YOUR-BACKEND-NAMESPACE>
spec:
  selector:
    matchLabels:
      app: <YOUR-BACKEND-APP-LABEL>
  action: ALLOW
  rules:
  - from:
    - source:
        requestPrincipals: ["*"] # Allow any request that passed JWT validation
  # Optional: Restrict to specific paths if needed
  - to:
    - operation:
        paths: ["/api/*", "/services/*"] # Add your protected paths here

Requests without a valid token will get a 401 Unauthorized response immediately, no need to reach your backend.

Step 3: Integrate with GLCB (Ingress-GCP) #

Since you're already using GLCB for path routing, you have two options to connect it with Istio:

Option 1: Forward GLCB Traffic to Istio IngressGateway #

Update your GLCB Ingress to send all traffic to Istio's gateway first:

apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  name: glcb-ingress
  annotations:
    kubernetes.io/ingress.class: "gce"
spec:
  rules:
  - http:
      paths:
      - path: "/api/*"
        pathType: Prefix
        backend:
          service:
            name: istio-ingressgateway
            port:
              number: 80

Then use an Istio VirtualService to handle path routing to your backends:

apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata:
  name: backend-router
  namespace: istio-system
spec:
  hosts:
  - "<YOUR-DOMAIN>" # Replace with your custom domain
  gateways:
  - istio-ingressgateway
  http:
  - match:
    - uri:
        prefix: "/api/service-a"
    route:
    - destination:
        host: service-a.<YOUR-BACKEND-NAMESPACE>.svc.cluster.local
        port:
          number: 80
  - match:
    - uri:
        prefix: "/api/service-b"
    route:
    - destination:
        host: service-b.<YOUR-BACKEND-NAMESPACE>.svc.cluster.local
        port:
          number: 80

This way, requests flow: User → GLCB → Istio Gateway (token check) → Backend Service.

Option 2: Replace GLCB with Istio Gateway (Recommended) #

If you can shift fully to Istio's gateway, you'll get tighter integration with all its features. Create an Istio Gateway:

apiVersion: networking.istio.io/v1beta1
kind: Gateway
metadata:
  name: external-gateway
  namespace: istio-system
spec:
  selector:
    istio: ingressgateway
  servers:
  - port:
      number: 80
      name: http
      protocol: HTTP
    hosts:
    - "<YOUR-DOMAIN>"
  - port:
      number: 443
      name: https
      protocol: HTTPS
    tls:
      mode: SIMPLE
      credentialName: "<YOUR-TLS-SECRET>" # Add your SSL cert secret here
    hosts:
    - "<YOUR-DOMAIN>"

Use the same VirtualService from Option 1 to handle path routing, and apply your RequestAuthentication/AuthorizationPolicy to your backends. Now traffic goes directly to Istio, skipping GLCB entirely.

Step 4: Test It Out #

• Send a request without a token: curl -v https://<YOUR-DOMAIN>/api/service-a → Should return 401.
• Send a request with a valid Firebase token: curl -v -H "Authorization: Bearer <VALID-FIREBASE-TOKEN>" https://<YOUR-DOMAIN>/api/service-a → Should successfully reach your backend.

Quick Notes #

• Istio automatically validates the aud (audience) field in the Firebase token—make sure it matches your Firebase project ID. If you need to skip this, add skipAudienceValidation: true to the jwtRules.
• The outputPayloadToHeader setting lets your backend read user data from the token without re-validating it—super handy for personalization or authorization checks.

内容的提问来源于stack exchange，提问作者Jithin Kumar S