Base64 Isn't Encryption: Why Kubernetes Secrets Pass Right Through, and the RBAC Design Traps That Make It Worse

Have you ever run 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.

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.

1. The Truth Behind "It's Encrypted" — What Base64 and etcd Actually Do

When you dump a Kubernetes Secret resource as a manifest, the values in the 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 echo <value> | base64 -d instantly reverses it back to plaintext.

The 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 --encryption-provider-config flag, the 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.

As a 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.

Encryption Options in K3s

K3s, a lightweight Kubernetes distribution, makes this easier to fix. As documented in the official K3s docs, simply passing the --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.

2. Over-Permissioned RBAC Causes Real Incidents — Designing get/list/watch Permission Scope

Another pitfall in Secrets management is RBAC (Role-Based Access Control) permission scope. According to the 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 get, list, or watch permissions you've already granted.

Underestimating this characteristic produces incident patterns like these:

• Permission sprawl via Service Accounts: If a Service Account attached to a Pod is granted list access to Secrets through a ClusterRole, every container and CI/CD job running in that Pod can read every Secret in the entire cluster
• Namespace boundaries become meaningless: You might assume namespace isolation keeps you safe, but a ClusterRoleBinding that grants cross-namespace access renders that boundary irrelevant
• Careless use of wildcards: Specifying resources: ["*"] or verbs: ["*"] grants access to resources you never intended to expose

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/CD pipeline.

3. Practical Countermeasures — etcd Encryption, External Secrets Operator, and CSI Secrets Store

Measures to secure Secrets management can be organized into three broad tiers, based on the tradeoff between implementation cost and effectiveness.

Measure 1: etcd Encryption at Rest (Minimal Cost)

This involves configuring 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.

Measure 2: External Secrets Operator for Vault/Cloud Integration

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 SecretStore defines the access method and ExternalSecret defines what to retrieve, cleanly separates the concerns of "where from" and "what." As the official HashiCorp Vault tutorial notes, centralizing access policy and audit logging in Vault significantly reduces the operational burden of rotation and revocation.

Measure 3: CSI Secrets Store Driver (Don't Create Secret Objects At All)

For environments with higher security requirements, the Secrets Store CSI Driver is worth considering. It uses a Custom Resource called 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.

4. A Secrets and RBAC Checklist for K3s / Managed Operations

Before going to production, we recommend confirming at least these four items:

1. Encryption configuration: Is EncryptionConfiguration (or K3s's --secrets-encryption) enabled?
2. Audit logging: Is get/list access to Secrets recorded in audit logs and traceable?
3. Rotation: Is periodic rotation of encryption keys and Secrets themselves built into your process?
4. Permission audits: Are Service Accounts, RoleBindings, and ClusterRoleBindings scoped to least privilege, and reviewed regularly?

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 Kubo, you start from a foundation where these security settings are already in place.

Kubo's 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.

Summary

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.

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 Kubo On-Premise, which gives you full control on your own infrastructure. Start by reaching out to us to revisit your current Secrets and RBAC design.