Deployed 9cfb79324 to main with MkDocs 1.6.1 and mike 1.2.0.dev0

main/api/externalsecret/index.html

@@ -5108,11 +5108,13 @@ be transformed and saved as a <code>Kind=Secret</code>:</p>
 <h2 id="update-behavior-with-3-different-refresh-policies">Update behavior with 3 different refresh policies</h2>
 <p>You can control how and when the <code>ExternalSecret</code> is refreshed by setting the <code>spec.refreshPolicy</code> field. If not specified, the default behavior is <code>Periodic</code>.</p>
 <h3 id="createdonce">CreatedOnce</h3>
-<p>With <code>refreshPolicy: CreatedOnce</code>, the controller will:
-- Create the <code>Kind=Secret</code> only if it does not exist yet
-- Never update the <code>Kind=Secret</code> afterwards if the source data changes
-- Update/ Recreate the <code>Kind=Secret</code> if it gets changed/Deleted
-- Useful for immutable credentials or when you want to manage updates manually</p>
+<p>With <code>refreshPolicy: CreatedOnce</code>, the controller will:</p>
+<ul>
+<li>Create the <code>Kind=Secret</code> only if it does not exist yet</li>
+<li>Never update the <code>Kind=Secret</code> afterwards if the source data changes</li>
+<li>Update/ Recreate the <code>Kind=Secret</code> if it gets changed/Deleted</li>
+<li>Useful for immutable credentials or when you want to manage updates manually</li>
+</ul>
 <p>Example:
 <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/v1</span>
 <span class="nt">kind</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">ExternalSecret</span>
@@ -5123,11 +5125,13 @@ be transformed and saved as a <code>Kind=Secret</code>:</p>
 <span class="w">  </span><span class="c1"># other fields...</span>
 </code></pre></div></p>
 <h3 id="periodic">Periodic</h3>
-<p>With <code>refreshPolicy: Periodic</code> (the default behavior), the controller will:
-- Create the <code>Kind=Secret</code> if it doesn't exist
-- Update the <code>Kind=Secret</code> regularly based on the <code>spec.refreshInterval</code> duration
-- When <code>spec.refreshInterval</code> is set to zero, it will only create the secret once and not update it afterward
-- When <code>spec.refreshInterval</code> is set to a value greater than zero, the controller will update the <code>Kind=Secret</code> at the specified interval or when the <code>ExternalSecret</code> specification changes</p>
+<p>With <code>refreshPolicy: Periodic</code> (the default behavior), the controller will:</p>
+<ul>
+<li>Create the <code>Kind=Secret</code> if it doesn't exist</li>
+<li>Update the <code>Kind=Secret</code> regularly based on the <code>spec.refreshInterval</code> duration</li>
+<li>When <code>spec.refreshInterval</code> is set to zero, it will only create the secret once and not update it afterward</li>
+<li>When <code>spec.refreshInterval</code> is set to a value greater than zero, the controller will update the <code>Kind=Secret</code> at the specified interval or when the <code>ExternalSecret</code> specification changes</li>
+</ul>
 <p>Example:
 <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/v1</span>
 <span class="nt">kind</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">ExternalSecret</span>
@@ -5139,11 +5143,13 @@ be transformed and saved as a <code>Kind=Secret</code>:</p>
 <span class="w">  </span><span class="c1"># other fields...</span>
 </code></pre></div></p>
 <h3 id="onchange">OnChange</h3>
-<p>With <code>refreshPolicy: OnChange</code>, the controller will:
-- Create the <code>Kind=Secret</code> if it doesn't exist
-- Update the <code>Kind=Secret</code> only when the <code>ExternalSecret</code>'s metadata or specification changes
-- This policy is independent of the <code>refreshInterval</code> value
-- Useful when you want to manually control when the secret is updated, by modifying the <code>ExternalSecret</code> resource</p>
+<p>With <code>refreshPolicy: OnChange</code>, the controller will:</p>
+<ul>
+<li>Create the <code>Kind=Secret</code> if it doesn't exist</li>
+<li>Update the <code>Kind=Secret</code> only when the <code>ExternalSecret</code>'s metadata or specification changes</li>
+<li>This policy is independent of the <code>refreshInterval</code> value</li>
+<li>Useful when you want to manually control when the secret is updated, by modifying the <code>ExternalSecret</code> resource</li>
+</ul>
 <p>Example:
 <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/v1</span>
 <span class="nt">kind</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">ExternalSecret</span>

main/contributing/burnout-mitigation/index.html

@@ -5526,10 +5526,12 @@ We need to keep monitoring influx items and pay attention to when the pressure i
 <h4 id="automate-repetitive-tasks">Automate Repetitive Tasks</h4>
 <p>CI/CD pipelines can help a lot in taking away some of the menial tasks while working on the project.
 Immediate bot responses for triage issues could be configured using copilot, or other means like claude code github action.
