Kubernetes Secrets are stored as Base64-encoded plaintext in etcd by default—not encrypted. Any user with role-based access control (RBAC) permissions on the API server can retrieve the raw values. To protect sensitive data at rest and in transit, use Key Management Service (KMS) to encrypt Secrets and follow the security best practices described in this topic.
Base64 encoding is not encryption. Treat Secrets as plaintext for all security planning purposes.
How Kubernetes handles sensitive data
Kubernetes provides two object types for storing data: Secret and ConfigMap. Both can be mounted to pods as files or environment variables. Use Secrets to store sensitive information such as database passwords, application certificates, and tokens. Use ConfigMaps for non-sensitive application configuration, such as startup parameters.
Secrets have the following security characteristics:
When a Secret creation request reaches the API server, the API server stores it as Base64-encoded plaintext in etcd.
Users with RBAC permissions can query the API server to retrieve the plaintext values.
After a Secret is mounted to a pod, its contents are stored in the node's tmpfs (temporary file system).
Security challenges
Using Secrets alone does not guarantee the security of sensitive data. Three common challenges arise:
Pre-deployment planning: Teams must agree on a security strategy for managing and storing sensitive information before deploying applications.
Key transmission security: Keeping reads, writes, and key transmissions secure without disrupting application access requires careful design.
Cloud provider tooling: Understanding which security solutions Alibaba Cloud provides—and how to integrate them—is not always obvious from the Kubernetes documentation alone.
Security solutions
Under the shared responsibility model for cloud security, Alibaba Cloud secures the control plane and provides tools for sensitive information management. On the application side, your team is responsible for using those tools correctly.
Use KMS for key lifecycle management
Key Management Service (KMS) provides professional key lifecycle management and data encryption/decryption services. Integrating KMS into your development and deployment pipeline eliminates the need to hard-code sensitive information in application templates, code repositories, or configuration files.
KMS also supports automatic key rotation, which reduces the risk of long-lived credentials being compromised and helps your organization meet security compliance requirements.
Use envelope encryption to protect your master key
Envelope encryption lets you encrypt and decrypt sensitive data offline on the application side—without sending your plaintext data to KMS. The mechanism works as follows:
| Component | Role |
|---|---|
| Content Encryption Key (CEK) | Encrypts the actual data locally |
| Key Encryption Key (KEK) | Stored in KMS; encrypts the CEK |
| Encrypted CEK | The only item exchanged with KMS—not the data itself |
This approach avoids uploading sensitive data to the cloud, resolves trust concerns in cloud computing scenarios, and reduces IT spending on data transmission in offline large-scale encryption workloads. For details, see Use envelope encryption to encrypt and decrypt local data.
Protecting the KEK (the "last key" problem)
The KEK itself must be protected. To do this:
Use Alibaba Cloud Resource Access Management (RAM) to control which identities can retrieve the KEK from KMS.
Apply the least privilege principle: grant only the minimum permissions required.
Use automatically rotated temporary tokens instead of long-lived RAM credentials.
Use an isolation mechanism such as RRSA to prevent applications from accessing RAM credentials they don't need.
Security best practices
Apply RBAC with least privilege
RBAC is the first line of defense for Secrets. Avoid issuing credentials with read and write permissions across all Secrets in a cluster. Revoke any credentials that may have been exposed.
Harden your supply chain
Sensitive information is used throughout the artifact lifecycle—from development and testing to build and deployment. To reduce exposure:
Prohibit hard-coding sensitive information in application templates, code repositories, and configuration files.
Use KMS to centrally manage keys across the entire artifact supply chain.
Build automated security inspection into each stage of the pipeline to detect potential data breaches before they reach production.
Audit and monitor key operations
All operations related to reading, writing, using, and managing keys must be audited and logged so that every access to sensitive data is traceable. Set up runtime monitoring with alert rules for:
Suspicious read and write operations on sensitive data
Breaches of Alibaba Cloud account AccessKey pairs
With logs and alerts in place, your operations team can quickly identify incidents, assess impact, and minimize losses.
Use temporary tokens and rotate keys
Avoid static credentials such as AccessKey pairs in application systems. Use temporary tokens instead: if an attacker gets a temporary token, the token expires before the attacker can escalate the attack, giving your team time to patch the vulnerability.
For keys stored in KMS, enable automatic key rotation or set a schedule for periodic manual rotation to reduce the impact of any single key being compromised.
Encrypt Kubernetes Secrets and ConfigMaps with KMS
If you store sensitive information in Kubernetes Secrets or ConfigMaps, encrypt it with KMS. Decrypt on demand based on your application's access pattern.
Prefer envelope encryption for large-scale or offline scenarios
Direct KMS encryption sends every plaintext item to KMS for processing. Envelope encryption keeps data local and only exchanges encrypted keys, reducing latency, cost, and cloud dependency. Use envelope encryption when:
Encrypting large volumes of data offline
Minimizing KMS API calls for cost or performance reasons
Your security policy requires data to remain on-premises