I've used Azure CSI a bit, and there are pretty much 2 ways I know of.

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" 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.
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.

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.

Method 1

Pros: Shorter YAML file, all AKV secrets are in one variable.

Cons: 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.

How to implement: 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:

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: "true"
    keyvaultName: "kvname"
    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: "tid"                    # the tenant ID of the KeyVault  

Method 2

Pros: Your secrets are broken up into individual variables, allowing flexibility to your deployment to select which ones get attached to which Pod(s)

Cons: 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 "kubectl apply -f <FILE_NAME>.yaml --namespace=<NAMESPACE>"

How to implement: 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:

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: "true"
    keyvaultName: "kvname"
    objects:  |
      array:
        - |
          objectName: secret1		
          objectType: secret       
    tenantId: "tid"                    # 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: "true"
    keyvaultName: "kvname"
    objects:  |
      array:
        - |
          objectName: secret2		
          objectType: secret       
    tenantId: "tid"                    # 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: "true"
    keyvaultName: "kvname"
    objects:  |
      array:
        - |
          objectName: secret3		
          objectType: secret       
    tenantId: "tid"                    # 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: "true"
    keyvaultName: "kvname"
    objects:  |
      array:
        - |
          objectName: secret4		
          objectType: secret       
    tenantId: "tid"                    # 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: "true"
    keyvaultName: "kvname"
    objects:  |
      array:
        - |
          objectName: secret5		
          objectType: secret       
    tenantId: "tid"                    # the tenant ID of the KeyVault