<p>how to edit below yaml file to get all secrets, keys, certificates in my Azure KeyVault instead of using array and type/write all of it here?</p>
<p>i'm be able to get only below listed secret and key, but i'd like to share all stored data in my AKV</p>
<pre><code>apiVersion: secrets-store.csi.x-k8s.io/v1alpha1
kind: SecretProviderClass
metadata:
  name: azure-kvname-podid
spec:
  provider: azure
  parameters:
    usePodIdentity: &quot;true&quot;
    keyvaultName: &quot;kvname&quot;
    cloudName: &quot;&quot;          # [OPTIONAL for Azure] if not provided, azure environment will default to AzurePublicCloud
    objects:  |
      array:
        - |
          objectName: secret1
          objectType: secret        # object types: secret, key or cert
          objectVersion: &quot;&quot;         # [OPTIONAL] object versions, default to latest if empty
        - |
          objectName: key1
          objectType: key
          objectVersion: &quot;&quot;
    tenantId: &quot;tid&quot;                    # the tenant ID of the KeyVault  
</code></pre>
<p><a href="https://github.com/Azure/secrets-store-csi-driver-provider-azure/blob/master/examples/v1alpha1_secretproviderclass_pod_identity.yaml" rel="nofollow noreferrer">reference1</a>
<a href="https://learn.microsoft.com/en-us/azure/key-vault/general/key-vault-integrate-kubernetes" rel="nofollow noreferrer">reference2</a></p>

Mahmoud
<p>I've used Azure CSI a bit, and there are pretty much 2 ways I know of.</p>
<p>Very quick disclaimer as it seems to be what you're asking for, there is no 'one-liner' to get all your secrets from Azure KeyVault.  Meaning if you expect 'select * from AKV&quot; without specifying specific IDs of those secrets/keys/cert, then this 'secrets store CSI' will not be what you expect.  You more or less have to have a fair-sized YAML file to make it work for ALL your Azure KeyVault secrets.<br />
That said, you can deploy a very large YAML file with 200 secrets using a single command if you want, which will be mentioned below.</p>
<p>So with that out of the way, I'll go over pros/cons of the 2 methods I use, and give a sample of how they work.</p>
<h2><strong>Method 1</strong></h2>
<p><strong>Pros:</strong>  Shorter YAML file, all AKV secrets are in one variable.</p>
<p><strong>Cons:</strong>  All your AKV secrets are in one variable; which depending on your application might not work.  For example, this equates to one single volume mount and the Pod would have access to ALL types of secrets you tell it to connect to.</p>
<p><strong>How to implement:</strong>
Actually, the sample YAML you have is pretty much how to have multiple secrets.  Just keep adding to the 'array' field with all the secrets you want Azure CSI to inject for you, and below is a modified example:</p>
<pre><code>apiVersion: secrets-store.csi.x-k8s.io/v1alpha1
kind: SecretProviderClass
metadata:
  name: azure-kvname-podid      # This ID, is what you use in your Volume Mapping to reference this.
spec:
  provider: azure
  parameters:
    usePodIdentity: &quot;true&quot;
    keyvaultName: &quot;kvname&quot;
    objects:  |
      array:
        - |
          objectName: secret1       
          objectType: secret       
        - |
          objectName: key1
          objectType: key
        - |
          objectName: your_db_password  # So this ID, matches the same ID in your Azure KeyVault (AKV)
          objectType: secret         # object types: secret, key or cert.  There no other types for AKV.
        - |
          objectName: your_blob_storage_password    # So this ID, matches the same ID in your Azure KeyVault (AKV)
          objectType: secret                # object types: secret, key or cert.  There no other types for AKV.
        - |
          objectName: even_more_secrets_in_your_AKV # So this ID, matches the same ID in your Azure KeyVault (AKV)
          objectType: secret                # object types: secret, key or cert.  There no other types for AKV.
    tenantId: &quot;tid&quot;                    # the tenant ID of the KeyVault  
</code></pre>
<h2>Method 2</h2>
<p><strong>Pros:</strong>  Your secrets are broken up into individual variables, allowing flexibility to your deployment to select which ones get attached to which Pod(s)</p>
<p><strong>Cons:</strong>  It's going to be a massively long YAML file, with a lot of duplicated fields.  That said; this essentially is deployed using a one-liner for all the secrets, using <code>&quot;kubectl apply -f &lt;FILE_NAME&gt;.yaml --namespace=&lt;NAMESPACE&gt;&quot;</code></p>
<p><strong>How to implement:</strong>
It's pretty much copying/pasting what you had, just split up into multiple sections.  So below is an example of 5 AKV secrets, into 5 individual variables that can be volume-mounted in your application:</p>
<pre><code>apiVersion: secrets-store.csi.x-k8s.io/v1alpha1
kind: SecretProviderClass
metadata:
  name: akv-secret1     # This ID, is what you use in your Volume Mapping to reference this.
spec:
  provider: azure
  parameters:
    usePodIdentity: &quot;true&quot;
    keyvaultName: &quot;kvname&quot;
    objects:  |
      array:
        - |
          objectName: secret1       
          objectType: secret       
    tenantId: &quot;tid&quot;                    # the tenant ID of the KeyVault  
---
apiVersion: secrets-store.csi.x-k8s.io/v1alpha1
kind: SecretProviderClass
metadata:
  name: akv-secret2     # This ID, is what you use in your Volume Mapping to reference this.
spec:
  provider: azure
  parameters:
    usePodIdentity: &quot;true&quot;
    keyvaultName: &quot;kvname&quot;
    objects:  |
      array:
        - |
          objectName: secret2       
          objectType: secret       
    tenantId: &quot;tid&quot;                    # the tenant ID of the KeyVault  
---
apiVersion: secrets-store.csi.x-k8s.io/v1alpha1
kind: SecretProviderClass
metadata:
  name: akv-secret3     # This ID, is what you use in your Volume Mapping to reference this.
spec:
  provider: azure
  parameters:
    usePodIdentity: &quot;true&quot;
    keyvaultName: &quot;kvname&quot;
    objects:  |
      array:
        - |
          objectName: secret3       
          objectType: secret       
    tenantId: &quot;tid&quot;                    # the tenant ID of the KeyVault 
---
apiVersion: secrets-store.csi.x-k8s.io/v1alpha1
kind: SecretProviderClass
metadata:
  name: akv-secret4     # This ID, is what you use in your Volume Mapping to reference this.
spec:
  provider: azure
  parameters:
    usePodIdentity: &quot;true&quot;
    keyvaultName: &quot;kvname&quot;
    objects:  |
      array:
        - |
          objectName: secret4       
          objectType: secret       
    tenantId: &quot;tid&quot;                    # the tenant ID of the KeyVault  
---
apiVersion: secrets-store.csi.x-k8s.io/v1alpha1
kind: SecretProviderClass
metadata:
  name: akv-secret5     # This ID, is what you use in your Volume Mapping to reference this.
spec:
  provider: azure
  parameters:
    usePodIdentity: &quot;true&quot;
    keyvaultName: &quot;kvname&quot;
    objects:  |
      array:
        - |
          objectName: secret5       
          objectType: secret       
    tenantId: &quot;tid&quot;                    # the tenant ID of the KeyVault   
</code></pre>
