Limit ServiceEntry scope

Enterprise

Use serviceEntryVisibility in MeshConfig to restrict ServiceEntry visibility to the namespace that created it.

Use the serviceEntryVisibility field in MeshConfig block of the istiod Helm chart to control the visibility of ServiceEntry resources across namespaces. By default, a ServiceEntry is visible to all workloads in the mesh, regardless of which namespace created it. You can restrict ServiceEntry visibility to the namespace that created it, either mesh-wide or per-namespace.

The following visibility values are supported.

Value	Description
`PUBLIC`	Default. The ServiceEntry is visible to all workloads in the mesh, subject to its `exportTo` field.
`NAMESPACE`	The ServiceEntry is visible only to workloads in the same namespace. Workloads in other namespaces cannot resolve or reach it.

Configure a mesh-wide default visibility

To apply a visibility ceiling to all ServiceEntry resources in the mesh, set meshConfig.serviceEntryVisibility.defaultVisibility in the istiod Helm chart. The default value is PUBLIC, which preserves existing behavior.

Update your istiod Helm values file with the following settings to limit visibility of ServiceEntry resources to workloads in the same namespace.
```
meshConfig:
  serviceEntryVisibility:
    defaultVisibility: NAMESPACE
```

Apply the change to istiod.

helm upgrade istiod oci://us-docker.pkg.dev/soloio-img/istio-helm/istiod \
  --version 1.31.0-solo \
  --namespace istio-system \
  --reuse-values \
  -f values.yaml

After this change, each ServiceEntry is visible only to workloads in the same namespace. Workloads in other namespaces cannot resolve it or route to it.

Configure per-namespace visibility policies

Instead of applying one setting to the whole mesh, you can use the policies list to apply different visibility settings to specific namespaces. Policies are evaluated in order. The first matching policy wins. If no policy matches a namespace, defaultVisibility applies.

Update your istiod Helm values file with the following settings. This example sets namespace-only visibility for all ServiceEntry resources by default, but grants cluster-wide visibility to ServiceEntry resources in namespaces labeled team: platform.

meshConfig:
  serviceEntryVisibility:
    defaultVisibility: NAMESPACE
    policies:
    - visibility: PUBLIC
      matchingRules:
      - namespaceSelector:
          matchLabels:
            team: platform

Apply the change to istiod.

helm upgrade istiod oci://us-docker.pkg.dev/soloio-img/istio-helm/istiod \
  --version 1.31.0-solo \
  --namespace istio-system \
  --reuse-values \
  -f values.yaml

Verify the configuration

After applying the configuration, check the status conditions on your ServiceEntry resources. Istiod writes a VisibilityApplied condition when a ServiceEntry’s visibility is restricted to NAMESPACE.

kubectl get serviceentry <name> -n <namespace> -o yaml

Example output when NAMESPACE visibility is applied:

status:
  conditions:
  - type: istio.io/VisibilityApplied
    status: "True"
    reason: Namespace
    message: ...

Use with waypoints

When you label a ServiceEntry that is scoped to NAMESPACE-only visibility to use a waypoint in a different namespace, istiod refuses the binding and reports the reason in the WaypointBound condition.

status:
  conditions:
  - type: istio.io/WaypointBound
    status: "False"
    reason: CrossNamespaceWaypointForbidden
    message: ...

When the target waypoint is a solo-ztunnel-egress gateway in a different namespace, istiod permits the cross-namespace binding even when the ServiceEntry has NAMESPACE visibility. The ztunnel egress data plane resolves each connection’s destination by the client’s HBONE source identity, so the ServiceEntry remains invisible to workloads outside its own namespace regardless of which namespace the gateway is in.

This exemption applies only when the solo-ztunnel-egress gateway’s allowedRoutes admit the ServiceEntry’s namespace. If the gateway’s listener is restricted to its own namespace, istiod denies the attachment before visibility is evaluated and reports AttachmentDenied in the WaypointBound condition.

For an example, see L4 ztunnel-native egress.

Rate limiting Canary deployments with Argo Rollouts