cluster.local cannot be used as a pointer to the local trust domain

[rinormaloku]

When using sidecars, with istio installations that have a custom trust domain, for example old-td .
Then both principals trust domains old-td and or cluster.local are valid to be used in the Authorization policy

apiVersion: security.istio.io/v1
kind: AuthorizationPolicy
metadata:
  name: service-httpbin.default.svc.cluster.local
  namespace: default
spec:
  rules:
  - from:
    - source:
        principals:
        - old-td/ns/sleep-allow/sa/sleep 
        # or 
        # - cluster.local/ns/sleep-allow/sa/sleep

However, that is not the case in ambient (ztunnel), you have to use only the custom trust domain i.e. old-td

The docs recommend using cluster.local as a best practice (that might be an outdated suggestion, fwiw). However, this means that all customers that were using cluster.local as a pointer to the local trust domain, would be impacted when migrating workloads from sidecars into ambient, which would catch them by surprise.

[bleggett]

Istio in general supports one trust domain per control-plane instance. We have a magic alias such that cluster.local is implicitly always treated as a valid trust domain, but it doesn't actually properly function as a secondary trust domain, or enable proper support of multiple trust domains.

Ambient supports one trust domain in the dataplane ATM. We could make it support the magic alias the control plane does, but there are a lot of (existing) problems that does not solve.

The trust domain alias in sidecars solves only one problem, really - to let you delay updating your Auth policies if you change your trust domain, which I do not think is very valuable or even something we should encourage - your Auth policies should explictly declare the principals you want, in all cases.

But you don't even need the magic alias to do that - Auth policies themselves can already do everything the magic alias allows for, by adding multiple principals to your Auth policies explicitly - which is better anyway, since AuthPolicies are supposed to be declarative, and having a secret switch to allow unlisted principals to pass the policy is Not Great.

If you want to have 2 trust domains but only actually use 1 of them, you don't actually need or want 2 trust domains - relying on the alias is bad practice IMO and we shouldn't encourage people to create or configure trust domains they do not intend to use.

Aliases are a semi-hack IMO. Istio doesn't really support multiple trust domains within a single control-plane instance, and the use of the alias for migrations is redundant with existing AuthPolicy capabilities - they really don't do anything useful, and break the declarative model of AuthPolicies.

I actually think we should just deprecate the use of trust domain aliases entirely in this doc and tell people to explicitly add the principals they want to their AuthPolicies if they wish to migrate between trust domains, which works just fine for this (likely extremely rare) activity and doesn't break the policy model or require weird controlplane logic.

Suggest the following:

• If you are using cluster.local, you should configure that globally in your Istio install (including ambient) and you will be fine.

• If you are using MY_TRUST_DOMAIN, you should configure that globally in your Istio install (including ambient) and you will be fine.

• If you are migrating from cluster.local to MY_TRUST_DOMAIN or vice-versa, you should configure your AuthPolicies to declaratively allow principals from either trust domain during the migration, and we update the migration doc to say this.

• If you are using cluster.local and MY_TRUST_DOMAIN simultaneously and permanently in a non-migration context, you're abusing the alias to do something you should not be doing, and we have never supported, documented, or recommended this (and should remove the aliasing so you cannot do it without explicitly configuring your AuthPolicies).

None of that requires any ambient changes, and would be better for sidecars too, so that's my pref here - added to the next WG tho for discussion.