Ambient segments: one mesh, hard internal boundaries

The problem in one line

You want one mesh to operate (one control plane, one trust domain, one telemetry pipeline, one upgrade path) but several isolated worlds inside it, where the same namespace and service names can be reused safely and nothing crosses unless you say so. Namespace sameness alone gives you the single mesh but not the isolation. Segments add the isolation.

A real boundary: the cardholder data environment

PCI DSS requires you to segment the cardholder data environment (the CDE, everything that stores, processes or transmits card data) from the rest of the estate, so that out-of-scope systems cannot reach in. That is a boundary an auditor will ask you to prove. Here is that boundary as two segments in one mesh.

What a segment actually is

A segment groups clusters, not workloads inside a cluster. It is two pieces that people often conflate:

• The Segment resource defines a segment: its name, its DNS domain suffix, and any hostname patterns. You create the same set of Segment resources on every peered cluster, so all clusters share one map of which segments exist.
• A label on istio-system assigns a cluster to one of those segments. A cluster belongs to exactly one segment at a time.

So the number of Segment resources is the number of segments in the mesh (two, here), applied everywhere; the label is each cluster's membership card that picks one entry from the map. A corporate cluster still carries the CDE segment's definition, that is how it knows the CDE exists and what its domain is, it just is not a member of it.

# Both Segment resources exist on EVERY peered cluster (istio-system)
apiVersion: admin.solo.io/v1alpha1
kind: Segment
metadata:
  name: corp
  namespace: istio-system
spec:
  domain: corp.bank
---
apiVersion: admin.solo.io/v1alpha1
kind: Segment
metadata:
  name: cde
  namespace: istio-system
spec:
  domain: cde.bank

# Then each cluster joins ONE segment by labelling its istio-system namespace:
#   kubectl --context corp-cluster label ns istio-system admin.solo.io/segment=corp
#   kubectl --context cde-cluster  label ns istio-system admin.solo.io/segment=cde

Name your own domains

The domain suffix is yours. Whatever you put in spec.domain becomes the suffix for every service published in that segment, so a service resolves at <service>.<namespace>.<domain>, for example card-vault.payments.cde.bank. From 1.29 you can also add alias patterns (RFC 6570 URI templates) for shorter or label-driven names:

apiVersion: admin.solo.io/v1alpha1
kind: Segment
metadata:
  name: cde
  namespace: istio-system
spec:
  domain: cde.bank
  aliases:
    - pattern: "{service}.cde.bank"                      # card-vault.cde.bank
    - pattern: "{service}.{labels['tier']}.cde.bank"     # card-vault.data.cde.bank

Deciding what crosses: visibility is not access

There are two separate controls, and mixing them up is the usual mistake.

So the CDE boundary is built from both. card-vault is scope=segment, so it is never published outside the CDE, the corporate side has no route to it at all. The one service that must cross, payment-api, is scope=global, and then an AuthorizationPolicy pins down exactly who may call it:

# card-vault stays inside the CDE: never leaves the segment
kubectl label svc card-vault -n payments solo.io/service-scope=segment

# payment-api is the one sanctioned crossing point: visible mesh-wide
kubectl label svc payment-api -n payments solo.io/service-scope=global

...but visible is not open. Only checkout, from the corp cluster, may call it:

apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  name: payment-api-allow-checkout
  namespace: payments
spec:
  targetRefs:
    - kind: Service
      group: ""
      name: payment-api
  action: ALLOW
  rules:
    - from:
        - source:
            principals:
              - "corp.bank/ns/shop/sa/checkout"   # exactly this identity
      to:
        - operation:
            methods: ["POST"]
            paths: ["/charge", "/tokenize"]

Targeting a specific cluster

Because each cluster can carry its own trust domain in the Solo distribution, the SPIFFE principal on a request encodes which cluster the caller is in, not just its service account. That is what lets you target access per cluster: an allow rule for corp.bank/ns/shop/sa/checkout grants the checkout workload in the corporate cluster and nothing else, a workload with the same service account in another cluster presents a different principal and is denied. Put the policy on the waypoint if you need L7 conditions (method, path, JWT claim); leave it at ztunnel for pure L4 identity allow or deny.

When segments are the wrong tool

Segments earn their place when you want isolation and a few shared services and one team operating the whole thing. If two estates share nothing, are run by different teams with different SLAs, and never need a service to cross, then separate meshes are simpler and you are not giving anything up. Reach for segments when the alternative, standing up and federating several independent meshes just to share a handful of services, costs more than drawing a line through one.