• Configure Citadel Service Account Secret Generation
    • Before you begin
      • Deactivating service account secret generation for a single namespace
      • Opt-in service account secret generation
    • Cleanup

    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:

    • Read the security concept.

    • Follow the Istio installation guide to install Istio with mutual TLS enabled.

    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