<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Kms on Le Site de François</title><link>https://lesitedefrancois.be/en/tags/kms/</link><description>Recent content in Kms 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/kms/index.xml" rel="self" type="application/rss+xml"/><item><title>KMS v2 (Kubernetes KMS Provider v2)</title><link>https://lesitedefrancois.be/en/security/kmsv2/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://lesitedefrancois.be/en/security/kmsv2/</guid><description>&lt;p&gt;&lt;strong&gt;KMS v2 (Kubernetes KMS Provider version 2)&lt;/strong&gt; is the stable (GA since Kubernetes 1.29, KMS v1 deprecated in 1.28 and disabled by default in 1.29) mechanism for encrypting the contents of the Kubernetes etcd datastore at rest using an external key management service. Without encryption, Kubernetes Secrets stored in etcd are base64-encoded — trivially decodable by anyone with read access to the etcd data files or a snapshot. With KMS v2 enabled, resources written to etcd — Secrets, ConfigMaps, and any other API objects selected by the &lt;code&gt;EncryptionConfiguration&lt;/code&gt; — are encrypted before being persisted, using a unique per-object key derived locally. The &lt;strong&gt;envelope encryption&lt;/strong&gt; scheme means those per-object keys are never stored in plaintext: only their encrypted form lives in etcd, and only the external KMS holds the wrapping key. The encryption configuration is declared in a file referenced by the API server&amp;rsquo;s &lt;code&gt;--encryption-provider-config&lt;/code&gt; flag, with &lt;code&gt;kms: apiVersion: v2&lt;/code&gt; selecting the KMS v2 code path, and &lt;code&gt;endpoint: unix:///path/to/plugin.sock&lt;/code&gt; pointing at the plugin&amp;rsquo;s Unix domain socket.&lt;/p&gt;</description></item><item><title>Storage Encryption</title><link>https://lesitedefrancois.be/en/security/storage-encryption/</link><pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate><guid>https://lesitedefrancois.be/en/security/storage-encryption/</guid><description>&lt;p&gt;Storage encryption is not a single feature but a &lt;strong&gt;four-layer decision&lt;/strong&gt; that must be made independently, because each layer addresses a different adversary and a different failure mode. &lt;strong&gt;Layer 1 — disk/OSD at-rest encryption&lt;/strong&gt; protects against physical media theft: a decommissioned OSD or stolen drive is unreadable without the key. &lt;strong&gt;Layer 2 — cluster-internal wire encryption&lt;/strong&gt; protects against a network-layer attacker who can observe traffic between storage nodes: OSDs, monitors, and clients on the cluster network. &lt;strong&gt;Layer 3 — PV/volume-level encryption&lt;/strong&gt; protects against a storage operator or another tenant reading a workload&amp;rsquo;s data through the storage system itself — the threat model where the storage cluster is itself potentially untrusted or multi-tenant. &lt;strong&gt;Layer 4 — object storage server-side encryption&lt;/strong&gt; provides per-object key management for S3-compatible workloads, enabling customer-managed keys (CMK) and per-tenant key isolation in object stores. These layers are &lt;strong&gt;independent and composable&lt;/strong&gt;: enabling Layer 1 without Layer 2 protects against physical theft but not a network interceptor; enabling Layer 3 without Layer 1 protects against the storage operator but not physical media extraction. A complete encryption posture addresses all four explicitly, even if some layers are deliberately left disabled with a documented rationale.&lt;/p&gt;</description></item></channel></rss>