如何在Google Kubernetes Engine集群中通过暴露微服务安全访问未暴露微服务

Hey there! Let's walk through how to securely enable end users to access your internal microservices B, C, and D via the exposed Microservice A on Google Kubernetes Engine (GKE). I’ve got a few solid, production-ready approaches for you based on common GKE patterns:

This is the most scalable and manageable approach for complex microservice setups, as it offloads security, routing, and observability to a dedicated layer.

• Enable Istio on your GKE cluster: Use the GKE Istio add-on to avoid manual deployment. Run this command:

  gcloud container clusters update YOUR_CLUSTER_NAME --zone YOUR_CLUSTER_ZONE --enable-istio
  

• Inject sidecar proxies: Label your namespace to auto-inject Istio sidecars into all pods (including A, B, C, D):

  kubectl label namespace default istio-injection=enabled
  

• Route traffic through Microservice A: Create an Istio VirtualService that maps specific paths from A to your internal services. For example:

  apiVersion: networking.istio.io/v1alpha3
  kind: VirtualService
  metadata:
    name: service-a-routes
  spec:
    hosts: ["service-a.your-domain.com"]
    http:
    - match:
      - uri:
          prefix: "/api/b"
      route:
      - destination:
          host: microservice-b.default.svc.cluster.local
          port:
            number: 8080
    - match:
      - uri:
          prefix: "/api/c"
      route:
      - destination:
          host: microservice-c.default.svc.cluster.local
          port:
            number: 8080
    - match:
      - uri:
          prefix: "/api/d"
      route:
      - destination:
          host: microservice-d.default.svc.cluster.local
          port:
            number: 8080
  

• Enforce secure service-to-service communication: Enable mutual TLS (mTLS) between all services using Istio DestinationRule and PeerAuthentication to encrypt internal traffic and prevent unauthorized access.
• Add access control: Create an Istio AuthorizationPolicy to only allow requests originating from Microservice A to reach B, C, D. You can also add JWT validation here to ensure end users are authenticated before requests reach any service.

If you prefer a lighter-weight approach without a service mesh, you can turn Microservice A into an authenticated gateway that forwards requests to internal services.

• Integrate reverse proxy logic: Use a library like Envoy (as a sidecar or embedded), Nginx, or your language's HTTP client to forward requests from A to B/C/D. Reference internal services using their ClusterIP DNS names (e.g., microservice-b.default.svc.cluster.local).
• Authenticate end users first: Before forwarding requests, validate user identity in A using standards like OAuth2.0, OpenID Connect, or signed JWT tokens. Reject unauthenticated requests immediately.
• Encrypt internal traffic: Enable mTLS between A and the internal services. You can use GCP Certificate Manager to issue internal TLS certificates, or use GKE Workload Identity to manage service account credentials for mutual auth.
• Lock down network access: Use GKE NetworkPolicy to restrict traffic to B/C/D so only Microservice A's pods can connect. Example policy for Microservice B:

  apiVersion: networking.k8s.io/v1
  kind: NetworkPolicy
  metadata:
    name: allow-only-from-a
    namespace: default
  spec:
    podSelector:
      matchLabels:
        app: microservice-b
    ingress:
    - from:
      - podSelector:
          matchLabels:
            app: microservice-a
      ports:
      - protocol: TCP
        port: 8080
  

For teams using GCP's managed networking tools, combining internal load balancers with A as a gateway works well for simpler setups.

• Deploy internal load balancers for B/C/D: Configure each internal service to use a GKE Internal Load Balancer (ILB) so they're only accessible within your VPC, not the public internet.
• Forward validated requests from A: In Microservice A, after authenticating end users, forward requests to the ILB IP addresses of B/C/D.
• Restrict VPC traffic: Use GCP VPC firewall rules to allow only traffic from Microservice A's node pool to the ILB IP ranges. Pair this with GKE NetworkPolicies for an extra layer of pod-level security.

• Always expose Microservice A via HTTPS: Use GKE Ingress with a managed SSL certificate from GCP Certificate Manager to encrypt public traffic.
• Least privilege access: Use GKE Workload Identity to assign minimal permissions to each service's service account, so A only has the access it needs to reach B/C/D.
• Audit and monitor: Enable GKE logging and monitoring to track all requests from end users through A to internal services. Set up alerts for unusual traffic patterns.
• Rotate credentials regularly: Automate rotation of TLS certificates, API keys, and service account keys to reduce the risk of credential leaks.

内容的提问来源于stack exchange，提问作者Ram