docs(azurekv): cert-manager pushsecret example and cleanups (#5972)

Co-authored-by: Gergely Bräutigam <gergely.brautigam@sap.com>

docs/provider/azure-key-vault.md

@@ -1,50 +1,79 @@
 
 ![aws sm](../pictures/eso-az-kv-azure-kv.png)
 
-## Azure Key vault
+## Azure Key Vault
 
-External Secrets Operator integrates with [Azure Key vault](https://azure.microsoft.com/en-us/services/key-vault/) for secrets, certificates and Keys management.
+External Secrets Operator integrates with [Azure Key Vault](https://azure.microsoft.com/en-us/services/key-vault/) via `SecretStore` and `ClusterSecretStore` resources. The operator can fetch secrets, keys and certificates stored in Azure Key Vault and synchronize them as Kubernetes secrets using an `ExternalSecret`. Vice versa, it can also push secrets from Kubernetes into Azure Key Vault as secrets, keys and certificates by using a `PushSecret`.
 
-### Authentication
-
-We support authentication with Microsoft Entra identities that can be used as Workload Identity or [AAD Pod Identity](https://azure.github.io/aad-pod-identity/docs/) as well as with Service Principal credentials.
+ESO supports connecting to different cloud flavours azure supports: `PublicCloud`, `USGovernmentCloud`, `ChinaCloud`, `GermanCloud` and `AzureStackCloud` (for Azure Stack Hub/Edge). You have to specify the `environmentType` and point to the correct cloud flavour. This defaults to `PublicCloud`.
 
-Since the [AAD Pod Identity](https://azure.github.io/aad-pod-identity/docs/) is deprecated, it is recommended to use the [Workload Identity](https://azure.github.io/azure-workload-identity) authentication.
+For environments with non-standard endpoints (Azure Stack, Azure China with AKS Workload Identity, etc.), you can provide custom cloud configuration to override the default endpoints. See the [Custom Cloud Configuration](#custom-cloud-configuration) section below.
 
-We support connecting to different cloud flavours azure supports: `PublicCloud`, `USGovernmentCloud`, `ChinaCloud`, `GermanCloud` and `AzureStackCloud` (for Azure Stack Hub/Edge). You have to specify the `environmentType` and point to the correct cloud flavour. This defaults to `PublicCloud`.
+### Configure SecretStore
 
-For environments with non-standard endpoints (Azure Stack, Azure China with AKS Workload Identity, etc.), you can provide custom cloud configuration to override the default endpoints. See the [Custom Cloud Configuration](#custom-cloud-configuration) section below.
+The Azure Key Vault provider is fully compatible with both namespaced `SecretStore` and cluster-wide `ClusterSecretStore` resources. For simplicity, this article refers only to `SecretStore`, but the same is applicable also for `ClusterSecretStore`. To establish the integration with Azure Key Vault, specify `azurekv` as the provider and provide the vault URL and authentication details. The vault URL is the URL of your Key Vault instance, which typically looks like `https://<your-keyvault-name>.vault.azure.net`. For Azure Stack, it may have a different format, so make sure to use the correct URL for your environment. See below for different authentication methods.
 
 ```yaml
 apiVersion: external-secrets.io/v1
 kind: SecretStore
 metadata:
-  name: azure-backend
+  name: azure-store
 spec:
   provider:
     azurekv:
-      # PublicCloud, USGovernmentCloud, ChinaCloud, GermanCloud
-      environmentType: PublicCloud # default
+      # URL of your Key Vault instance, see: https://docs.microsoft.com/en-us/azure/key-vault/general/about-keys-secrets-certificates
+      vaultUrl: "https://xx-xxxx-xx.vault.azure.net"
 ```
 
-Minimum required permissions are `Get` over secret and certificate permissions. This can be done by adding a Key Vault access policy:
-
-```sh
-KUBELET_IDENTITY_OBJECT_ID=$(az aks show --resource-group <AKS_CLUSTER_RG_NAME> --name <AKS_CLUSTER_NAME> --query 'identityProfile.kubeletidentity.objectId' -o tsv)
-az keyvault set-policy --name kv-name-with-certs --object-id "$KUBELET_IDENTITY_OBJECT_ID" --certificate-permissions get --secret-permissions get
+```yaml
+apiVersion: external-secrets.io/v1
+kind: ClusterSecretStore
+metadata:
+  name: azure-store
+spec:
+  provider:
+    azurekv:
+      # URL of your Key Vault instance, see: https://docs.microsoft.com/en-us/azure/key-vault/general/about-keys-secrets-certificates
+      vaultUrl: "https://xx-xxxx-xx.vault.azure.net"
 ```
 
-#### Service Principal key authentication
+### Authentication
+
+ESO supports multiple authentication methods to connect to Azure Key Vault:
+
+- Service Principal
+- Managed Identity (AAD Pod Identity)
+- Workload Identity
+
+Regardless of which authentication method is used to authenticate to Azure Key Vault, the identity which is assigned to External Secrets Operator needs to have proper permissions to access the Key Vault. Both [RBAC](https://learn.microsoft.com/en-us/azure/key-vault/general/rbac-guide) and legacy [Access Policy](https://learn.microsoft.com/en-us/azure/key-vault/general/assign-access-policy) based Key Vaults are supported.
+
+The required permissions depend on the type of objects you want to manage (secrets, keys, certificates) and the operations you want to perform (read, write, delete, etc.). For example, to grant External Secrets Operator permissions to synchronize secrets and certificates using an `ExternalSecret`, the minimum required permissions are either the [Key Vault Secrets User](https://learn.microsoft.com/en-us/azure/role-based-access-control/built-in-roles/security#key-vault-secrets-user) and [Key Vault Certificates User](https://learn.microsoft.com/en-us/azure/role-based-access-control/built-in-roles/security#key-vault-certificates-user) RBAC roles, alternatively for Access Policy based Key Vaults, the `Get` permission over secrets and certificates.
+
+#### Service Principal
+
+To use a Service Principal's credentials for authentication, you need to create a Service Principal in Entra ID and grant it the necessary permissions to access the Key Vault. Then, you can create a Kubernetes Secret containing the Service Principal's credentials:
+
+- Client ID
+- **Either** Client Secret **or** Client Certificate (in PEM format)
+
+Reference this secret in your `SecretStore` configuration.
+
+```yaml
+{% include 'azkv-secret-store-spn-secret.yaml' %}
+```
 
-A service Principal client and Secret is created and the JSON keyfile is stored in a `Kind=Secret`. The `ClientID` and `ClientSecret` or `ClientCertificate` (in PEM format) should be configured for the secret. This service principal should have proper access rights to the keyvault to be managed by the operator.
+```yaml
+{% include 'azkv-secret-store-spn-certificate.yaml' %}
+```
 
-#### Managed Identity authentication
+#### Managed Identity (AAD Pod Identity)
 
-A Managed Identity should be created in Azure, and that Identity should have proper rights to the keyvault to be managed by the operator.
+!!! warning
+    This authentication option uses [AAD Pod Identity](https://azure.github.io/aad-pod-identity/docs/) which is deprecated, it is recommended to use the [Workload Identity](https://azure.github.io/azure-workload-identity) authentication instead.
 
-Use [aad-pod-identity](https://azure.github.io/aad-pod-identity/docs/) to assign the identity to external-secrets operator. To add the selector to external-secrets operator, use `podLabels` in your values.yaml in case of Helm installation of external-secrets.
+To use a Managed Identity with AAD Pod Identity for authentication, you need to create a Managed Identity in Azure and grant it the necessary permissions to access the Key Vault. Then, assign that Managed Identity to the External Secrets Operator using [AAD Pod Identity](https://azure.github.io/aad-pod-identity/docs/). Finally, you can reference that identity in your `SecretStore` configuration.
 
-If there are multiple Managed Identities for different keyvaults, the operator should have been assigned all identities via [aad-pod-identity](https://azure.github.io/aad-pod-identity/docs/), then the SecretStore configuration should include the Id of the identity to be used via the `identityId` field.
+If you have multiple identities assigned to External Secrets Operator, you can specify which of them to use by providing its client ID in the field `spec.provider.azurekv.identityId` on the `SecretStore`. If only one identity is assigned, you can omit the `identityId` field.
 
 ```yaml
 {% include 'azkv-secret-store-mi.yaml' %}
@@ -52,9 +81,9 @@ If there are multiple Managed Identities for different keyvaults, the operator s
 
 #### Workload Identity
 
-In Microsoft Entra, Workload Identity can be Application, user-assigned Managed Identity and Service Principal.
+Workload Identity is the recommended authentication method for Azure Key Vault. It allows the External Secrets Operator to authenticate to Azure Key Vault using the identity of a Kubernetes Service Account, without needing to manage secrets or credentials. This is achieved by creating a trust relationship between your Kubernetes cluster and the Entra ID identity you want to use. This process is known as [Workload Identity Federation](https://learn.microsoft.com/en-us/entra/workload-id/workload-identity-federation). The identity in Entra ID can be either an Application, a user-assigned Managed Identity or a Service Principal.
 
-You can use [Azure AD Workload Identity Federation](https://docs.microsoft.com/en-us/azure/active-directory/develop/workload-identity-federation) to access Azure managed services like Key Vault **without needing to manage secrets**. You need to configure a trust relationship between your Kubernetes Cluster and Azure AD. This can be done in various ways, for instance using `terraform`, the Azure Portal or the `az` cli. We found the [azwi](https://azure.github.io/azure-workload-identity/docs/installation/azwi.html) cli very helpful. The Azure [Workload Identity Quick Start Guide](https://azure.github.io/azure-workload-identity/docs/quick-start.html) is also good place to get started.
+The workload identity federation can be done in various ways, for instance using Terraform, the Azure Portal or Azure CLI. We found the [azwi](https://azure.github.io/azure-workload-identity/docs/installation/azwi.html) CLI very helpful. The Azure [Workload Identity Quick Start Guide](https://azure.github.io/azure-workload-identity/docs/quick-start.html) is a good place to get started.
 
 This is basically a two step process:
 
@@ -76,7 +105,7 @@ azwi serviceaccount create phase federated-identity \
   --service-account-issuer-url "${SERVICE_ACCOUNT_ISSUER}"
 ```
 
-With these prerequisites met you can configure `ESO` to use that Service Account. You have two options:
+With these prerequisites met you can configure External Secrets Operator to use that Service Account. You have two options:
 
 ##### Mounted Service Account
 You run the controller and mount that particular service account into the pod by adding the label `azure.workload.identity/use: "true"`to the pod. That grants _everyone_ who is able to create a secret store or reference a correctly configured one the ability to read secrets. **This approach is usually not recommended**. But may make sense when you want to share an identity with multiple namespaces. Also see our [Multi-Tenancy Guide](../guides/multi-tenancy.md) for design considerations.
@@ -168,47 +197,32 @@ spec:
           key: client-secret
 ```
 
-**Important Notes:**
-- `useAzureSDK: true` is mandatory when using `customCloudConfig`
-- `customCloudConfig` can be used with any `environmentType` (PublicCloud, ChinaCloud, etc.)
-- For AzureStackCloud, `customCloudConfig` is required
-- Contact your Azure Stack administrator for the correct endpoint URLs
-
-### Update secret store
-Be sure the `azurekv` provider is listed in the `Kind=SecretStore`
-
-```yaml
-{% include 'azkv-secret-store.yaml' %}
-```
-**NOTE:** In case of a `ClusterSecretStore`, Be sure to provide `namespace` in `clientId` and `clientSecret`  with the namespaces where the secrets reside.
-
-Or in case of Managed Identity authentication:
+!!! note
 
-```yaml
-{% include 'azkv-secret-store-mi.yaml' %}
-```
+    - `useAzureSDK: true` is mandatory when using `customCloudConfig`
+    - `customCloudConfig` can be used with any `environmentType` (PublicCloud, ChinaCloud, etc.)
+    - For AzureStackCloud, `customCloudConfig` is required
+    - Contact your Azure Stack administrator for the correct endpoint URLs
 
 ### Object Types
 
-Azure Key Vault manages different [object types](https://docs.microsoft.com/en-us/azure/key-vault/general/about-keys-secrets-certificates#object-types), we support `keys`, `secrets` and `certificates`. Simply prefix the key with `key`, `secret` or `cert` to retrieve the desired type (defaults to secret).
-
-| Object Type   | Return Value                                                                                                                                                                                                                      |
-| ------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
-| `secret`      | the raw secret value.                                                                                                                                                                                                             |
-| `key`         | A JWK which contains the public key. Azure Key Vault does **not** export the private key. You may want to use [template functions](../guides/templating.md) to transform this JWK into PEM encoded PKIX ASN.1 DER format. |
-| `certificate` | The raw CER contents of the x509 certificate. You may want to use [template functions](../guides/templating.md) to transform this into your desired encoding                                                             |
+Azure Key Vault has different [object types](https://docs.microsoft.com/en-us/azure/key-vault/general/about-keys-secrets-certificates#object-types); Secrets, Keys and Certificates, all of which are supported. To explicitly select which object type to fetch via an `ExternalSecret` or push via a `PushSecret`, prefix the `spec.data[].remoteRef.key` field with either `key`, `secret` or `cert`. If no prefix is provided, the operator defaults to `secret`.
 
-### Creating external secret
+| Object Type | Prefix | Description
+| ----------- | ------ | ------------------------- |
+| Secret      | `secret` (default) | Generic secrets, such as passwords and database connection strings. |
+| Key         | `key`    | Cryptographic keys represented as JSON Web Key [JWK] objects. Azure Key Vault does **not** export the private key. You may want to use [template functions](../guides/templating.md) to transform this JWK into PEM encoded PKIX ASN.1 DER format. |
+| Certificate | `cert`   | X509 certificates, for example TLS certificates. You may want to use [template functions](../guides/templating.md) to transform this into your desired encoding. |
 
-To create a Kubernetes secret from the Azure Key vault secret a `Kind=ExternalSecret` is needed.
+### Creating an ExternalSecret
 
-You can manage keys/secrets/certificates saved inside the keyvault , by setting a "/" prefixed type in the secret name, the default type is a `secret`. Other supported values are `cert` and `key`.
+To synchronize secrets from Azure Key Vault into Kubernetes, you need to create an `ExternalSecret` which references the `SecretStore` or `ClusterSecretStore` you configured. You specify the name of the secret in Azure Key Vault that you want to synchronize and the name of the Kubernetes secret that should be created.
 
 ```yaml
 {% include 'azkv-external-secret.yaml' %}
 ```
 
-The operator will fetch the Azure Key vault secret and inject it as a `Kind=Secret`. Then the Kubernetes secret can be fetched by issuing:
+The operator will fetch the Azure Key Vault secret and inject it as a `Secret`. View the created secret by running the following command:
 
 ```sh
 kubectl get secret secret-to-be-created -n <namespace> -o jsonpath='{.data.dev-secret-test}' | base64 -d
@@ -220,38 +234,56 @@ To select all secrets inside the key vault or all tags inside a secret, you can
 {% include 'azkv-datafrom-external-secret.yaml' %}
 ```
 
-To get a PKCS#12 certificate from Azure Key Vault and inject it as a `Kind=Secret` of type `kubernetes.io/tls`:
+To fetch a P12 certificate (also known as PKCS12 or PFX) from Azure Key Vault and inject it as a `Secret` of type `kubernetes.io/tls`, you can use the following configuration. Note that template functions are used to transform the certificate from its original format into a PEM encoded format that Kubernetes expects for TLS secrets.
 
 ```yaml
 {% include 'azkv-pkcs12-cert-external-secret.yaml' %}
 ```
 
 ### Creating a PushSecret
-You can push secrets to Azure Key Vault into the different `secret`, `key` and `certificate` APIs.
+You can push secrets from Kubernetes into Azure Key Vault as secrets, keys or certificates by using a `PushSecret`. A `PushSecret` references a Kubernetes Secret as the source of the data. The operator can create, update or delete the corresponding secret in Azure Key Vault to match the desired state defined in the `PushSecret`.
 
 #### Pushing to a Secret
-Pushing to a Secret requires no previous setup. with the secret available in Kubernetes, you can simply refer it to a PushSecret object to have it created on Azure Key Vault:
+Pushing to a Secret requires no previous setup. Provided you have a Kubernetes Secret available, you can create a `PushSecret` which references it to have it created on Azure Key Vault. You can optionally set metadata such as content type or tags. The operator will read the data from the Kubernetes Secret and push it to Azure Key Vault as a secret.
+
 ```yaml
 {% include 'azkv-pushsecret-secret.yaml' %}
 ```
+
 !!! note
-      In order to create a PushSecret targeting keys, `CreateSecret` and `DeleteSecret` actions must be granted to the Service Principal/Identity configured on the SecretStore.
+    In order to create a PushSecret targeting Secrets, the [Key Vault Secrets Officer](https://learn.microsoft.com/en-us/azure/role-based-access-control/built-in-roles/security#key-vault-secrets-officer) role, alternatively Access Policy permissions `Set` and `Delete` for Secrets must be granted to the identity configured on the SecretStore.
 
 #### Pushing to a Key
-The first step is to generate a valid Private Key. Supported Formats include `PRIVATE KEY`, `RSA PRIVATE KEY` AND `EC PRIVATE KEY` (EC/PKCS1/PKCS8 types). After uploading your key to a Kubernetes Secret, the next step is to create a PushSecret manifest with the following configuration:
+The first step is to generate a valid private key. Supported formats include `PRIVATE KEY`, `RSA PRIVATE KEY` AND `EC PRIVATE KEY` (EC/PKCS1/PKCS8 types). After uploading your key to a Kubernetes Secret, the next step is to create a PushSecret manifest with the following configuration:
 
 ```yaml
 {% include 'azkv-pushsecret-key.yaml' %}
 ```
 
 !!! note
-      In order to create a PushSecret targeting keys, `ImportKey` and `DeleteKey` actions must be granted to the Service Principal/Identity configured on the SecretStore.
+    In order to create a PushSecret targeting keys, the [Key Vault Crypto Officer](https://learn.microsoft.com/en-us/azure/role-based-access-control/built-in-roles/security#key-vault-crypto-officer) role, alternatively Access Policy permissions `Import` and `Delete` for Keys must be granted to the identity configured on the SecretStore.
+
 #### Pushing to a Certificate
-The first step is to generate a valid P12 certificate. Currently, only PKCS1/PKCS8 types are supported. Currently only password-less P12 certificates are supported.
 
-After uploading your P12 certificate to a Kubernetes Secret, the next step is to create a PushSecret manifest with the following configuration
+The P12 format (also known as PKCS12 or PFX) is recommended format for importing certificates to Azure Key Vault. The P12 file must contain both the certificate and the private key. Make sure to use PKCS8 format for the private key, as Azure Key Vault [does not support PKCS1 format](https://learn.microsoft.com/en-us/rest/api/keyvault/certificates/import-certificate/import-certificate?view=rest-keyvault-certificates-2025-07-01). Additionally, only password-less P12 files are supported.
+
+Provided you have a Kubernetes Secret with a P12 certificate, you can push it to Azure Key Vault by creating a `PushSecret` with the following configuration. The operator will read the P12 file from the Kubernetes Secret and import it into Azure Key Vault as a certificate.
+
+```yaml
+{% include 'azkv-pushsecret-certificate-p12.yaml' %}
+```
+
+Provided you have a Kubernetes Secret with the certificate and private key in PEM format, you can use the following configuration to transform it into a P12 file and push it to Azure Key Vault. The operator will read the certificate and private key from the Kubernetes Secret, convert them into a P12 file using template functions, and import it into Azure Key Vault as a certificate.
+
 ```yaml
-{% include 'azkv-pushsecret-certificate.yaml' %}
+{% include 'azkv-pushsecret-certificate-pem.yaml' %}
+```
+
+If you are using [cert-manager](https://cert-manager.io/) and its `Certificate` resource to generate the Kubernetes Secret in a PEM format as shown above, make sure to set `spec.privateKey.encoding` to `PKCS8`. By default, cert-manager generates private keys with PKCS1 encoding, which is not supported by Azure Key Vault.
+
+```yaml hl_lines="14"
+{% include 'azkv-pushsecret-certificate-cert-manager.yaml' %}
 ```
+
 !!! note
-       In order to create a PushSecret targeting keys, `ImportCertificate` and `DeleteCertificate` actions must be granted to the Service Principal/Identity configured on the SecretStore.
+    In order to create a PushSecret targeting certificates, the [Key Vault Certificates Officer](https://learn.microsoft.com/en-us/azure/role-based-access-control/built-in-roles/security#key-vault-certificates-officer) role, alternatively Access Policy permissions `Import` and `Delete` for Certificates must be granted to the identity configured on the SecretStore.

docs/snippets/azkv-pkcs12-cert-external-secret.yaml

@@ -13,8 +13,8 @@ spec:
       type: kubernetes.io/tls
       engineVersion: v2
       data:
-        tls.crt: "{{ .tls | b64dec | pkcs12cert }}"
-        tls.key: "{{ .tls | b64dec | pkcs12key }}"
+        tls.crt: '{{ .tls | b64dec | pkcs12cert }}'
+        tls.key: '{{ .tls | b64dec | pkcs12key }}'
   data:
   - secretKey: tls
     remoteRef:

docs/snippets/azkv-pushsecret-certificate-cert-manager.yaml

@@ -0,0 +1,16 @@
+apiVersion: cert-manager.io/v1
+kind: Certificate
+metadata:
+  name: dummy-certificate
+spec:
+  dnsNames:
+    - dummy.local
+  issuerRef:
+    group: cert-manager.io
+    kind: ClusterIssuer
+    name: letsencrypt-prod
+  secretName: source-certificate
+  privateKey:
+    encoding: PKCS8 # Must be PKCS8 for Azure Key Vault
+    algorithm: RSA
+    size: 2048

docs/snippets/azkv-pushsecret-certificate-p12.yaml

@@ -0,0 +1,26 @@
+apiVersion: v1
+kind: Secret
+metadata:
+  name: source-certificate
+data:
+  cert.p12: <BASE64_ENCODED_P12_CERTIFICATE>
+---
+apiVersion: external-secrets.io/v1alpha1
+kind: PushSecret
+metadata:
+  name: pushsecret-example
+  namespace: default
+spec:
+  refreshInterval: 1h0m0s # Refresh interval for which push secret will reconcile
+  deletionPolicy: Delete
+  secretStoreRefs: # A list of secret stores to push secrets to
+    - name: azure-store
+      kind: SecretStore
+  selector:
+    secret:
+      name: source-certificate # Source Kubernetes secret to be pushed
+  data:
+    - match:
+        secretKey: cert.p12 # Source Kubernetes secret key containing the P12 certificate
+        remoteRef:
+          remoteKey: cert/my-azkv-cert-name

docs/snippets/azkv-pushsecret-certificate-pem.yaml

@@ -0,0 +1,35 @@
+{% raw %}
+apiVersion: v1
+kind: Secret
+metadata:
+  name: source-certificate
+data:
+  tls.crt: <BASE64_ENCODED_PEM_CERTIFICATE>
+  tls.key: <BASE64_ENCODED_PEM_KEY>
+---
+apiVersion: external-secrets.io/v1alpha1
+kind: PushSecret
+metadata:
+  name: pushsecret-example
+  namespace: default
+spec:
+  refreshInterval: 1h0m0s # Refresh interval for which push secret will reconcile
+  deletionPolicy: Delete
+  secretStoreRefs: # A list of secret stores to push secrets to
+    - name: azure-store
+      kind: SecretStore
+  selector:
+    secret:
+      name: source-certificate # Source Kubernetes secret to be pushed
+  template:
+    engineVersion: v2
+    data:
+      # Use the `fullPemToPkcs12` function to convert the PEM-encoded certificate chain (certificate + intermediate certificates) + private key into a P12 file.
+      # You can also use the `pemToPkcs12` function if you only want to include the certificate + private key without the intermediate certificates.
+      cert.p12: '{{ fullPemToPkcs12 (index . "tls.crt" | toString) (index . "tls.key" | toString) | b64dec }}'
+  data:
+    - match:
+        secretKey: cert.p12 # Reference to the generated P12 file in the template data
+        remoteRef:
+          remoteKey: cert/my-azkv-cert-name
+{% endraw %}

docs/snippets/azkv-secret-store-mi.yaml

@@ -4,10 +4,9 @@ metadata:
   name: azure-store
 spec:
   provider:
-    # provider type: azure keyvault
     azurekv:
       authType: ManagedIdentity
-      # Optionally set the Id of the Managed Identity, if multiple identities are assigned to external-secrets operator
-      identityId: "<MI_clientId>"
-      # URL of your vault instance, see: https://docs.microsoft.com/en-us/azure/key-vault/general/about-keys-secrets-certificates
+      # Optionally set the ID of the Managed Identity, if multiple identities are assigned to External Secrets Operator.
+      identityId: "00000000-0000-0000-0000-000000000000"
+      # URL of your Key Vault instance, see: https://docs.microsoft.com/en-us/azure/key-vault/general/about-keys-secrets-certificates
       vaultUrl: "https://my-keyvault-name.vault.azure.net"

docs/snippets/azkv-secret-store-spn-certificate.yaml

@@ -0,0 +1,20 @@
+apiVersion: external-secrets.io/v1
+kind: SecretStore
+metadata:
+  name: azure-store-spn-certificate
+spec:
+  provider:
+    azurekv:
+      # Azure tenant ID, see: https://docs.microsoft.com/en-us/azure/active-directory/fundamentals/active-directory-how-to-find-tenant
+      tenantId: "2ed1d494-6c5a-4c5d-aa24-479446fb844d"
+      # URL of your Key Vault instance, see: https://docs.microsoft.com/en-us/azure/key-vault/general/about-keys-secrets-certificates
+      vaultUrl: "https://kvtestpushsecret.vault.azure.net"
+      authSecretRef:
+        # Reference to Kubernetes Secret name containing the Service Principal client ID under the key `ClientID`
+        clientId:
+          name: azure-secret-sp
+          key: ClientID
+        # Reference to Kubernetes Secret name containing the Service Principal client certificate in PEM format under the key `ClientCertificate`
+        clientCertificate:
+          name: azure-secret-sp
+          key: ClientCertificate

docs/snippets/azkv-secret-store-spn-secret.yaml

@@ -0,0 +1,20 @@
+apiVersion: external-secrets.io/v1
+kind: SecretStore
+metadata:
+  name: azure-store-spn-secret
+spec:
+  provider:
+    azurekv:
+      # Azure tenant ID, see: https://docs.microsoft.com/en-us/azure/active-directory/fundamentals/active-directory-how-to-find-tenant
+      tenantId: "2ed1d494-6c5a-4c5d-aa24-479446fb844d"
+      # URL of your Key Vault instance, see: https://docs.microsoft.com/en-us/azure/key-vault/general/about-keys-secrets-certificates
+      vaultUrl: "https://kvtestpushsecret.vault.azure.net"
+      authSecretRef:
+        # Reference to Kubernetes Secret name containing the Service Principal client ID under the key `ClientID`
+        clientId:
+          name: azure-secret-sp
+          key: ClientID
+        # Reference to Kubernetes Secret name containing the Service Principal client secret under the key `ClientSecret`
+        clientSecret:
+          name: azure-secret-sp
+          key: ClientSecret

docs/snippets/azkv-secret-store.yaml

@@ -1,21 +0,0 @@
-apiVersion: external-secrets.io/v1
-kind: SecretStore
-metadata:
-  name: azure-store
-spec:
-  provider:
-    # provider type: azure keyvault
-    azurekv:
-      # azure tenant ID, see: https://docs.microsoft.com/en-us/azure/active-directory/fundamentals/active-directory-how-to-find-tenant
-      tenantId: "2ed1d494-6c5a-4c5d-aa24-479446fb844d"
-      # URL of your vault instance, see: https://docs.microsoft.com/en-us/azure/key-vault/general/about-keys-secrets-certificates
-      vaultUrl: "https://kvtestpushsecret.vault.azure.net"
-      authSecretRef:
-        # points to the secret that contains
-        # the azure service principal credentials
-        clientId:
-          name: azure-secret-sp
-          key: ClientID
-        clientSecret:
-          name: azure-secret-sp
-          key: ClientSecret

docs/snippets/azkv-workload-identity-mounted.yaml

@@ -1,7 +1,7 @@
 apiVersion: v1
 kind: ServiceAccount
 metadata:
-  # this service account was created by azwi
+  # This service account was created by azwi
   name: workload-identity-sa
   annotations:
     azure.workload.identity/client-id: 7d8cdf74-xxxx-xxxx-xxxx-274d963d358b
@@ -16,4 +16,4 @@ spec:
     azurekv:
       authType: WorkloadIdentity
       vaultUrl: "https://xx-xxxx-xx.vault.azure.net"
-      # note: no serviceAccountRef was provided
+      # Note: no serviceAccountRef was provided

docs/snippets/azkv-workload-identity-secretref.yaml

@@ -1,7 +1,7 @@
 apiVersion: v1
 kind: ServiceAccount
 metadata:
-  # this service account was created by azwi
+  # This service account was created by azwi
   name: workload-identity-sa
   annotations: {}
 ---