-These responses would use the repository as a context and could give immediate valuable info to the submitter such as:
-- Duplicate issues
-- Possible solutions looking at the documentation
-- Link to existing documentation based on context</p>
+These responses would use the repository as a context and could give immediate valuable info to the submitter such as:</p>
+<ul>
+<li>Duplicate issues</li>
+<li>Possible solutions looking at the documentation</li>
+<li>Link to existing documentation based on context</li>
+</ul>
 <p>These need to be fine-tuned but could potentially alleviate some of the tress and pressure for the maintainers.</p>
 <h3 id="community-building">Community Building</h3>
 <p>It is important that we nurture an understanding and caring community. People who use ESO will have to understand that demands will lead no-where.
@@ -5580,22 +5582,26 @@ Thanks for being part of this community! 🚀
 </code></pre></div>
 <h2 id="conclusion">Conclusion</h2>
 <p>This document sums up various procedures and things that we can do and we can start on. The important part is publication,
-visibility and outreach. There are many channel on which ESO can communicate but the most important ones are:
-- Slack ( <a href="https://kubernetes.slack.com/archives/C017BF84G2Y">external-secrets</a>, <a href="https://kubernetes.slack.com/archives/C047LA9MUPJ">external-secrets-dev</a> channels )
-- Reddit <a href="https://www.reddit.com/r/kubernetes/">Kubernetes Subreddit</a> ( this was particulalry helpful in the past )
-- HackerNews pos
-- LinkedIn
-- CNCF help channels and issue requests
-- Pinned Issue on GitHub page</p>
+visibility and outreach. There are many channel on which ESO can communicate but the most important ones are:</p>
+<ul>
+<li>Slack ( <a href="https://kubernetes.slack.com/archives/C017BF84G2Y">external-secrets</a>, <a href="https://kubernetes.slack.com/archives/C047LA9MUPJ">external-secrets-dev</a> channels )</li>
+<li>Reddit <a href="https://www.reddit.com/r/kubernetes/">Kubernetes Subreddit</a> ( this was particulalry helpful in the past )</li>
+<li>HackerNews pos</li>
+<li>LinkedIn</li>
+<li>CNCF help channels and issue requests</li>
+<li>Pinned Issue on GitHub page</li>
+</ul>
 <p>Whatever we do the most important part is visibility <em>BEFORE</em> we get to this point. Before all of this, the most important part is
 monitoring the maintainers health and general well being. Prevention instead of escalation.</p>
 <h2 id="our-reaction-when-things-do-not-go-as-planned">Our reaction when things do not go as planned</h2>
 <p>Contributors will come and go. It is perfectly normal (and even welcomed!) in an open source project.
 When events occur and response do not go as planned, the maintainers team will take decisions and expose them in a community meeting.</p>
 <p>Here is our DNA: Contributor's healths come first. We will never compromise humans for software.</p>
-<p>The team will try (best effort) to:
-- minimize impact on community
-- be transparent over any potential impact</p>
+<p>The team will try (best effort) to:</p>
+<ul>
+<li>minimize impact on community</li>
+<li>be transparent over any potential impact</li>
+</ul>
 <p>Maintainers stepping back from the project is perfectly <em>fine</em>, the project slowing down is <em>fine</em>. this shouldn't be seen as a negative. People need to take care of themselves first before they can take care of the project.</p>
 
 

main/contributing/devguide/index.html

@@ -5072,10 +5072,12 @@ docker<span class="w"> </span>run<span class="w"> </span>--rm<span class="w"> </
 <h2 id="using-tilt">Using Tilt</h2>
 <p><a href="https://tilt.dev">Tilt</a> can be used to develop external-secrets. Tilt will hot-reload changes to the code and replace
 the running binary in the container using a process manager of its own.</p>
-<p>To run tilt, download the utility for your operating system and run <code>make tilt-up</code>. This will do two things:
-- downloads tilt for the current OS and ARCH under <code>bin/tilt</code>
-- make manifest files of your current changes and place them under <code>./bin/deploy/manifests/external-secrets.yaml</code>
-- run tilt with <code>tilt run</code></p>
+<p>To run tilt, download the utility for your operating system and run <code>make tilt-up</code>. This will do two things:</p>
+<ul>
+<li>downloads tilt for the current OS and ARCH under <code>bin/tilt</code></li>
+<li>make manifest files of your current changes and place them under <code>./bin/deploy/manifests/external-secrets.yaml</code></li>
+<li>run tilt with <code>tilt run</code></li>
+</ul>
 <p>Hit <code>space</code> and you can observe all the pods starting up and track their output in the tilt UI.</p>
 <h2 id="installing">Installing</h2>
 <p>To install the External Secret Operator into a Kubernetes Cluster run:</p>

main/contributing/release/index.html

@@ -4977,12 +4977,14 @@
 <p>ESO and the ESO Helm Chart have two distinct lifecycles and can be released independently. Helm Chart releases are named <code>external-secrets-x.y.z</code>.</p>
 <p>The external-secrets project is released on a as-needed basis. Feel free to open a issue to request a release.</p>
 <h2 id="multi-module-versioning">Multi-Module Versioning</h2>
