Deployed 4acf82f2 to main with MkDocs 1.4.3 and mike 1.2.0.dev0

main/provider/azure-key-vault/index.html

@@ -2392,8 +2392,8 @@
 <h2 id="azure-key-vault">Azure Key vault</h2>
 <p>External Secrets Operator integrates with <a href="https://azure.microsoft.com/en-us/services/key-vault/">Azure Key vault</a> for secrets, certificates and Keys management.</p>
 <h3 id="authentication">Authentication</h3>
-<p>We support Service Principals, Managed Identity and Workload Identity authentication.</p>
-<p>To use Managed Identity authentication, you should use <a href="https://azure.github.io/aad-pod-identity/docs/">aad-pod-identity</a> to assign the identity to external-secrets operator. To add the selector to external-secrets operator, use <code>podLabels</code> in your values.yaml in case of Helm installation of external-secrets.</p>
+<p>We support authentication with Microsoft Entra identities that can be used as Workload Identity or <a href="https://azure.github.io/aad-pod-identity/docs/">AAD Pod Identity</a> as well as with Service Principal credentials.</p>
+<p>Since the <a href="https://azure.github.io/aad-pod-identity/docs/">AAD Pod Identity</a> is deprecated, it is recommended to use the <a href="https://azure.github.io/azure-workload-identity">Workload Identity</a> authentication.</p>
 <p>We support connecting to different cloud flavours azure supports: <code>PublicCloud</code>, <code>USGovernmentCloud</code>, <code>ChinaCloud</code> and <code>GermanCloud</code>. You have to specify the <code>environmentType</code> and point to the correct cloud flavour. This defaults to <code>PublicCloud</code>.</p>
 <div class="highlight"><pre><span></span><code><span class="nt">apiVersion</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">external-secrets.io/v1beta1</span>
 <span class="nt">kind</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">SecretStore</span>
@@ -2413,6 +2413,7 @@ az<span class="w"> </span>keyvault<span class="w"> </span>set-policy<span class=
 <p>A service Principal client and Secret is created and the JSON keyfile is stored in a <code>Kind=Secret</code>. The <code>ClientID</code> and <code>ClientSecret</code> should be configured for the secret. This service principal should have proper access rights to the keyvault to be managed by the operator</p>
 <h4 id="managed-identity-authentication">Managed Identity authentication</h4>
 <p>A Managed Identity should be created in Azure, and that Identity should have proper rights to the keyvault to be managed by the operator.</p>
+<p>Use <a href="https://azure.github.io/aad-pod-identity/docs/">aad-pod-identity</a> to assign the identity to external-secrets operator. To add the selector to external-secrets operator, use <code>podLabels</code> in your values.yaml in case of Helm installation of external-secrets.</p>
 <p>If there are multiple Managed Identities for different keyvaults, the operator should have been assigned all identities via <a href="https://azure.github.io/aad-pod-identity/docs/">aad-pod-identity</a>, then the SecretStore configuration should include the Id of the identity to be used via the <code>identityId</code> field.</p>
 <div class="highlight"><pre><span></span><code><span class="nt">apiVersion</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">external-secrets.io/v1beta1</span>
 <span class="nt">kind</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">SecretStore</span>
@@ -2429,6 +2430,7 @@ az<span class="w"> </span>keyvault<span class="w"> </span>set-policy<span class=
 <span class="w">      </span><span class="nt">vaultUrl</span><span class="p">:</span><span class="w"> </span><span class="s">&quot;https://my-keyvault-name.vault.azure.net&quot;</span>
 </code></pre></div>
 <h4 id="workload-identity">Workload Identity</h4>
+<p>In Microsoft Entra, Workload Identity can be Application, user-assigned Managed Identity and Service Principal.</p>
 <p>You can use <a href="https://docs.microsoft.com/en-us/azure/active-directory/develop/workload-identity-federation">Azure AD Workload Identity Federation</a> to access Azure managed services like Key Vault <strong>without needing to manage secrets</strong>. You need to configure a trust relationship between your Kubernetes Cluster and Azure AD. This can be done in various ways, for instance using <code>terraform</code>, the Azure Portal or the <code>az</code> cli. We found the <a href="https://azure.github.io/azure-workload-identity/docs/installation/azwi.html">azwi</a> cli very helpful. The Azure <a href="https://azure.github.io/azure-workload-identity/docs/quick-start.html">Workload Identity Quick Start Guide</a> is also good place to get started.</p>
 <p>This is basically a two step process:</p>
 <ol>
@@ -2470,7 +2472,7 @@ az<span class="w"> </span>keyvault<span class="w"> </span>set-policy<span class=
 <span class="w">      </span><span class="c1"># note: no serviceAccountRef was provided</span>
 </code></pre></div>
 <h5 id="referenced-service-account">Referenced Service Account</h5>
