<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Secret Management on SL Notebook</title><link>https://slnotes.blog.castrillon.ch/k8s/secretmanagement/</link><description>Recent content in Secret Management on SL Notebook</description><generator>Hugo -- gohugo.io</generator><lastBuildDate>Sat, 12 Sep 2026 11:08:59 +0200</lastBuildDate><atom:link href="https://slnotes.blog.castrillon.ch/k8s/secretmanagement/index.xml" rel="self" type="application/rss+xml"/><item><title>Encryption at Rest</title><link>https://slnotes.blog.castrillon.ch/k8s/secretmanagement/enc_at_rest/</link><pubDate>Sat, 12 Sep 2026 11:08:59 +0200</pubDate><guid>https://slnotes.blog.castrillon.ch/k8s/secretmanagement/enc_at_rest/</guid><description>When dealing with Kubernetes secrets, the values are not only stored in the definitions used to create the resources. Critically, they are also stored in the etcd store that the cluster uses for configuration.
By default, secret values in this store can just be read directly which is a vulnerability.
K8s offers a process to encrypt these values: https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/
THis process involves:
Creating an EncryptionConfiguration object In here it can be determined: WHich resources to encrypt at rest (e.</description></item></channel></rss>