> ## Documentation Index
> Fetch the complete documentation index at: https://notes.kodekloud.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Service Entries
> Explains Istio ServiceEntry and outboundTrafficPolicy, showing how to register external services under REGISTRY_ONLY so Envoy can manage egress traffic, security, and telemetry.
The Istio service mesh mediates traffic between workloads so services inside the mesh can call each other through their Envoy sidecars (for example, Service 1 → Service 3 → Service 2).
## Outbound traffic policy: REGISTRY\_ONLY vs ALLOW\_ANY
When you install Istio with the [IstioOperator](https://istio.io/latest/docs/setup/install/operator/) you can set a mesh-wide outbound traffic policy that controls how Envoy handles outbound requests to external services. The two modes are:
| Mode | Behavior |
| --------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| `REGISTRY_ONLY` | Envoy only allows outbound traffic to services present in Istio’s internal service registry (including ServiceEntry resources). Unknown external destinations are blocked. |
| `ALLOW_ANY` | Envoy passes through requests to unknown external services (default). Istio has limited visibility and cannot apply traffic management, security, or telemetry to those calls. |
By default Istio uses `ALLOW_ANY`, which simplifies reaching external services but prevents Istio from applying telemetry, routing, or security controls to those calls. Switching to `REGISTRY_ONLY` forces you to explicitly register external services so Istio can manage them.
If you set `meshConfig.outboundTrafficPolicy.mode` to `REGISTRY_ONLY` and you do not declare a ServiceEntry for an external host, Envoy will drop outbound traffic to that host.
## What is a ServiceEntry?
A ServiceEntry adds external (or otherwise non-discovered) hosts into Istio’s internal service registry. Once an external host is defined as a ServiceEntry, Envoy can treat it like any other mesh service so Istio can apply:
* Traffic management (retries, timeouts, routing)
* Security controls (mTLS where applicable, access policies)
* Telemetry and observability for egress traffic
Use cases:
* Enable controlled access to databases, APIs, or third-party services when `REGISTRY_ONLY` is enforced.
* Centralize egress configuration so policies and telemetry apply consistently across the mesh.
## Installing Istio with REGISTRY\_ONLY
To change the default behavior during installation, set `meshConfig.outboundTrafficPolicy.mode` to `REGISTRY_ONLY` in your IstioOperator spec. Example:
```yaml theme={null}
apiVersion: networking.istio.io/v1
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: {}
```
## Example: ServiceEntry for a PostgreSQL database
When your mesh uses `REGISTRY_ONLY`, declare each external service with a ServiceEntry. The following ServiceEntry allows workloads in the `frontend` namespace to reach `db.example.com:5432`:
```yaml theme={null}
apiVersion: networking.istio.io/v1
kind: ServiceEntry
metadata:
name: postgres-db
namespace: frontend
spec:
hosts:
- db.example.com
ports:
- number: 5432
name: db
protocol: TCP
resolution: DNS
```
Note: This ServiceEntry is namespace-scoped (`namespace: frontend`), so only workloads in the `frontend` namespace can use it. Workloads in other namespaces (for example, `default`) will still be blocked under `REGISTRY_ONLY` unless a ServiceEntry is created for their namespace or a cluster-wide approach is used.
## Key ServiceEntry fields
| Field | Purpose |
| ------------ | ------------------------------------------------------------------------- |
| `hosts` | Domain names or hostnames for the external service. |
| `ports` | Port numbers and protocols to expose for the host. |
| `resolution` | How endpoints are resolved: `DNS`, `STATIC`, or `NONE`. |
| `endpoints` | Static IPs used when `resolution: STATIC`. |
| `location` | `MESH_EXTERNAL` or `MESH_INTERNAL` to indicate where the service resides. |
## Why use ServiceEntry if ALLOW\_ANY is easier?
* Centralized management: Declare external services so policies and configurations are consistent.
* Traffic control: Apply retries, timeouts, and routing to egress calls.
* Security and compliance: Enforce access rules and mTLS for outbound traffic.
* Observability: Capture telemetry for external calls rather than losing visibility in pass-through mode.
## References and further reading
* [Istio Networking: Service Entry (reference)](https://istio.io/latest/docs/reference/config/networking/service-entry/)
* [Istio Installation with IstioOperator](https://istio.io/latest/docs/setup/install/operator/)
* [Envoy Proxy](https://www.envoyproxy.io/)
In this lesson you learned what a ServiceEntry is, why it’s required when `outboundTrafficPolicy` is set to `REGISTRY_ONLY`, and how to declare a basic ServiceEntry for an external PostgreSQL database. For the Istio Certified Associate (ICA) exam, be comfortable creating ServiceEntry resources (including specifying ports) and understanding how `outboundTrafficPolicy` affects egress behavior.