-<p>You run the controller without service account (effectively without azure permissions). Now you have to configure the SecretStore and set the <code>serviceAccountRef</code> and point to the service account you have just created. <strong>This is usually the recommended approach</strong>. It makes sense for everyone who wants to run the controller withour Azure permissions and delegate authentication via service accounts in particular namespaces. Also see our [Multi-Tenancy Guide] for design considerations.</p>
+<p>You run the controller without service account (effectively without azure permissions). Now you have to configure the SecretStore and set the <code>serviceAccountRef</code> and point to the service account you have just created. <strong>This is usually the recommended approach</strong>. It makes sense for everyone who wants to run the controller without Azure permissions and delegate authentication via service accounts in particular namespaces. Also see our <a href="../../guides/multi-tenancy/">Multi-Tenancy Guide</a> for design considerations.</p>
 <div class="highlight"><pre><span></span><code><span class="nt">apiVersion</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">v1</span>
 <span class="nt">kind</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">ServiceAccount</span>
 <span class="nt">metadata</span><span class="p">:</span>
@@ -2533,7 +2535,7 @@ az<span class="w"> </span>keyvault<span class="w"> </span>set-policy<span class=
 <span class="w">      </span><span class="nt">vaultUrl</span><span class="p">:</span><span class="w"> </span><span class="s">&quot;https://my-keyvault-name.vault.azure.net&quot;</span>
 </code></pre></div>
 <h3 id="object-types">Object Types</h3>
-<p>Azure KeyVault manages different <a href="https://docs.microsoft.com/en-us/azure/key-vault/general/about-keys-secrets-certificates#object-types">object types</a>, we support <code>keys</code>, <code>secrets</code> and <code>certificates</code>. Simply prefix the key with <code>key</code>, <code>secret</code> or <code>cert</code> to retrieve the desired type (defaults to secret).</p>
+<p>Azure Key Vault manages different <a href="https://docs.microsoft.com/en-us/azure/key-vault/general/about-keys-secrets-certificates#object-types">object types</a>, we support <code>keys</code>, <code>secrets</code> and <code>certificates</code>. Simply prefix the key with <code>key</code>, <code>secret</code> or <code>cert</code> to retrieve the desired type (defaults to secret).</p>
 <table>
 <thead>
 <tr>
@@ -2548,7 +2550,7 @@ az<span class="w"> </span>keyvault<span class="w"> </span>set-policy<span class=
 </tr>
 <tr>
 <td><code>key</code></td>
-<td>A JWK which contains the public key. Azure KeyVault does <strong>not</strong> export the private key. You may want to use <a href="../../guides/templating/">template functions</a> to transform this JWK into PEM encoded PKIX ASN.1 DER format.</td>
+<td>A JWK which contains the public key. Azure Key Vault does <strong>not</strong> export the private key. You may want to use <a href="../../guides/templating/">template functions</a> to transform this JWK into PEM encoded PKIX ASN.1 DER format.</td>
 </tr>
 <tr>
 <td><code>certificate</code></td>
@@ -2557,7 +2559,7 @@ az<span class="w"> </span>keyvault<span class="w"> </span>set-policy<span class=
 </tbody>
 </table>
 <h3 id="creating-external-secret">Creating external secret</h3>
-<p>To create a kubernetes secret from the Azure Key vault secret a <code>Kind=ExternalSecret</code> is needed.</p>
+<p>To create a Kubernetes secret from the Azure Key vault secret a <code>Kind=ExternalSecret</code> is needed.</p>
 <p>You can manage keys/secrets/certificates saved inside the keyvault , by setting a "/" prefixed type in the secret name, the default type is a <code>secret</code>. Other supported values are <code>cert</code> and <code>key</code>.</p>
 <div class="highlight"><pre><span></span><code><span class="nt">apiVersion</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">external-secrets.io/v1beta1</span>
 <span class="nt">kind</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">ExternalSecret</span>
@@ -2669,9 +2671,9 @@ az<span class="w"> </span>keyvault<span class="w"> </span>set-policy<span class=
 <span class="w">      </span><span class="nt">key</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">secret/tls-client-credentials</span>
 </code></pre></div>
 <h3 id="creating-a-pushsecret">Creating a PushSecret</h3>
-<p>You can push secrets to Keyvault into the different <code>secret</code>, <code>key</code> and <code>certificate</code> APIs.</p>
+<p>You can push secrets to Azure Key Vault into the different <code>secret</code>, <code>key</code> and <code>certificate</code> APIs.</p>
 <h4 id="pushing-to-a-secret">Pushing to a Secret</h4>
-<p>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 Keyvault:
+<p>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:
 <div class="highlight"><pre><span></span><code><span class="nt">apiVersion</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">v1</span>
 <span class="nt">kind</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">Secret</span>
 <span class="nt">metadata</span><span class="p">:</span>
@@ -2737,7 +2739,7 @@ az<span class="w"> </span>keyvault<span class="w"> </span>set-policy<span class=
 <p>In order to create a PushSecret targeting keys, <code>ImportKey</code> and <code>DeleteKey</code> actions must be granted to the Service Principal/Identity configured on the SecretStore.</p>
 </div>
 <h4 id="pushing-to-a-certificate">Pushing to a Certificate</h4>
-<p>The first step is to generate a valid P12 certificate. Currently, only PKCS1/PKCS8 types are supported. Currently only passwordless P12 certificates are supported.</p>
+<p>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.</p>
 <p>After uploading your P12 certificate to a Kubernetes Secret, the next step is to create a PushSecret manifest with the following configuration
 <div class="highlight"><pre><span></span><code><span class="nt">apiVersion</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">v1</span>
 <span class="nt">kind</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">Secret</span>