<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Gitops on Le Site de François</title><link>https://lesitedefrancois.be/en/tags/gitops/</link><description>Recent content in Gitops on Le Site de François</description><generator>Hugo -- gohugo.io</generator><language>en</language><copyright>© 2026 François</copyright><atom:link href="https://lesitedefrancois.be/en/tags/gitops/index.xml" rel="self" type="application/rss+xml"/><item><title>ESO (External Secrets Operator)</title><link>https://lesitedefrancois.be/en/security/eso/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://lesitedefrancois.be/en/security/eso/</guid><description>&lt;p&gt;&lt;strong&gt;External Secrets Operator (ESO)&lt;/strong&gt; is a CNCF incubating project that bridges the gap between Kubernetes-native secrets and enterprise secret management backends. Its premise is that native Kubernetes Secrets — base64-encoded values stored in etcd — are not adequate as a primary secret store: they offer no encryption at rest by default, no access audit trail, no versioning or rotation lifecycle, and no single source of truth across multiple clusters. Rather than replacing Kubernetes Secrets as a consumption mechanism (applications still mount them as environment variables or files in the familiar way), ESO replaces etcd as their &lt;em&gt;source of authority&lt;/em&gt;, pulling the real values from a backend that does provide those properties and keeping the Kubernetes Secret as a synchronised, ephemeral projection.&lt;/p&gt;</description></item><item><title>Sealed Secrets</title><link>https://lesitedefrancois.be/en/security/sealed-secrets/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://lesitedefrancois.be/en/security/sealed-secrets/</guid><description>&lt;p&gt;&lt;strong&gt;Sealed Secrets&lt;/strong&gt; is a Kubernetes controller and companion CLI tool (&lt;code&gt;kubeseal&lt;/code&gt;) created by Bitnami that solves a specific GitOps problem: how to store Kubernetes Secret manifests in a Git repository without exposing their contents. A standard Kubernetes Secret is base64-encoded, not encrypted — anyone who can read the manifest file or the Git history can decode the values instantly. Sealed Secrets resolves this by encrypting the secret values using asymmetric cryptography before they ever leave the developer&amp;rsquo;s machine, producing a &lt;code&gt;SealedSecret&lt;/code&gt; custom resource that contains only ciphertext and is safe to commit to any repository, public or private. The corresponding plaintext Secret is materialised exclusively inside the cluster by the controller, which holds the only private key capable of decryption.&lt;/p&gt;</description></item></channel></rss>