Service Account Secret Creation

When a Citadel instance notices that a ServiceAccount is created in a namespace, it must decide whetherit should generate an istio.io/key-and-cert secret for that ServiceAccount.In order to make that decision, Citadel considers three inputs (note: there can be multiple Citadel instancesdeployed in a single cluster, and the following targeting rules are applied to each instance):

• ca.istio.io/env namespace label: string valued label containing the namespace of the desired Citadel instance

• ca.istio.io/override namespace label: boolean valued label which overrides all other configurations and forces all Citadel instances either to target or ignore a namespace

• enableNamespacesByDefault security configuration: default behavior if no labels are found on the ServiceAccount’s namespace

From these three values, the decision process mirrors that of the Sidecar Injection Webhook. The detailed behavior is that:

• If ca.istio.io/override exists and is true, generate key/cert secrets for workloads.

• Otherwise, if ca.istio.io/override exists and is false, don’t generate key/cert secrets for workloads.

• Otherwise, if a ca.istio.io/env: "ns-foo" label is defined in the service account’s namespace, the Citadel instance in namespace ns-foo will be used for generating key/cert secrets for workloads in the ServiceAccount’s namespace.

• Otherwise, set enableNamespacesByDefault to true during installation. If it is true, the default Citadel instance will be used for generating key/cert secrets for workloads in the ServiceAccount’s namespace.

• Otherwise, no secrets are created for the ServiceAccount’s namespace.

This logic is captured in the truth table below:

When a namespace transitions from disabled to enabled, Citadel will retroactively generate secrets for all ServiceAccounts in that namespace. When transitioning from enabled to disabled, however, Citadel will not delete the namespace’s generated secrets until the root certificate is renewed.