Service Entries

We assume familiarity with the Istio service mesh basics: workloads communicate through Envoy sidecars (e.g., Service 1 → Service 3 → Service 2). Controlling how Envoy handles outbound traffic is done via the mesh-wide outbound traffic policy mode, which you configure when installing Istio (for example, using the IstioOperator). Outbound traffic policy modes

ALLOW_ANY (default): Envoy will pass through requests to external services that are not in Istio’s internal service registry.
REGISTRY_ONLY: Envoy will only allow outbound traffic to services registered in Istio’s internal service registry (typically via a ServiceEntry). Any attempt to reach unknown external services will be dropped.

By default Istio runs in permissive mode (ALLOW_ANY), so workloads can reach external services without a ServiceEntry. However, Istio will not apply traffic management, observability, or security features to those external flows unless the external services are added to the registry.

Why ServiceEntry? A ServiceEntry adds an external service (for example, an external PostgreSQL database) to Istio’s internal service registry. This enables Envoy to route to that service and allows Istio to enforce traffic policies, telemetry collection, and mTLS for egress traffic.

The image is a diagram illustrating how a service entry in Istio adds external PostgreSQL services to Istio's registry for routing and access, involving nodes, namespaces, and Envoy proxies.

Comparing ALLOW_ANY vs REGISTRY_ONLY

Mode	Behavior	When to use
`ALLOW_ANY`	Envoy allows outbound traffic to unknown external hosts (no `ServiceEntry` required). Istio does not apply advanced controls to those flows.	Useful for default permissive setups or during initial development.
`REGISTRY_ONLY`	Envoy only permits outbound traffic to services present in Istio’s registry (e.g., via `ServiceEntry`). Unknown external traffic is dropped.	Use when you require strict control over egress traffic, observability, or egress security (mTLS, authorization).

Enforcing REGISTRY_ONLY with the Istio operator To force Envoy to only allow registry-listed services, set meshConfig.outboundTrafficPolicy.mode to REGISTRY_ONLY in your IstioOperator manifest:

apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
spec:
  components:
    base:
      enabled: true
    cni:
      enabled: false
    egressGateways:
      - enabled: false
        name: istio-egressgateway
    ingressGateways:
      - enabled: true
        name: istio-ingressgateway
    istiodRemote:
      enabled: false
    pilot:
      enabled: true
  hub: docker.io/istio
  meshConfig:
    outboundTrafficPolicy:
      mode: REGISTRY_ONLY
  defaultConfig:
    proxyMetadata: {}

With REGISTRY_ONLY, any external destination not represented in Istio’s registry will be blocked. In ALLOW_ANY mode, external destinations are reachable but not managed by Istio. ServiceEntry example — external PostgreSQL Below is a minimal ServiceEntry that registers an external PostgreSQL server. Note: resolution is at the same level as ports inside spec, and this resource is namespaced.

apiVersion: networking.istio.io/v1beta1
kind: ServiceEntry
metadata:
  name: postgres-db
  namespace: frontend
spec:
  hosts:
    - db.example.com
  ports:
    - number: 5432
      name: tcp-db
      protocol: TCP
  resolution: DNS

Scoping and visibility

ServiceEntry is a namespaced resource. By default, a ServiceEntry created in namespace frontend is visible only to sidecars and workloads in frontend.
To make a ServiceEntry available to other namespaces, use the exportTo field (or create the resource in a namespace that is visible to others).

If your mesh is configured with REGISTRY_ONLY, you must ensure any external dependency is registered in the namespace(s) that require access (or exported). Failing to do so will result in blocked egress traffic.

Common reasons to declare external services with ServiceEntry

Centralized management of external dependencies for routing and troubleshooting.
Apply Istio traffic management features to egress (retries, timeouts, circuit breaking).
Enforce security policies (mTLS, authorization) for outbound traffic.
Enable observability/telemetry for external calls through Envoy.

Resolution methods overview The resolution field controls how Envoy discovers endpoints for the declared host. The slide below summarizes common resolution options:

The image is a slide titled "Service Entry Options" featuring definitions and explanations for terms like "ServiceEntry", "Location", and "Resolution", with a focus on how network endpoints are resolved in a proxy. The slide includes detailed tables describing resolution methods such as NONE, STATIC, DNS, and DNS_ROUND_ROBIN.

Resolution quick-reference

Resolution	Description
`NONE`	No endpoints are provided by the `ServiceEntry`; it’s used for DNS-only scenarios where sidecars rely on DNS to resolve the host.
`DNS`	Envoy uses DNS lookup to discover endpoints for the host (typical for external services).
`DNS_ROUND_ROBIN`	Envoy resolves the host via DNS and load-balances across returned addresses (round-robin behavior).
`STATIC`	Endpoints are supplied directly in the `ServiceEntry` using the `addresses`/`endpoints` fields.

References and further reading

Summary

ALLOW_ANY vs REGISTRY_ONLY determines whether Envoy allows unknown external egress.
Use ServiceEntry to register external dependencies when you need Istio-managed egress (routing, security, telemetry).
ServiceEntry resources are namespaced — use exportTo when cross-namespace visibility is required.
Practice creating ServiceEntry objects and toggling outboundTrafficPolicy to observe differences in connectivity and telemetry.

Introduction

Installation & Configuration

Traffic Management

Securing Workloads

Troubleshooting

Conclusion

Watch Video