Configure Citadel Service Account Secret Generation

A cluster operator might decide not to generate ServiceAccount secrets for some subset of namespaces, or to make ServiceAccount secret generation opt-in per namespace. This task describes how an operator can configure their cluster for these situations. Full documentation of the Citadel namespace targeting mechanism can be found here.

Before you begin

To complete this task, you should first take the following actions:

Deactivating Service Account secret generation for a single namespace

To create a new sample namespace foo, run:

  1. $ kubectl create ns foo

Service account secrets are created following the default behavior. To verify that Citadel has generated a key/cert secret for the default service account in the foo namespace, run (note that this may take up to 1 minute):

  1. $ kubectl get secrets -n foo | grep istio.io
  2. NAME                    TYPE                           DATA      AGE
  3. istio.default           istio.io/key-and-cert          3         13s

To label the namespace to prevent Citadel from creating ServiceAccount secrets in target namespace foo, run:

  1. $ kubectl label ns foo ca.istio.io/override=false

To create a new ServiceAccount in this namespace, run:

  1. $ kubectl apply -f - <<EOF
  2. apiVersion: v1
  3. kind: ServiceAccount
  4. metadata:
  5.   name: sample-service-account
  6.   namespace: foo
  7. EOF

To check the namespace’s secrets again, run:

  1. $ kubectl get secrets -n foo | grep istio.io
  2. NAME                    TYPE                           DATA      AGE
  3. istio.default           istio.io/key-and-cert          3         11m

You can observe that no new istio.io/key-and-cert secret was generated for the sample-service-account service account.

Opt-in Service Account secret generation

Set the enableNamespacesByDefault installation option to false to make ServiceAcount secret generation opt-in (i.e., to disable generating secrets unless otherwise specified):

  1. ...
  2. security:
  3.     enableNamespacesByDefault: false
  4. ...

Once this mesh configuration is applied, to create a namespace foo and check the secrets present in that namespace, run:

  1. $ kubectl create ns foo
  2. $ kubectl get secrets -n foo | grep istio.io

You can observe that no secrets have been created. To override this value for the foo namespace, add a ca.istio.io/override=true label in that namespace:

  1. $ kubectl label ns foo ca.istio.io/override=true

To create a new service account in the foo namespace, run:

  1. $ kubectl apply -f - <<EOF
  2. apiVersion: v1
  3. kind: ServiceAccount
  4. metadata:
  5.   name: sample-service-account
  6.   namespace: foo
  7. EOF

To check the secrets in the foo namespace again, run:

  1. $ kubectl get secrets -n foo | grep istio.io
  2. NAME                                 TYPE                                  DATA   AGE
  3. istio.default                        istio.io/key-and-cert                 3      47s
  4. istio.sample-service-account         istio.io/key-and-cert                 3      6s

You can observe that an istio.io/key-and-cert secret has been created for the default service account in addition to the sample-service-account. This is due to the retroactive secret generation feature, which will create secrets for all service accounts in a namespace once it transitions from inactive to active.

Cleanup

To delete the foo test namespace and all its resources, run:

  1. $ kubectl delete ns foo