-<p>External Secrets Operator uses a multi-module structure with the following modules:
-- <code>/apis</code> - CRD types and interfaces
-- <code>/runtime</code> - Shared utilities
-- <code>/providers/v1/*</code> - Individual provider modules
-- <code>/generators/v1/*</code> - Individual generator modules
-- <code>/</code> (root) - Main module with controllers and binary</p>
+<p>External Secrets Operator uses a multi-module structure with the following modules:</p>
+<ul>
+<li><code>/apis</code> - CRD types and interfaces</li>
+<li><code>/runtime</code> - Shared utilities</li>
+<li><code>/providers/v1/*</code> - Individual provider modules</li>
+<li><code>/generators/v1/*</code> - Individual generator modules</li>
+<li><code>/</code> (root) - Main module with controllers and binary</li>
+</ul>
 <p><strong>All modules share the same version tag.</strong> When releasing version <code>v0.x.y</code>, a single git tag is created that applies to all modules in the repository. Go's module system automatically handles this, and consumers can reference any module using the same version tag.</p>
 <p>For example:
 <div class="highlight"><pre><span></span><code><span class="nx">require</span><span class="w"> </span><span class="p">(</span>
@@ -5015,12 +5017,14 @@ Otherwise the <code>latest</code> documentation will point to the older version.
 <li>merge PR if everything is green</li>
 <li>CI picks up the new chart version and creates a new GitHub Release for it</li>
 </ol>
-<p>The following things are updated with those commands:
-1. Update helm docs
-2. Update the apiVersion in the snapshots for the helm tests
-3. Update all the helm tests with potential added values
-4. Update the stability docs with the latest minor version if exists
-5. Update the CRD conformance tests</p>
+<p>The following things are updated with those commands:</p>
+<ol>
+<li>Update helm docs</li>
+<li>Update the apiVersion in the snapshots for the helm tests</li>
+<li>Update all the helm tests with potential added values</li>
+<li>Update the stability docs with the latest minor version if exists</li>
+<li>Update the CRD conformance tests</li>
+</ol>
 <p>The branch to create this release should be <code>release-chart-x.y.z</code>. Though be aware that release branches are <em>immutable</em>.
 This means that if there is anything that needs to be fixed, a new branch will need to be created.</p>
 <p>Also, keep an eye on <code>main</code> so nothing is merged while the chart branch is running the e2e tests. If that happens,

main/examples/pushsecret-datato/index.html

@@ -5097,13 +5097,15 @@
 <span class="w">            </span><span class="nt">source</span><span class="p">:</span><span class="w"> </span><span class="s">&quot;^db-&quot;</span>
 <span class="w">            </span><span class="nt">target</span><span class="p">:</span><span class="w"> </span><span class="s">&quot;myapp/production/database/&quot;</span>
 </code></pre></div></p>
-<p><strong>Result in AWS Secrets Manager:</strong>
-- <code>myapp/production/database/host</code>
-- <code>myapp/production/database/port</code>
-- <code>myapp/production/database/username</code>
-- <code>myapp/production/database/password</code>
-- <code>myapp/production/database/database</code>
-- <code>myapp/production/database/ssl-mode</code></p>
+<p><strong>Result in AWS Secrets Manager:</strong></p>
+<ul>
+<li><code>myapp/production/database/host</code></li>
+<li><code>myapp/production/database/port</code></li>
+<li><code>myapp/production/database/username</code></li>
+<li><code>myapp/production/database/password</code></li>
+<li><code>myapp/production/database/database</code></li>
+<li><code>myapp/production/database/ssl-mode</code></li>
+</ul>
 <h2 id="example-2-multi-environment-configuration">Example 2: Multi-Environment Configuration</h2>
 <p>Push the same secrets to different environments with different prefixes.</p>
 <p><strong>Source Secret:</strong>
@@ -5219,13 +5221,15 @@
 <span class="w">            </span><span class="nt">source</span><span class="p">:</span><span class="w"> </span><span class="s">&quot;^tls-&quot;</span>
 <span class="w">            </span><span class="nt">target</span><span class="p">:</span><span class="w"> </span><span class="s">&quot;config/tls/&quot;</span>
 </code></pre></div></p>
-<p><strong>Result:</strong>
-- <code>config/database/host</code>
-- <code>config/database/password</code>
-- <code>config/api/github-token</code>
-- <code>config/api/stripe-key</code>
-- <code>config/tls/cert</code>
-- <code>config/tls/key</code></p>
+<p><strong>Result:</strong></p>
+<ul>
+<li><code>config/database/host</code></li>
+<li><code>config/database/password</code></li>
+<li><code>config/api/github-token</code></li>
+<li><code>config/api/stripe-key</code></li>
+<li><code>config/tls/cert</code></li>
+<li><code>config/tls/key</code></li>
+</ul>
 <h2 id="example-4-template-transformation">Example 4: Template Transformation</h2>
 <p>Use Go templates to transform key names with advanced logic.</p>
 <p><strong>Source Secret:</strong>
@@ -5259,10 +5263,12 @@
 <span class="w">        </span><span class="p p-Indicator">-</span><span class="w"> </span><span class="nt">transform</span><span class="p">:</span>
 <span class="w">            </span><span class="nt">template</span><span class="p">:</span><span class="w"> </span><span class="s">&quot;services/{{</span><span class="nv"> </span><span class="s">.value</span><span class="nv"> </span><span class="s">|</span><span class="nv"> </span><span class="s">upper</span><span class="nv"> </span><span class="s">|</span><span class="nv"> </span><span class="s">replace</span><span class="nv"> </span><span class="s">\&quot;-\&quot;</span><span class="nv"> </span><span class="s">\&quot;_\&quot;</span><span class="nv"> </span><span class="s">}}&quot;</span>
 </code></pre></div>
-<p><strong>Result:</strong>
-- <code>services/PAYMENT_GATEWAY_KEY</code>
-- <code>services/EMAIL_SERVICE_KEY</code>
-- <code>services/STORAGE_SERVICE_KEY</code></p>
+<p><strong>Result:</strong></p>
+<ul>
+<li><code>services/PAYMENT_GATEWAY_KEY</code></li>
+<li><code>services/EMAIL_SERVICE_KEY</code></li>
+<li><code>services/STORAGE_SERVICE_KEY</code></li>
+</ul>
 <h2 id="example-5-chained-transformations">Example 5: Chained Transformations</h2>
 <p>Apply multiple transformations sequentially for complex key restructuring.</p>
 <p><strong>Source Secret:</strong>
@@ -5306,10 +5312,12 @@
 <span class="w">            </span><span class="nt">source</span><span class="p">:</span><span class="w"> </span><span class="s">&quot;-&quot;</span>
 <span class="w">            </span><span class="nt">target</span><span class="p">:</span><span class="w"> </span><span class="s">&quot;/&quot;</span>
 </code></pre></div></p>
-<p><strong>Result:</strong>
-- <code>migrated/db/primary/host</code>
-- <code>migrated/db/replica/host</code>
-- <code>migrated/cache/redis/url</code></p>
+<p><strong>Result:</strong></p>
+<ul>
+<li><code>migrated/db/primary/host</code></li>
+<li><code>migrated/db/replica/host</code></li>
+<li><code>migrated/cache/redis/url</code></li>
+</ul>
 <h2 id="example-6-override-specific-keys">Example 6: Override Specific Keys</h2>
 <p>Use both dataTo and explicit data to handle exceptions.</p>
 <p><strong>Source Secret:</strong>
@@ -5356,12 +5364,14 @@
 <span class="w">        </span><span class="nt">remoteRef</span><span class="p">:</span>
 <span class="w">          </span><span class="nt">remoteKey</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">admin/database/password</span>
 </code></pre></div></p>
-<p><strong>Result:</strong>
-- <code>app/database/host</code> (from dataTo)
-- <code>app/database/port</code> (from dataTo)
-- <code>app/database/user</code> (from dataTo)
-- <code>app/database/password</code> (from dataTo)
-- <code>admin/database/password</code> (from explicit data override)</p>
+<p><strong>Result:</strong></p>
+<ul>
+<li><code>app/database/host</code> (from dataTo)</li>
+<li><code>app/database/port</code> (from dataTo)</li>
+<li><code>app/database/user</code> (from dataTo)</li>
+<li><code>app/database/password</code> (from dataTo)</li>
+<li><code>admin/database/password</code> (from explicit data override)</li>
+</ul>
 <h2 id="example-7-aws-secrets-manager-with-metadata">Example 7: AWS Secrets Manager with Metadata</h2>
 <p>Push secrets with AWS-specific metadata tags.</p>
 <p><strong>PushSecret with Metadata:</strong>
@@ -5441,10 +5451,12 @@
 <span class="w">            </span><span class="nt">source</span><span class="p">:</span><span class="w"> </span><span class="s">&quot;^shared-&quot;</span>
 <span class="w">            </span><span class="nt">target</span><span class="p">:</span><span class="w"> </span><span class="s">&quot;shared/&quot;</span>
 </code></pre></div></p>
-<p><strong>Result:</strong>
-- <code>services/a/api-key</code>
-- <code>services/b/api-key</code>
-- <code>shared/secret</code></p>
+<p><strong>Result:</strong></p>
+<ul>
+<li><code>services/a/api-key</code></li>
+<li><code>services/b/api-key</code></li>
+<li><code>shared/secret</code></li>
+</ul>
 <h2 id="example-9-azure-key-vault">Example 9: Azure Key Vault</h2>
 <p>Push secrets to Azure Key Vault with naming constraints (alphanumeric and hyphens only).</p>
 <p><strong>PushSecret for Azure:</strong>
@@ -5522,15 +5534,21 @@
 <div class="highlight"><pre><span></span><code>kubectl<span class="w"> </span>get<span class="w"> </span>pushsecret<span class="w"> </span>&lt;name&gt;<span class="w"> </span>-n<span class="w"> </span>&lt;namespace&gt;<span class="w"> </span>-o<span class="w"> </span><span class="nv">jsonpath</span><span class="o">=</span><span class="s1">&#39;{.status.syncedPushSecrets}&#39;</span><span class="w"> </span><span class="p">|</span><span class="w"> </span>jq
 </code></pre></div>
 <h3 id="common-issues">Common Issues</h3>
-<p><strong>1. No keys matched:</strong>
-- Verify the source Secret has keys matching your pattern
-- Check regexp syntax: <code>kubectl get secret &lt;name&gt; -o jsonpath='{.data}' | jq 'keys'</code></p>
-<p><strong>2. Invalid regexp error:</strong>
-- Validate your regexp using an online regexp tester
-- Ensure special characters are properly escaped</p>
-<p><strong>3. Duplicate remote keys:</strong>
-- Check if your rewrites produce unique keys
-- Adjust patterns or use explicit data overrides</p>
+<p><strong>1. No keys matched:</strong></p>
+<ul>
+<li>Verify the source Secret has keys matching your pattern</li>
+<li>Check regexp syntax: <code>kubectl get secret &lt;name&gt; -o jsonpath='{.data}' | jq 'keys'</code></li>
+</ul>
+<p><strong>2. Invalid regexp error:</strong></p>
+<ul>
+<li>Validate your regexp using an online regexp tester</li>
+<li>Ensure special characters are properly escaped</li>
+</ul>
+<p><strong>3. Duplicate remote keys:</strong></p>
+<ul>
+<li>Check if your rewrites produce unique keys</li>
+<li>Adjust patterns or use explicit data overrides</li>
+</ul>
 <h2 id="best-practices">Best Practices</h2>
 <ol>
 <li><strong>Start with match-all to verify</strong>: Test with <code>dataTo: [{storeRef: {name: your-store}}]</code> first</li>

main/guides/templating/index.html

@@ -5576,13 +5576,17 @@ NtFUGA95RGN9s+pl6XY0YARPHf5O76ErC1OZtDTR5RdyQfcM+94gYZsexsXl0aQO
 <h3 id="rsa-decryption-data-from-provider">RSA Decryption Data From Provider</h3>
 <p>When a provider returns RSA-encrypted values, you can decrypt them directly in the template using the <code>rsaDecrypt</code> functions (engine v2).
 <code>rsaDecrypt</code> performs decryption with the private key passed through the pipeline: <code>&lt;privateKeyPEM | rsaDecrypt "&lt;SCHEME&gt;" "&lt;HASH&gt;" &lt;ciphertext&gt; &gt;</code>. <code>SCHEME</code> and <code>HASH</code> are strings (for example, <code>"RSA-OAEP"</code> and <code>"SHA1"</code>). The third argument must be the ciphertext in binary form.</p>
-<p>Base64 handling: providers often return ciphertext as Base64. You can either:
-- decode in the template with <code>b64dec</code> (for example: <code>(.password_encrypted_base64 | b64dec)</code>), or
-- set <code>decodingStrategy: Base64</code> on the corresponding <code>spec.data.remoteRef</code> so the template receives binary data.</p>
-<p>Prerequisites
-- <code>spec.target.template.engineVersion: v2</code>.
-- A valid RSA private key in PEM format without passphrase (from another reference in the same ExternalSecret).
-- Ciphertext must match the key pair and the chosen algorithm/hash.</p>
+<p>Base64 handling: providers often return ciphertext as Base64. You can either:</p>
+<ul>
+<li>decode in the template with <code>b64dec</code> (for example: <code>(.password_encrypted_base64 | b64dec)</code>), or</li>
+<li>set <code>decodingStrategy: Base64</code> on the corresponding <code>spec.data.remoteRef</code> so the template receives binary data.</li>
+</ul>
+<p>Prerequisites</p>
+<ul>
+<li><code>spec.target.template.engineVersion: v2</code>.</li>
+<li>A valid RSA private key in PEM format without passphrase (from another reference in the same ExternalSecret).</li>
+<li>Ciphertext must match the key pair and the chosen algorithm/hash.</li>
+</ul>
 <p>Full example:</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/v1</span>
 <span class="nt">kind</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">ExternalSecret</span>
@@ -5617,12 +5621,16 @@ NtFUGA95RGN9s+pl6XY0YARPHf5O76ErC1OZtDTR5RdyQfcM+94gYZsexsXl0aQO
 <span class="w">  </span><span class="c1">#     decodingStrategy: Base64</span>
 <span class="w">  </span><span class="c1"># ...</span>
 </code></pre></div>
-<p>Useful variations (included as comments in the example):
-- Base64 decode in the template with <code>b64dec</code> or via <code>decodingStrategy: Base64</code> on <code>spec.data</code>.
-- Use a private key available in the same ExternalSecret (for example: <code>( .private_key | rsaDecrypt ... )</code>).</p>
-<p>Error notes
-- Referencing a missing key in the template will fail rendering.
-- If key/algorithm/hash do not match the ciphertext, decryption will fail and reconciliation will retry.</p>
+<p>Useful variations (included as comments in the example):</p>
+<ul>
+<li>Base64 decode in the template with <code>b64dec</code> or via <code>decodingStrategy: Base64</code> on <code>spec.data</code>.</li>
+<li>Use a private key available in the same ExternalSecret (for example: <code>( .private_key | rsaDecrypt ... )</code>).</li>
+</ul>
+<p>Error notes</p>
+<ul>
+<li>Referencing a missing key in the template will fail rendering.</li>
+<li>If key/algorithm/hash do not match the ciphertext, decryption will fail and reconciliation will retry.</li>
+</ul>
 <h2 id="templating-with-pushsecret">Templating with PushSecret</h2>
 <p><code>PushSecret</code> templating is much like <code>ExternalSecrets</code> templating. In-fact under the hood, it's using the same data structure.
 Which means, anything described in the above should be possible with push secret as well resulting in a templated secret

main/introduction/faq/index.html

@@ -5052,10 +5052,12 @@ the <code>external-secrets.io/force-sync</code> annotation on the ClusterExterna
 <div class="highlight"><pre><span></span><code>kubectl get es my-external-secret -o yaml | grep refreshTime
   refreshTime: &quot;2022-05-21T23:02:47Z&quot;
 </code></pre></div>
-<p>The interval can be changed by the <code>spec.refreshInterval</code> in the ExternalSecret. You can also control the refresh behavior by setting <code>spec.refreshPolicy</code> to one of the following options:
-- <code>Periodic</code> (default): Update regularly based on refreshInterval
-- <code>CreatedOnce</code>: Create the Secret only once and never update it afterward
-- <code>OnChange</code>: Only update when the ExternalSecret's metadata or specification changes</p>
+<p>The interval can be changed by the <code>spec.refreshInterval</code> in the ExternalSecret. You can also control the refresh behavior by setting <code>spec.refreshPolicy</code> to one of the following options:</p>
+<ul>
+<li><code>Periodic</code> (default): Update regularly based on refreshInterval</li>
+<li><code>CreatedOnce</code>: Create the Secret only once and never update it afterward</li>
+<li><code>OnChange</code>: Only update when the ExternalSecret's metadata or specification changes</li>
+</ul>
 <h2 id="how-do-i-know-when-the-status-of-my-secret-changed-the-last-time">How do I know when the status of my secret changed the last time?</h2>
 <p>Every ExternalSecret resource contains a status condition that indicates whether a secret was successfully synchronized, along with the timestamp of the last status change of the ExternalSecret (e.g. from SecretSyncedError to SecretSynced). This can be obtained from the field <code>lastTransitionTime</code>:</p>
 <div class="highlight"><pre><span></span><code>kubectl get es my-external-secret -o yaml | grep condition -A 5

main/introduction/stability-support/index.html

@@ -5081,9 +5081,11 @@
 <p>This page lists the status, timeline and policy for currently supported ESO releases and its providers. Please also see our <a href="../deprecation-policy/">deprecation policy</a> that describes API versioning, deprecation and API surface.</p>
 <h2 id="supported-versions">Supported Versions</h2>
 <p>external-secrets only supports the most-up-to date, current minor version. Any other minor version releases are automatically deprecated as soon as a new minor version comes.</p>
-<p>During a minor version support time, we cover:
-- regular image rebuilds to update OS dependencies
-- regular go dependency updates</p>
+<p>During a minor version support time, we cover:</p>
+<ul>
+<li>regular image rebuilds to update OS dependencies</li>
+<li>regular go dependency updates</li>
+</ul>
 <p>We do not do test coverage for any other kubernetes version than the ones running on our test suites.
 As of version 0.14.x , this is the only kubernetes version that we will guarantee support for.</p>
 <table>

main/provider/aws-parameter-store/index.html

@@ -5362,11 +5362,13 @@ Please estimate your costs before using ESO. Cost depends on the RefreshInterval
 <span class="w">          </span><span class="nt">property</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">best-pokemon-dst</span><span class="w"> </span><span class="c1"># The key within the destination secret object.</span>
 </code></pre></div>
 <h4 id="additional-metadata-for-pushsecret">Additional Metadata for PushSecret</h4>
-<p>Optionally, it is possible to configure additional options for the parameter. These are as follows:
-- type
-- keyID
-- tier &amp; policies
-- encodeAsDecoded</p>
+<p>Optionally, it is possible to configure additional options for the parameter. These are as follows:</p>
+<ul>
+<li>type</li>
+<li>keyID</li>
+<li>tier &amp; policies</li>
+<li>encodeAsDecoded</li>
+</ul>
 <p>To control this behaviour you can set the following provider's <code>metadata</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/v1alpha1</span>
 <span class="nt">kind</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">PushSecret</span>

main/provider/aws-secrets-manager/index.html

@@ -5255,12 +5255,14 @@ a <code>path</code> prefix or use <code>Tags</code> filter.</p>
 <span class="w">        </span><span class="c1"># recoveryWindowInDays: 9 (conflicts with forceDeleteWithoutRecovery)</span>
 </code></pre></div>
 <h4 id="additional-metadata-for-pushsecret">Additional Metadata for PushSecret</h4>
-<p>Optionally, it is possible to configure additional options for the parameter. These are as follows:
-- kmsKeyID
-- secretPushFormat
-- description
-- tags
-- resourcePolicy</p>
+<p>Optionally, it is possible to configure additional options for the parameter. These are as follows:</p>
+<ul>
+<li>kmsKeyID</li>
+<li>secretPushFormat</li>
+<li>description</li>
+<li>tags</li>
+<li>resourcePolicy</li>
+</ul>
 <p>To control this behavior set the following provider metadata:</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/v1alpha1</span>
 <span class="nt">kind</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">PushSecret</span>

main/provider/barbican/index.html

@@ -5493,9 +5493,11 @@
 <li>Ensure the secret is in the correct project/tenant</li>
 </ol>
 <h3 id="network-connectivity">Network Connectivity</h3>
-<p>Ensure your Kubernetes cluster can reach:
-- The OpenStack Keystone endpoint (for authentication)
-- The Barbican service endpoint (for secret retrieval)</p>
+<p>Ensure your Kubernetes cluster can reach:</p>
+<ul>
+<li>The OpenStack Keystone endpoint (for authentication)</li>
+<li>The Barbican service endpoint (for secret retrieval)</li>
+</ul>
 <p>Check firewall rules and network policies that might block access.</p>
 
 

main/provider/doppler/index.html

@@ -5216,10 +5216,12 @@
 <span class="w">  </span><span class="nt">name</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">doppler-oidc-sa</span>
 <span class="w">  </span><span class="nt">namespace</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">external-secrets</span>
 </code></pre></div>
-<p>Next, create a Doppler Service Account Identity with:
-- <strong>Issuer</strong>: Your cluster's OIDC discovery URL
-- <strong>Audience</strong>: The resource-specific audience for the SecretStore (<code>secretStore:&lt;namespace&gt;:&lt;storeName&gt;</code> or <code>clusterSecretStore:&lt;storeName&gt;</code>), e.g. <code>secretStore:external-secrets:doppler-oidc-sa</code> or <code>clusterSecretStore:doppler-auth-api</code>
-- <strong>Subject</strong>: The Kubernetes ServiceAccount (<code>system:serviceaccount:&lt;serviceAccountNamespace&gt;:&lt;serviceAccountName&gt;</code>), e.g. <code>system:serviceaccount:external-secrets:doppler-oidc-sa</code></p>
+<p>Next, create a Doppler Service Account Identity with:</p>
+<ul>
+<li><strong>Issuer</strong>: Your cluster's OIDC discovery URL</li>
+<li><strong>Audience</strong>: The resource-specific audience for the SecretStore (<code>secretStore:&lt;namespace&gt;:&lt;storeName&gt;</code> or <code>clusterSecretStore:&lt;storeName&gt;</code>), e.g. <code>secretStore:external-secrets:doppler-oidc-sa</code> or <code>clusterSecretStore:doppler-auth-api</code></li>
+<li><strong>Subject</strong>: The Kubernetes ServiceAccount (<code>system:serviceaccount:&lt;serviceAccountNamespace&gt;:&lt;serviceAccountName&gt;</code>), e.g. <code>system:serviceaccount:external-secrets:doppler-oidc-sa</code></li>
+</ul>
 <p>Then configure the SecretStore:</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/v1</span>
 <span class="nt">kind</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">SecretStore</span>

main/provider/hashicorp-vault/index.html

@@ -6478,14 +6478,18 @@ and pick the best fit for your environment and Vault configuration.</p>
 <li><strong>Token Revocation</strong>: When tokens are evicted from the cache, they are properly revoked from Vault</li>
 </ul>
 <h4 id="when-to-use-token-caching">When to Use Token Caching</h4>
-<p>Token caching is beneficial when:
-- Using authentication methods that generate short-lived tokens (e.g., AppRole, Kubernetes auth)
-- Running multiple ExternalSecrets that use the same SecretStore
-- Experiencing high token generation overhead</p>
-<p>Token caching should <strong>not</strong> be used when:
-- Using static tokens (no performance benefit)
-- Security requirements mandate fresh tokens for each request
-- Memory usage is a concern</p>
+<p>Token caching is beneficial when:</p>
+<ul>
+<li>Using authentication methods that generate short-lived tokens (e.g., AppRole, Kubernetes auth)</li>
+<li>Running multiple ExternalSecrets that use the same SecretStore</li>
+<li>Experiencing high token generation overhead</li>
+</ul>
+<p>Token caching should <strong>not</strong> be used when:</p>
+<ul>
+<li>Using static tokens (no performance benefit)</li>
+<li>Security requirements mandate fresh tokens for each request</li>
+<li>Memory usage is a concern</li>
+</ul>
 <h4 id="read-your-writes">Read Your Writes</h4>
 <p>Vault 1.10.0 and later encodes information in the token to detect the case
 when a server is behind. If a Vault server does not have information about

main/provider/ibm-secrets-manager/index.html

@@ -5601,11 +5601,13 @@ Below example creates a kubernetes secret based on ID of the secret in Secrets M
 <h3 id="populating-the-kubernetes-secret-with-metadata-from-ibm-secrets-manager-provider">Populating the Kubernetes secret with metadata from IBM Secrets Manager Provider</h3>
 <p>ESO can add metadata while creating or updating a Kubernetes secret to be reflected in its labels or annotations. The metadata could be any of the fields that are supported and returned in the response by IBM Secrets Manager.</p>
 <p>In order for the user to opt in to adding metadata to secret, an existing optional field <code>spec.dataFrom.extract.metadataPolicy</code> can be set to <code>Fetch</code>, its default value being <code>None</code>. In addition to this, templating provided be ESO can be leveraged to specify the key-value pairs of the resultant secrets' labels and annotation.</p>
-<p>In order for the required metadata to be populated in the Kubernetes secret, combination of below should be provided in the External Secrets resource:
-1. The required metadata should be specified under <code>template.metadata.labels</code> or <code>template.metadata.annotations</code>.
-2. The required secret data should be specified under <code>template.data</code>.
-3. The spec.dataFrom.extract should be specified with details of the Secrets Manager secret with <code>spec.dataFrom.extract.metadataPolicy</code> set to <code>Fetch</code>.
-Below is an example, where <code>secret_id</code> and <code>updated_at</code> are the metadata of a secret in IBM Secrets Manager:</p>
+<p>In order for the required metadata to be populated in the Kubernetes secret, combination of below should be provided in the External Secrets resource:</p>
+<ol>
+<li>The required metadata should be specified under <code>template.metadata.labels</code> or <code>template.metadata.annotations</code>.</li>
+<li>The required secret data should be specified under <code>template.data</code>.</li>
+<li>The spec.dataFrom.extract should be specified with details of the Secrets Manager secret with <code>spec.dataFrom.extract.metadataPolicy</code> set to <code>Fetch</code>.
+Below is an example, where <code>secret_id</code> and <code>updated_at</code> are the metadata of a secret in IBM Secrets Manager:</li>
+</ol>
 <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/v1</span>
 <span class="nt">kind</span><span class="p">:</span><span class="w"> </span><span class="l l-Scalar l-Scalar-Plain">ExternalSecret</span>
 <span class="nt">metadata</span><span class="p">:</span>

main/provider/ovhcloud/index.html

@@ -5164,14 +5164,18 @@
 
 <h2 id="secrets-manager">Secrets Manager</h2>
 <p>External Secrets Operator integrates with <a href="https://www.ovhcloud.com/en/identity-security-operations/key-management-service/">OVHcloud KMS</a>.  </p>
-<p>This guide demonstrates:
-- how to set up a <code>ClusterSecretStore</code>/<code>SecretStore</code> with the OVH provider.
-- <code>ExternalSecret</code> use cases with examples.
-- <code>PushSecret</code> use cases with examples.</p>
-<p>This guide assumes:
-- External Secrets Operator is already installed
-- You have access to OVHcloud Secret Manager
-- Required credentials are already created</p>
+<p>This guide demonstrates:</p>
+<ul>
+<li>how to set up a <code>ClusterSecretStore</code>/<code>SecretStore</code> with the OVH provider.</li>
+<li><code>ExternalSecret</code> use cases with examples.</li>
+<li><code>PushSecret</code> use cases with examples.</li>
+</ul>
+<p>This guide assumes:</p>
+<ul>
+<li>External Secrets Operator is already installed</li>
+<li>You have access to OVHcloud Secret Manager</li>
+<li>Required credentials are already created</li>
+</ul>
 <h3 id="secretstore"><u>SecretStore</u></h3>
 <p><strong>OVH provider supports both <code>token</code> and <code>mTLS</code> authentication.</strong></p>
 <p>Token authentication:

main/provider/secretserver/index.html

@@ -5721,9 +5721,11 @@ secret (for push, delete, and existence checks). The <code>folderId</code> and <
 <code>folderId:&lt;id&gt;/&lt;name&gt;</code> format, a path-based key, or a numeric ID to ensure the correct secret is
 updated. Using a plain name will update the <strong>first match</strong> returned by the API.</p>
 <h4 id="deletion-behavior">Deletion Behavior</h4>
-<p>The <code>PushSecret</code> resource allows you to configure what happens to the remote secret in Secret Server when the <code>PushSecret</code> itself is deleted, via the <code>PushSecret.spec.deletionPolicy</code> field. Supported values are:
-- <code>Retain</code>: (Default) The remote secret is left intact in Secret Server when the <code>PushSecret</code> is deleted.
-- <code>Delete</code>: The provider will attempt to delete the remote secret from Secret Server when the <code>PushSecret</code> is removed.</p>
+<p>The <code>PushSecret</code> resource allows you to configure what happens to the remote secret in Secret Server when the <code>PushSecret</code> itself is deleted, via the <code>PushSecret.spec.deletionPolicy</code> field. Supported values are:</p>
+<ul>
+<li><code>Retain</code>: (Default) The remote secret is left intact in Secret Server when the <code>PushSecret</code> is deleted.</li>
+<li><code>Delete</code>: The provider will attempt to delete the remote secret from Secret Server when the <code>PushSecret</code> is removed.</li>
+</ul>
 <p>When <code>Delete</code> is specified, the deletion operation is idempotent; if the secret has already been removed or cannot be found, the provider will safely ignore the error and proceed.</p>
 <p><strong>Important:</strong> The deletion operation does <strong>not</strong> have access to <code>metadata</code>. If your Secret Server
 has multiple secrets with the same name in different folders and you use <code>deletionPolicy: Delete</code>,