API Gateway and Istio: Clear North-South and East-West Boundaries

An API gateway and Istio can complement each other, but only when each policy has one clear owner. A common design gives the API gateway the public API contract—consumer authentication, quotas, version routing, and request transformation—while Istio protects and observes workload-to-workload traffic inside the mesh. That division is a starting point, not a rule: Istio's ingress gateway may be sufficient when the public edge needs only the capabilities it already provides.

The dangerous design is an accidental stack. Two gateways validate different tokens, append different client addresses, retry the same request, and report incompatible route names. This guide shows how to choose a topology, define the identity handoff, and verify the complete path before production traffic moves.

The Istio behavior in this guide is reviewed against Istio 1.31.1. Pin the patch release and Gateway API CRDs used by the deployment, because a floating documentation page is not a production version contract.

Key Takeaways

• Start with responsibilities, not products: public API policy, mesh identity, application authorization, and network exposure need named owners.
• Use one permitted public path. An Istio ingress endpoint or workload service that remains directly reachable can bypass edge policy.
• Istio RequestAuthentication validates credentials that are present; an accompanying authorization policy is needed when credentials must be present.
• Mesh mutual TLS authenticates workloads, not end users, and does not replace authorization.
• Put retries, timeouts, and traffic splitting at the layer with the required context, then test the combined deadline and replay behavior.

Separate the Responsibility Planes

This allocation is deliberately conditional. If Istio ingress owns the public API policy, it is serving the gateway role for that boundary. If a separate API gateway owns that role, Istio should not silently recreate a conflicting public contract.

Choose One of Three Topologies

1. API gateway before Istio ingress

flowchart LR
    C[External client] --> G[API gateway]
    G -->|Authenticated origin connection| I[Istio ingress gateway]
    I --> M[Mesh workload]
    M --> S[Downstream mesh service]

Use this topology when the edge needs API consumer management, complex transformations, developer-facing credentials, or governance that is intentionally outside the mesh. Restrict the Istio ingress endpoint so traffic can arrive only from the API gateway path. The gateway-to-ingress connection needs its own server authentication and, when required, client authentication; a forwarded identity header alone does not prove which proxy sent it.

The extra hop has a cost. Measure connection reuse, TLS handshakes, body buffering, streaming, and failure behavior. Do not keep both layers merely because both products are installed.

2. Istio ingress as the only public gateway

Istio supports exposing services through an ingress gateway and can use its own networking API or the Kubernetes Gateway API. This can be the smallest design when the required public routing and security policies fit the selected Istio version and operating model.

Before removing a separate API gateway, inventory hard requirements: consumer lifecycle, key issuance, shared quotas, request or response transformation, schema governance, analytics, monetization, and non-Kubernetes backends. Do not assume an ingress listener supplies a complete API-management lifecycle.

3. Public gateway plus dedicated multicluster east-west gateways

An east-west gateway has a different job from a public API gateway. Istio's documented multi-network pattern uses dedicated gateways when workloads in separate cluster networks cannot connect directly. Those gateways transport authenticated mesh traffic between networks and rely on trusted mTLS workload identities; they are not automatically public API entry points.

The Istio 1.31 multi-primary, multi-network guide also warns that its east-west gateway may be publicly reachable by default and needs production access restrictions. Keep public DNS, firewall policy, listener ports, and certificate trust separate for north-south and east-west gateways.

Define the Identity Handoff

Draw each identity as a different value:

1. the network peer that connected to the public edge;
2. the client address resolved through trusted proxy rules;
3. the API consumer or end-user identity validated from a credential;
4. the gateway workload identity used on the mesh connection; and
5. the application principal used for object authorization.

Do not collapse them into one X-User or X-Forwarded-For header. At the first trusted boundary, remove caller-supplied copies of security-sensitive identity headers. The owning gateway can then create a bounded context for the next hop. The receiver must accept that context only on an authenticated connection from an authorized gateway workload.

If the application needs the original bearer token, decide whether to forward it, exchange it, or forward selected verified claims. Forwarding every claim increases coupling and disclosure. A gateway-generated request ID is useful for correlation, but it is not a user identity.

Pair Authentication with Authorization

The Istio 1.31 RequestAuthentication API makes an important distinction: invalid credentials covered by the rule are rejected, but a request with no credential is accepted without an authenticated identity. To require a valid principal, pair authentication with authorization.

This Istio 1.31.1 excerpt illustrates the relationship; replace the selector, issuer, audience, and JWKS URI with values from the deployment's identity contract:

apiVersion: security.istio.io/v1
kind: RequestAuthentication
metadata:
  name: public-api-jwt
  namespace: istio-system
spec:
  selector:
    matchLabels:
      istio: ingressgateway
  jwtRules:
    - issuer: "https://identity.example.com/"
      audiences: ["api://orders"]
      jwksUri: "https://identity.example.com/.well-known/jwks.json"
