sigs.k8s.io/cluster-api-provider-azure@v1.14.3/docs/book/src/topics/multitenancy.md (about)

     1  # Multi-tenancy
     2  
     3  To enable single controller multi-tenancy, a different Identity can be added to the Azure Cluster that will be used as the Azure Identity when creating Azure resources related to that cluster.
     4  
     5  This is achieved using [workload identity](workload-identity.md).
     6  
     7  ## Supported Identity Types
     8  
     9  Please read the [identities](identities.md) page for more information on the supported identity types.
    10  
    11  ### allowedNamespaces
    12  
    13  AllowedNamespaces is used to identify the namespaces the clusters are allowed to use the identity from. Namespaces can be selected either using an array of namespaces or with label selector.
    14  An empty allowedNamespaces object indicates that AzureClusters can use this identity from any namespace.
    15  If this object is nil, no namespaces will be allowed (default behavior, if this field is not provided)
    16  A namespace should be either in the NamespaceList or match with Selector to use the identity.
    17  Please note NamespaceList will take precedence over Selector if both are set.
    18  
    19  ## Deprecated Identity Types
    20  
    21  <aside class="note warning">
    22  <h1> Warning </h1>
    23  The ability to set credentials using environment variables has been removed. Instead, use <code class="hjls">AzureClusterIdentity</code> as described in the <a href="identities.html">identities</a> documentation.
    24  </aside>
    25  
    26  <aside class="note warning">
    27  <h1> Warning </h1>
    28  The identity type <code class="hjls">ManualServicePrincipal</code> has been deprecated because it is now identical to <code class="hjls">ServicePrincipal</code> and therefore redundant. None of the identity types use AAD Pod Identity any longer.
    29  </aside>
    30  
    31  ## Manual Service Principal (deprecated)
    32  
    33  Manual Service Principal Identity uses the service principal's `clientSecret` directly fetched from the secret containing it.  To use this type of identity, set the identity type as `ManualServicePrincipal` in `AzureClusterIdentity`. For example,
    34  
    35  ```yaml
    36  apiVersion: infrastructure.cluster.x-k8s.io/v1beta1
    37  kind: AzureClusterIdentity
    38  metadata:
    39    name: example-identity
    40    namespace: default
    41  spec:
    42    type: ManualServicePrincipal
    43    tenantID: <azure-tenant-id>
    44    clientID: <client-id-of-SP-identity>
    45    clientSecret: {"name":"<secret-name-for-client-password>","namespace":"default"}
    46    allowedNamespaces:
    47      list:
    48      - <cluster-namespace>
    49  ```
    50  
    51  Deploy this resource to your cluster:
    52  ```bash
    53  kubectl apply -f azure-cluster-identity.yaml
    54  ```
    55  
    56  A Kubernetes Secret should also be created to store the client password:
    57  
    58  ```bash
    59  kubectl create secret generic "${AZURE_CLUSTER_IDENTITY_SECRET_NAME}" --from-literal=clientSecret="${AZURE_CLIENT_SECRET}"
    60  ```
    61  
    62  The resulting Secret should look similar to the following example:
    63  
    64  ```yaml
    65  apiVersion: v1
    66  kind: Secret
    67  metadata:
    68    name: <secret-name-for-client-password>
    69  type: Opaque
    70  data:
    71    clientSecret: <client-secret-of-SP-identity>
    72  ```