Skip to content

For the complete documentation index, see llms.txt. Markdown versions of all docs pages are available by appending .md to any docs URL.

Policy attachment for global services

Alpha
Page as Markdown

Attach policies and routes to global services using service inheritance or a GlobalService parentRef.

Warning

This feature is considered alpha in the Solo distribution of Istio 1.31. Alpha features are likely to change, are not fully tested, and are not supported for production. For more information, see Solo feature maturity.

About

Policy resources that target a Kubernetes Service also apply to the corresponding global service. For example, an AuthorizationPolicy that controls access to the myapp Kubernetes Service applies both when traffic routes through the myapp.mynamespace.svc.cluster.local hostname and when it routes through the myapp.mynamespace.mesh.internal global hostname. This behavior is called policy inheritance.

Policy inheritance is enabled by default in version 1.31 of the Solo distribution of Istio. In version 1.30, inheritance was disabled by default and you enabled it per resource or for the entire mesh. If you need the previous behavior, you can turn off policy inheritance.

Note that policy inheritance is independent of how you route to the global service. For information about configuring routes to target global services, see Route to global services.

Before you begin

Make sure that your apps are exposed as global services across clusters.

Policy inheritance

Policy inheritance extends the following non-routing policy types from a Kubernetes Service to its corresponding global service:

  • AuthorizationPolicy
  • Telemetry
  • EnvoyFilter
  • TrafficExtension
  • WasmPlugin
  • RequestAuthentication

Routing resources such as VirtualService, HTTPRoute, GRPCRoute, TCPRoute, TLSRoute, and DestinationRule are not eligible for inheritance. Use a GlobalService parentRef to attach a route directly to a global service instead.

Inheritance applies to every eligible resource. You do not need to annotate the resource or configure istiod to extend a policy to the global service.

Warning

Review your existing policies before you upgrade from version 1.30. Because policies that target a Kubernetes Service now also apply to traffic that reaches the service through its global hostname, traffic that was previously allowed can be rejected after the upgrade. An AuthorizationPolicy with the ALLOW action rejects any request that does not match one of its rules, so callers in other clusters that are not listed in the from field are denied. A RequestAuthentication policy rejects requests that do not present a token from a listed issuer. Check the from and jwtRules fields of the policies that target a Kubernetes Service and confirm that they account for callers in other clusters.

Example: AuthorizationPolicy with service inheritance

The following AuthorizationPolicy restricts access to a Kubernetes Service. Because inheritance is enabled by default, the same restriction extends to the global service.

apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  name: myapp
  namespace: mynamespace
spec:
  targetRef:
    group: ""
    kind: Service
    name: myapp
  rules:
  - from:
    - source:
        principals:
        - cluster.local/ns/client-ns/sa/client-sa

This AuthorizationPolicy applies to both the local myapp.mynamespace.svc.cluster.local service and the hostname of the corresponding peered ServiceEntry, such as myapp.mynamespace.mesh.internal (or myapp.mynamespace.<segment-domain> if you use a custom segment domain).

Turn off policy inheritance

To restrict a policy to only the Kubernetes Service that it targets, you can turn off inheritance for a single resource or for the entire mesh:

  • Per-resource: Add the solo.io/service-inheritance: "false" annotation to a policy resource. The annotation takes precedence over the mesh-wide setting.
  • Mesh-wide: Set the ENABLE_SERVICE_INHERITANCE=false environment variable on the istiod deployment to turn off inheritance for all eligible resources. To opt individual resources back in, annotate them with solo.io/service-inheritance: "true".