[{"data":1,"prerenderedAt":474},["ShallowReactive",2],{"blog-en-kubernetes-secrets-rbac-etcd-encryption":3,"blog-related-en-kubernetes-secrets-rbac-etcd-encryption":423,"blog-en-kubernetes-secrets-rbac-etcd-encryption-alt":411},{"id":4,"title":5,"author":6,"body":7,"date":405,"description":406,"extension":407,"image":408,"locale":409,"meta":410,"navigation":411,"path":412,"seo":413,"stem":414,"tags":415,"__hash__":422},"blog\u002Fblog\u002Fen\u002Fkubernetes-secrets-rbac-etcd-encryption.md","Base64 Isn't Encryption: Why Kubernetes Secrets Pass Right Through, and the RBAC Design Traps That Make It Worse","Kubo Team",{"type":8,"value":9,"toc":389},"minimark",[10,19,22,27,38,57,66,71,84,91,95,116,119,153,161,167,171,174,178,185,189,211,215,228,295,301,305,308,344,353,361,367,371,374],[11,12,13,14,18],"p",{},"Have you ever run ",[15,16,17],"code",{},"kubectl get secret -o yaml",", seen the values displayed as Base64 strings, and thought \"that's encrypted, so it's safe\"? That assumption is a major misconception. By default, Kubernetes Secrets management only applies Base64 encoding — no encryption happens at all. Anyone with access to etcd, or anyone operating in a cluster with loose RBAC permission design, can decode those values in seconds and pull out plaintext credentials.",[11,20,21],{},"This article explains why the \"Base64 equals encryption\" myth persists, how sloppy RBAC permission scoping leads to real incidents, and the concrete steps you need to take to secure Secrets management in a production K3s environment.",[23,24,26],"h2",{"id":25},"_1-the-truth-behind-its-encrypted-what-base64-and-etcd-actually-do","1. The Truth Behind \"It's Encrypted\" — What Base64 and etcd Actually Do",[11,28,29,30,33,34,37],{},"When you dump a Kubernetes Secret resource as a manifest, the values in the ",[15,31,32],{},"data"," field appear as Base64 strings. That appearance leads no small number of engineers to assume the data is \"obfuscated\" or \"already encrypted.\" But Base64 is an encoding scheme, not encryption. Decoding it requires no key whatsoever — a single ",[15,35,36],{},"echo \u003Cvalue> | base64 -d"," instantly reverses it back to plaintext.",[11,39,40,41,48,49,52,53,56],{},"The ",[42,43,47],"a",{"href":44,"rel":45},"https:\u002F\u002Fkubernetes.io\u002Fdocs\u002Ftasks\u002Fadminister-cluster\u002Fencrypt-data\u002F",[46],"nofollow","official Kubernetes documentation"," is explicit on this point: by default, sensitive data such as Secrets and ConfigMaps is stored in etcd without encryption. Unless you pass encryption configuration to the Kubernetes API server via the ",[15,50,51],{},"--encryption-provider-config"," flag, the ",[15,54,55],{},"identity"," provider — which is effectively no encryption at all — remains in effect. In other words, in any cluster where this hasn't been configured, anyone with access to etcd's backup files or snapshots can read the contents of your Secrets as-is.",[11,58,59,60,65],{},"As a ",[42,61,64],{"href":62,"rel":63},"https:\u002F\u002Fdev.classmethod.jp\u002Farticles\u002Fk8s_secret\u002F",[46],"DevelopersIO article"," also points out, this all comes down to one fact: anyone with read permission can decode the data and retrieve it in plaintext. Teams that conflate encoding with encryption often don't discover the problem until it surfaces during an audit or a third-party security review.",[67,68,70],"h3",{"id":69},"encryption-options-in-k3s","Encryption Options in K3s",[11,72,73,74,79,80,83],{},"K3s, a lightweight Kubernetes distribution, makes this easier to fix. As documented in the ",[42,75,78],{"href":76,"rel":77},"https:\u002F\u002Fdocs.k3s.io\u002Fsecurity\u002Fsecrets-encryption",[46],"official K3s docs",", simply passing the ",[15,81,82],{},"--secrets-encryption"," flag at server startup automatically encrypts Secrets stored in etcd. An AES-CBC encryption key is generated automatically, and the encryption configuration file is passed to the Kube-APIServer. Note, though, that enabling this on an existing server after the fact requires a restart.",[11,85,86],{},[87,88],"img",{"alt":89,"src":90},"section01","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fkubernetes-secrets-rbac-etcd-encryption\u002Fsection01.webp",[23,92,94],{"id":93},"_2-over-permissioned-rbac-causes-real-incidents-designing-getlistwatch-permission-scope","2. Over-Permissioned RBAC Causes Real Incidents — Designing get\u002Flist\u002Fwatch Permission Scope",[11,96,97,98,103,104,107,108,111,112,115],{},"Another pitfall in Secrets management is RBAC (Role-Based Access Control) permission scope. According to the ",[42,99,102],{"href":100,"rel":101},"https:\u002F\u002Fkubernetes.io\u002Fdocs\u002Freference\u002Faccess-authn-authz\u002Frbac\u002F",[46],"official Kubernetes RBAC documentation",", RBAC is built from four object types — Role, ClusterRole, RoleBinding, and ClusterRoleBinding — and permissions can only be granted additively. There is no \"deny rule\" that lets you later partially revoke ",[15,105,106],{},"get",", ",[15,109,110],{},"list",", or ",[15,113,114],{},"watch"," permissions you've already granted.",[11,117,118],{},"Underestimating this characteristic produces incident patterns like these:",[120,121,122,133,139],"ul",{},[123,124,125,129,130,132],"li",{},[126,127,128],"strong",{},"Permission sprawl via Service Accounts",": If a Service Account attached to a Pod is granted ",[15,131,110],{}," access to Secrets through a ClusterRole, every container and CI\u002FCD job running in that Pod can read every Secret in the entire cluster",[123,134,135,138],{},[126,136,137],{},"Namespace boundaries become meaningless",": You might assume namespace isolation keeps you safe, but a ClusterRoleBinding that grants cross-namespace access renders that boundary irrelevant",[123,140,141,144,145,148,149,152],{},[126,142,143],{},"Careless use of wildcards",": Specifying ",[15,146,147],{},"resources: [\"*\"]"," or ",[15,150,151],{},"verbs: [\"*\"]"," grants access to resources you never intended to expose",[11,154,155,160],{},[42,156,159],{"href":157,"rel":158},"https:\u002F\u002Fwww.wiz.io\u002Facademy\u002Fcontainer-security\u002Fkubernetes-rbac-best-practices",[46],"Wiz's container security guide"," repeatedly emphasizes enforcing the principle of least privilege, avoiding wildcards, and regularly auditing permissions. RBAC isn't something you configure once and forget — it's an ongoing operational responsibility that needs revisiting every time you add a new Service Account or CI\u002FCD pipeline.",[11,162,163],{},[87,164],{"alt":165,"src":166},"section02","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fkubernetes-secrets-rbac-etcd-encryption\u002Fsection02.webp",[23,168,170],{"id":169},"_3-practical-countermeasures-etcd-encryption-external-secrets-operator-and-csi-secrets-store","3. Practical Countermeasures — etcd Encryption, External Secrets Operator, and CSI Secrets Store",[11,172,173],{},"Measures to secure Secrets management can be organized into three broad tiers, based on the tradeoff between implementation cost and effectiveness.",[67,175,177],{"id":176},"measure-1-etcd-encryption-at-rest-minimal-cost","Measure 1: etcd Encryption at Rest (Minimal Cost)",[11,179,180,181,184],{},"This involves configuring ",[15,182,183],{},"EncryptionConfiguration"," and enabling at-rest encryption for etcd using AES-GCM or a KMS provider. It can be introduced without major changes to your existing cluster setup, making it the baseline measure every team should implement first.",[67,186,188],{"id":187},"measure-2-external-secrets-operator-for-vaultcloud-integration","Measure 2: External Secrets Operator for Vault\u002FCloud Integration",[11,190,191,196,197,200,201,204,205,210],{},[42,192,195],{"href":193,"rel":194},"https:\u002F\u002Fexternal-secrets.io\u002Flatest\u002Fintroduction\u002Foverview\u002F",[46],"External Secrets Operator (ESO)"," is a tool that retrieves credentials from external systems — HashiCorp Vault or a cloud provider's secrets manager — and automatically syncs them as Kubernetes Secrets. Its division of responsibilities, where ",[15,198,199],{},"SecretStore"," defines the access method and ",[15,202,203],{},"ExternalSecret"," defines what to retrieve, cleanly separates the concerns of \"where from\" and \"what.\" As the ",[42,206,209],{"href":207,"rel":208},"https:\u002F\u002Fdeveloper.hashicorp.com\u002Fvault\u002Ftutorials\u002Fkubernetes-introduction\u002Fkubernetes-external-vault",[46],"official HashiCorp Vault tutorial"," notes, centralizing access policy and audit logging in Vault significantly reduces the operational burden of rotation and revocation.",[67,212,214],{"id":213},"measure-3-csi-secrets-store-driver-dont-create-secret-objects-at-all","Measure 3: CSI Secrets Store Driver (Don't Create Secret Objects At All)",[11,216,217,218,223,224,227],{},"For environments with higher security requirements, the ",[42,219,222],{"href":220,"rel":221},"https:\u002F\u002Fsecrets-store-csi-driver.sigs.k8s.io\u002F",[46],"Secrets Store CSI Driver"," is worth considering. It uses a Custom Resource called ",[15,225,226],{},"SecretProviderClass"," to mount values from an external secrets store directly into a Pod's filesystem as a volume — without ever creating a Kubernetes Secret object. Because the Secret object never exists in etcd, the Base64 problem described above simply doesn't apply.",[229,230,231,250],"table",{},[232,233,234],"thead",{},[235,236,237,241,244,247],"tr",{},[238,239,240],"th",{},"Measure",[238,242,243],{},"Implementation Cost",[238,245,246],{},"Effectiveness",[238,248,249],{},"Best Fit",[251,252,253,268,281],"tbody",{},[235,254,255,259,262,265],{},[256,257,258],"td",{},"etcd Encryption at Rest",[256,260,261],{},"Low",[256,263,264],{},"Medium",[256,266,267],{},"The baseline every team should implement first",[235,269,270,273,275,278],{},[256,271,272],{},"External Secrets Operator",[256,274,264],{},[256,276,277],{},"High",[256,279,280],{},"Organizations already running Vault or similar",[235,282,283,286,289,292],{},[256,284,285],{},"CSI Secrets Store Driver",[256,287,288],{},"Medium–High",[256,290,291],{},"Highest",[256,293,294],{},"Environments handling private keys or regulated credentials",[11,296,297],{},[87,298],{"alt":299,"src":300},"section03","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fkubernetes-secrets-rbac-etcd-encryption\u002Fsection03.webp",[23,302,304],{"id":303},"_4-a-secrets-and-rbac-checklist-for-k3s-managed-operations","4. A Secrets and RBAC Checklist for K3s \u002F Managed Operations",[11,306,307],{},"Before going to production, we recommend confirming at least these four items:",[309,310,311,320,332,338],"ol",{},[123,312,313,316,317,319],{},[126,314,315],{},"Encryption configuration",": Is EncryptionConfiguration (or K3s's ",[15,318,82],{},") enabled?",[123,321,322,325,326,328,329,331],{},[126,323,324],{},"Audit logging",": Is ",[15,327,106],{},"\u002F",[15,330,110],{}," access to Secrets recorded in audit logs and traceable?",[123,333,334,337],{},[126,335,336],{},"Rotation",": Is periodic rotation of encryption keys and Secrets themselves built into your process?",[123,339,340,343],{},[126,341,342],{},"Permission audits",": Are Service Accounts, RoleBindings, and ClusterRoleBindings scoped to least privilege, and reviewed regularly?",[11,345,346,347,352],{},"Building and operating all of this from scratch on your own doesn't just add to your initial cluster setup cost — it places an ongoing monitoring and audit burden on your infrastructure team. Do you really want to build this from zero every time? With a managed K3s environment like ",[42,348,351],{"href":349,"rel":350},"https:\u002F\u002Fkubo.hexabase.io\u002F",[46],"Kubo",", you start from a foundation where these security settings are already in place.",[11,354,355,356,360],{},"Kubo's ",[42,357,359],{"href":349,"rel":358},[46],"Captain UI"," makes permission settings and cluster configuration visible rather than a black box, which helps address the common problem of RBAC audits depending entirely on a single person's institutional knowledge. Compared to building and operating EKS or AKS entirely on your own, a lightweight K3s-based setup lets you establish a cost-efficient foundation for security operations.",[11,362,363],{},[87,364],{"alt":365,"src":366},"section04","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fkubernetes-secrets-rbac-etcd-encryption\u002Fsection04.webp",[23,368,370],{"id":369},"summary","Summary",[11,372,373],{},"Kubernetes Secrets are only Base64-encoded — not encrypted. Under default settings, anyone with access to etcd, or anyone operating within a cluster with loosely designed RBAC permissions, can read sensitive data. Countermeasures fall into three tiers — etcd encryption, External Secrets Operator, and CSI Secrets Store Driver — that can be adopted incrementally based on the cost-effectiveness tradeoff that fits your organization.",[11,375,376,377,382,383,388],{},"This matters especially for organizations in regulated industries like finance and healthcare, where data sovereignty and air-gapped operation are often required. The burden of building and auditing Secrets management and RBAC design entirely from scratch is not small. As your next step toward a production-ready foundation, it's worth considering a managed K3s environment like ",[42,378,381],{"href":379,"rel":380},"https:\u002F\u002Fwww.hexabase.com\u002Fproduct\u002Fkubo\u002Fon-premise",[46],"Kubo On-Premise",", which gives you full control on your own infrastructure. Start by ",[42,384,387],{"href":385,"rel":386},"https:\u002F\u002Fwww.hexabase.com\u002Fcontact-us\u002F",[46],"reaching out to us"," to revisit your current Secrets and RBAC design.",{"title":390,"searchDepth":391,"depth":391,"links":392},"",2,[393,397,398,403,404],{"id":25,"depth":391,"text":26,"children":394},[395],{"id":69,"depth":396,"text":70},3,{"id":93,"depth":391,"text":94},{"id":169,"depth":391,"text":170,"children":399},[400,401,402],{"id":176,"depth":396,"text":177},{"id":187,"depth":396,"text":188},{"id":213,"depth":396,"text":214},{"id":303,"depth":391,"text":304},{"id":369,"depth":391,"text":370},"2026-07-29","Kubernetes Secrets are only Base64-encoded, not encrypted. Learn how plaintext-equivalent storage in etcd and over-permissioned RBAC lead to real incidents, plus the concrete Secrets management practices you need for production K3s.","md","https:\u002F\u002Fcdn.kubo.hexabase.io\u002Fimages\u002Fblog\u002Fkubernetes-secrets-rbac-etcd-encryption\u002Feyecatch.webp","en",{},true,"\u002Fblog\u002Fen\u002Fkubernetes-secrets-rbac-etcd-encryption",{"title":5,"description":406},"blog\u002Fen\u002Fkubernetes-secrets-rbac-etcd-encryption",[416,417,418,419,420,421],"kubernetes","k3s","secrets-management","rbac","security","etcd-encryption","3i3z51HJgVsH-71Iu3rqaEq7WyTKOB-YkCJvqHEIZhw",[424,432,440,448,457,466],{"path":425,"title":426,"description":427,"date":428,"tags":429},"\u002Fblog\u002Fen\u002Fkubernetes-certificate-management-cert-manager-process-debt","The Cert Renewal Took One Line of Code and Two Months of Meetings: Why Kubernetes Certificate Management Is a Process Problem, Not a Technical One","Kubernetes certificate management is technically a matter of days. What actually takes time is the organizational process of getting sign-off. Here's how cert-manager automates the technical side, and how to design away the operational debt that remains.","2026-08-09",[417,416,430,431,420],"cert-manager","tls",{"path":433,"title":434,"description":435,"date":436,"tags":437},"\u002Fblog\u002Fen\u002Fai-agent-sandbox-kata-containers-kubernetes","AI Agent Code Isn't a \"Trusted Product\" Anymore. Kubernetes Sandbox Design Has an Answer","Code generated and executed by AI agents can no longer be treated as a trusted, reviewed product. This article explains the limits of container isolation and why Kata Containers' microVM isolation is becoming essential when designing AI agent sandboxes on Kubernetes.","2026-08-08",[417,416,438,439,420],"kata-containers","ai-agent",{"path":441,"title":442,"description":443,"date":444,"tags":445},"\u002Fblog\u002Fen\u002Fkubernetes-image-signing-sigstore-supply-chain","Anyone Can Rewrite an Image Tag. Why Kubernetes Needs Sigstore-Backed Signing to Prove Provenance","Container image signing explained: tags can be overwritten by anyone, and passing CI tests doesn't guarantee the image running in production is the one you built. Learn how Sigstore and Kyverno work together to reject unsigned images on Kubernetes\u002FK3s, integrated into a GitOps workflow.","2026-08-06",[417,416,446,447,420],"ci-cd","gitops",{"path":449,"title":450,"description":451,"date":452,"tags":453},"\u002Fblog\u002Fen\u002Fshadow-ai-kubernetes-admission-control-governance","Rogue Deployments Are Wrecking Your Company: The Shadow AI Problem Inside Kubernetes Clusters, and Admission Control as the Fix","Shadow AI isn't just unauthorized SaaS tools. It's happening inside your Kubernetes clusters too. Here's the risk it creates, and how Admission Control turns detection into real governance.","2026-07-17",[416,417,454,455,456,420],"shadow-ai","admission-control","kyverno",{"path":458,"title":459,"description":460,"date":461,"tags":462},"\u002Fblog\u002Fen\u002Fkubernetes-v136-k3s-managed-cost-reduction","Managed Kubernetes is Too Expensive. The Reality of 'Full K8s Operations Under $400\u002FMonth' with K3s Lightweight and v1.36 Security Enhancements","Explore how to leverage Kubernetes v1.36 'Haru' enhanced User Namespaces and security features in K3s lightweight environments. Discover managed K3s operational strategies and 2026 infrastructure selection guidelines that achieve 60% cost reduction compared to EKS.","2026-05-28",[417,416,463,464,465,420],"kubernetes-v136","managed-kubernetes","cost-optimization",{"path":467,"title":468,"description":469,"date":470,"tags":471},"\u002Fblog\u002Fen\u002Fkubevirt-calico-live-migration-networking","Moving a VM Doesn't Have to Break the Connection: Inside KubeVirt and Calico's Live Migration Magic","Why doesn't live migrating a VM (KubeVirt) between Kubernetes nodes break the connection? We break down Calico's IP persistence and BGP route convergence, and what it means for teams moving off VMware.","2026-08-07",[417,416,472,473,464],"kubevirt","networking",1786354655821]