---
apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  name: require-public-api-principal
  namespace: istio-system
spec:
  selector:
    matchLabels:
      istio: ingressgateway
  rules:
    - from:
        - source:
            requestPrincipals: ["*"]

This is a configuration excerpt, not a complete deployment. Confirm the ingress workload labels, policy attachment model, issuer behavior, JWKS availability, exempt health or token-issuance paths, and the exact Istio version. Match audiences to the IdP and API contract; when the list is empty, Istio's documented fallback is to accept an audience matching the service name. A separate edge gateway may already validate the token; if Istio validates again, document why, how key rotation is synchronized, and which result the application trusts.

Treat Mesh mTLS as Workload Authentication

Istio 1.31 security best practices state that proxies use permissive mutual TLS during incremental adoption by default, accepting both mutual TLS and plaintext when possible. Moving to strict mode rejects plaintext mesh connections. These two paths have different trust properties and must be tested before a migration is called complete.

Even strict mutual TLS proves a workload identity, not that the end user may read a particular invoice or modify a particular account. Apply mesh authorization policy for workload-level access and keep object-level checks in the application. Use Kubernetes NetworkPolicy and cloud firewall controls as defense in depth because traffic capture and gateway exposure are separate boundaries.

Assign Traffic Policy Once

Retries are the clearest source of accidental multiplication. If the API gateway attempts a request twice and Istio attempts each upstream call twice, one client operation can create four application attempts. Writes may be replayed after partial completion.

For every route, record:

• the end-to-end client deadline;
• connection, request, and per-try timeouts at each hop;
• which methods or operations are retryable;
• the maximum total attempts across the path;
• the idempotency key and deduplication owner for replayable writes;
• which layer performs canary weighting, fault injection, or outlier handling.

Keep public API version routing at the layer that owns the external contract. Keep service-instance selection and workload-local resilience in the mesh unless a deliberate exception has stronger context. Then inject a slow upstream, a reset after headers, and a control-plane outage to observe actual behavior.

Coordinate Kubernetes Configuration Ownership

Kubernetes Gateway API improves role separation through resources such as GatewayClass, Gateway, and HTTPRoute, but it does not prevent two teams from expressing conflicting intent. Assign each GatewayClass to one controller, restrict who may create public listeners, and use namespace attachment rules deliberately.

Choose a source of truth for hostnames, certificates, routes, and policy attachments. A GitOps repository should show whether a public route is reconciled by the API gateway controller or Istio. Status conditions must be part of promotion: an accepted manifest that no controller programs is not a successful deployment.

Observe and Verify the Complete Path

Use one correlation value across layers, but retain each layer's own authoritative fields. Logs should distinguish edge rejection, Istio authentication failure, mesh authorization denial, upstream reset, application denial, and client cancellation.

Before cutover, verify:

• direct traffic cannot reach Istio ingress or a service around the public gateway;
• forged forwarding and identity headers are replaced at the trust boundary;
• missing, invalid, expired, and valid credentials follow the intended paths;
• permissive and strict mesh mTLS behavior is understood during migration;
• timeout and retry totals remain within the client deadline;
• streaming, WebSocket, gRPC, and large-body routes work without unintended buffering;
• route deletion, certificate rotation, and policy rollback are observable;
• north-south and east-west gateways expose only their intended listeners.

Migration Sequence

1. Inventory current hostnames, routes, identities, retries, timeouts, and observability fields.
2. Assign one owner to every policy and remove duplicate defaults from the target design.
3. Deploy the new path without public traffic and test origin authentication and bypass resistance.
4. Mirror or replay sanitized traffic to verify routing and telemetry without creating writes.
5. Shift a small cohort with an immediate DNS or load-balancer rollback.
6. Compare denial reasons, latency, errors, and upstream attempt counts.
7. Remove the old public path only after rollback and emergency access are documented.

Summary

Combining an API gateway with Istio is an ownership exercise, not a requirement to stack two proxies. Use the API gateway for the public API contract when its capabilities are needed, use Istio for mesh identity and service traffic, and leave domain authorization with the application. Authenticate every handoff, prevent alternate paths, and test the combined retries, deadlines, identities, and failures as one system.

FAQ

Does every Istio deployment need a separate API gateway?

No. Istio ingress may be sufficient for a deployment whose public requirements fit its supported routing and security model. Add a separate API gateway only for explicit capabilities and operating ownership.

Is an Istio east-west gateway an API gateway?

It is a gateway for mesh traffic between networks. It does not automatically own public API products, consumer credentials, quotas, or lifecycle governance.

Does Istio mTLS authenticate the end user?

No. It authenticates participating workloads. End-user authentication and application authorization remain separate decisions.

Next Steps

Compare the broader API gateway and service mesh roles, design gateway mTLS identity and rotation, and define fine-grained authorization ownership.