Advanced Guide to Kubernetes Secrets and ConfigMaps

Kubernetes Secrets are a fundamental component of secure configuration management in containerized environments. Secrets provide a built-in solution for storing and managing sensitive data such as passwords, OAuth tokens, and SSH keys, ensuring they remain protected while being accessible to the applications that need them. In Kubernetes deployments, proper configuration management is essential for maintaining security, reliability, and scalability. Kubernetes Secrets offer a standardized approach to handle confidential data, separating sensitive information from application code and container images. This separation is crucial for maintaining security best practices and preventing the exposure of sensitive data during the development and deployment lifecycle. Unlike ConfigMaps, which are designed for non-sensitive configuration data, Kubernetes Secrets are specifically intended for confidential information. They provide mechanisms for encrypting data at rest, controlling access through role-based access control, and managing the lifecycle of sensitive information independently from the applications that consume it. What are Kubernetes Secrets? Kubernetes Secrets are objects that contain a small amount of sensitive data. This data is stored in the Kubernetes API server’s underlying data store (etcd) and can be mounted as files in pods or exposed as environment variables to containers. By using Secrets, developers can avoid hardcoding sensitive information directly into their application code or storing it in container images, which could lead to security vulnerabilities. What are ConfigMaps? ConfigMaps are similar to Secrets but are designed for non-confidential configuration data. While Secrets and ConfigMaps share many similarities in terms of how they’re created and consumed by applications, the key difference lies in their intended purpose. ConfigMaps are meant for configuration parameters like application settings, configuration files, and command-line arguments, whereas Kubernetes Secrets are specifically for sensitive data that requires additional security measures. The role of Kubernetes Secrets in cloud-native applications In cloud-native applications, Kubernetes Secrets play a pivotal role in managing sensitive information securely. These applications often consist of microservices deployed as containers orchestrated by Kubernetes, where secure configuration becomes critical — especially in API development, where services must authenticate with internal or external APIs using tokens or keys. Kubernetes Secrets integrate seamlessly with the cloud-native ecosystem, providing a standardized way to handle sensitive data across distributed microservices. When applications are broken down into smaller services, each service might require access to various credentials, tokens, or keys. Kubernetes Secrets solve this problem by centralizing the management of sensitive data while making it accessible to the services that need it. One of the key benefits of using Kubernetes Secrets is the ability to update secrets independently from application deployments. When credentials need to be rotated or updated, you can modify the Secret without rebuilding or redeploying the application containers. This separation simplifies operational tasks and enhances security by enabling more frequent credential rotation. Kubernetes secret types Kubernetes Secrets come in various types, each designed for specific use cases and with different validation requirements. Understanding these different types helps in implementing the right security solution for your specific needs. The most common type of Secret is the Opaque type, which is the default if no type is specified. Opaque Secrets allow storing arbitrary user-defined data without any specific structure or validation. This flexibility makes them suitable for a wide range of use cases, from storing simple passwords to complex configuration data. Transport Layer Security (TLS) Secrets are specifically designed for storing TLS certificates and private keys. These Secrets are commonly used for securing communication between services or exposing applications outside the cluster via HTTPS. Kubernetes validates that the Secret contains the required keys: tls.crt for the certificate and tls.key for the private key. Docker registry Secrets, with types kubernetes.io/dockercfg and kubernetes.io/dockerconfigjson, store authentication information for private container registries. These Secrets enable Kubernetes to pull images from private repositories during pod creation. Service account token Secrets contain tokens that identify service accounts within the Kubernetes cluster. These tokens are used for authentication and authorization when pods need to interact with the Kubernetes API. Key differences: when to use Secrets vs. ConfigMaps When designing Kubernetes applications, developers often face the decision of whether to use Kuber

Apr 17, 2025 - 07:11

Advanced Guide to Kubernetes Secrets and ConfigMaps

Kubernetes Secrets are a fundamental component of secure configuration management in containerized environments. Secrets provide a built-in solution for storing and managing sensitive data such as passwords, OAuth tokens, and SSH keys, ensuring they remain protected while being accessible to the applications that need them.

In Kubernetes deployments, proper configuration management is essential for maintaining security, reliability, and scalability. Kubernetes Secrets offer a standardized approach to handle confidential data, separating sensitive information from application code and container images. This separation is crucial for maintaining security best practices and preventing the exposure of sensitive data during the development and deployment lifecycle.

Unlike ConfigMaps, which are designed for non-sensitive configuration data, Kubernetes Secrets are specifically intended for confidential information. They provide mechanisms for encrypting data at rest, controlling access through role-based access control, and managing the lifecycle of sensitive information independently from the applications that consume it.

What are Kubernetes Secrets?

Kubernetes Secrets are objects that contain a small amount of sensitive data. This data is stored in the Kubernetes API server’s underlying data store (etcd) and can be mounted as files in pods or exposed as environment variables to containers. By using Secrets, developers can avoid hardcoding sensitive information directly into their application code or storing it in container images, which could lead to security vulnerabilities.

What are ConfigMaps?

ConfigMaps are similar to Secrets but are designed for non-confidential configuration data. While Secrets and ConfigMaps share many similarities in terms of how they’re created and consumed by applications, the key difference lies in their intended purpose. ConfigMaps are meant for configuration parameters like application settings, configuration files, and command-line arguments, whereas Kubernetes Secrets are specifically for sensitive data that requires additional security measures.

The role of Kubernetes Secrets in cloud-native applications
In cloud-native applications, Kubernetes Secrets play a pivotal role in managing sensitive information securely. These applications often consist of microservices deployed as containers orchestrated by Kubernetes, where secure configuration becomes critical — especially in API development, where services must authenticate with internal or external APIs using tokens or keys.

Kubernetes Secrets integrate seamlessly with the cloud-native ecosystem, providing a standardized way to handle sensitive data across distributed microservices. When applications are broken down into smaller services, each service might require access to various credentials, tokens, or keys. Kubernetes Secrets solve this problem by centralizing the management of sensitive data while making it accessible to the services that need it.

One of the key benefits of using Kubernetes Secrets is the ability to update secrets independently from application deployments. When credentials need to be rotated or updated, you can modify the Secret without rebuilding or redeploying the application containers. This separation simplifies operational tasks and enhances security by enabling more frequent credential rotation.

Kubernetes secret types

Kubernetes Secrets come in various types, each designed for specific use cases and with different validation requirements. Understanding these different types helps in implementing the right security solution for your specific needs.

The most common type of Secret is the Opaque type, which is the default if no type is specified. Opaque Secrets allow storing arbitrary user-defined data without any specific structure or validation. This flexibility makes them suitable for a wide range of use cases, from storing simple passwords to complex configuration data.

Transport Layer Security (TLS) Secrets are specifically designed for storing TLS certificates and private keys. These Secrets are commonly used for securing communication between services or exposing applications outside the cluster via HTTPS. Kubernetes validates that the Secret contains the required keys: tls.crt for the certificate and tls.key for the private key.

Docker registry Secrets, with types kubernetes.io/dockercfg and kubernetes.io/dockerconfigjson, store authentication information for private container registries. These Secrets enable Kubernetes to pull images from private repositories during pod creation.

Service account token Secrets contain tokens that identify service accounts within the Kubernetes cluster. These tokens are used for authentication and authorization when pods need to interact with the Kubernetes API.

Key differences: when to use Secrets vs. ConfigMaps

When designing Kubernetes applications, developers often face the decision of whether to use Kubernetes Secrets or ConfigMaps for configuration data. While both resources serve the purpose of separating configuration from application code, they have distinct characteristics that make them suitable for different scenarios.

The primary distinction between Kubernetes Secrets and ConfigMaps lies in their intended purpose. Secrets are specifically designed for storing sensitive information such as passwords, tokens, and keys, while ConfigMaps are meant for non-confidential configuration data. This fundamental difference drives many of the other distinctions between these two resources.

From a security perspective, Kubernetes Secrets offer additional protections that ConfigMaps do not. Although Secrets are stored as base64 encoded data by default (which is not encryption), Kubernetes provides mechanisms to encrypt Secrets at rest in etcd. Additionally, Kubernetes restricts the visibility of Secret data in logs and when using commands like kubectl get secrets, showing only metadata rather than the actual secret values.

Best practices suggest using Kubernetes Secrets only for genuinely sensitive information and ConfigMaps for everything else. This approach minimizes the attack surface by limiting the amount of sensitive data that needs special protection.

How to create Secrets in Kubernetes: hands-on implementation
Creating and managing Kubernetes Secrets effectively is a crucial skill for any Kubernetes administrator or developer. This section provides a hands-on guide to implementing Secrets in your Kubernetes cluster.

The most straightforward way to create a Secret is using the kubectl command-line tool. For example, to create a Secret containing database credentials, you can use the following command:

# First, encode your sensitive data using base64
echo -n 'admin' | base64
# Output: YWRtaW4=
echo -n 'p@ssw0rd' | base64
# Output: cEBzc3cwcmQ=

# Then create the secret using the encoded values
kubectl create secret generic db-credentials \
  --from-literal=username=YWRtaW4= \
  --from-literal=password=cEBzc3cwcmQ=

This command creates an Opaque Secret named db-credentials with two key-value pairs. The values are base64-encoded to follow security best practices. Note that while base64 encoding is not encryption, it’s the standard format for Kubernetes Secrets and should be combined with proper RBAC controls and encryption at rest.

For more complex scenarios, creating Secrets using YAML files provides greater flexibility and enables version control of your Secret definitions (without the actual secret values).

Here’s an example of a Secret defined in a YAML file:

apiVersion: v1
kind: Secret
metadata:
  name: api-credentials
type: Opaque
data:
  api-key: YXBpLWtleS0xMjM0NQ==     # Base64 encoded 'api-key-12345'
  api-token: dG9rZW4tYWJjZGVmZ2hpams=  # Base64 encoded 'token-abcdefghijk'

In the example above, the values are base64-encoded as required by Kubernetes. Never include actual secret values in your version-controlled YAML files, even in base64 format. Instead, use a secure secret management workflow where encoded values are generated and applied separately.

How are Kubernetes Secrets stored by default?

By default, Kubernetes stores Secrets in its underlying database, etcd, which serves as the primary datastore for all Kubernetes cluster state information.

The most critical aspect to understand about Kubernetes Secrets storage is that, by default, Secrets are stored unencrypted in etcd. While the data in Secrets is base64 encoded, this encoding is not encryption and provides no security benefit, it’s just a way to represent binary data in a string format.

To address these security concerns, Kubernetes provides a feature encryption at rest for secrets called EncryptionConfig. When enabled, this encrypts data before storing it in etcd, providing an additional layer of protection. Enabling encryption at rest requires configuring an encryption provider in the API server configuration file. Kubernetes supports several encryption providers, including:


identity: No encryption (default)
aescbc: AES-CBC encryption with PKCS#7 padding
secretbox: XSalsa20 and Poly1305 encryption
aesgcm: AES-GCM encryption

kms: Envelope encryption using a key management service

Security best practices and compliance considerations

The first and most critical security practice for Kubernetes Secrets is enabling encryption at rest. Enabling encryption at rest ensures that Secret data is encrypted before being written to persistent storage.

Role-based access control (RBAC) is another security measure for Kubernetes Secrets. RBAC allows you to define fine-grained permissions for who can create, read, update, and delete Secrets in your cluster. Implementing the principle of “least privilege” will allow users and service accounts to have access only to the specific Secrets they need to perform their functions.

Network policies should be implemented to restrict which pods can communicate with the Kubernetes API server, limiting the potential for unauthorized Secret access. By default, all pods in a cluster can communicate with the API server, potentially allowing compromised applications to access Secrets they shouldn’t.

Regular auditing of Secret access and usage is a good practice for security and compliance. Kubernetes audit logs can be configured to record all Secret-related operations, providing visibility into who accessed which Secrets and when.

Conclusion

While the default implementation offers basic protection, additional measures like encryption at rest, RBAC, and integration with external secret management systems can significantly enhance security.

When implementing Kubernetes Secrets in your environment, remember these key takeaways:

Use Secrets specifically for sensitive information and ConfigMaps for non-confidential configuration data
Enable encryption at rest to protect Secrets stored in etcd
Implement RBAC with least privilege principles to control access to Secrets
Consider setting Secrets as immutable to improve performance and prevent accidental updates
For enterprise environments, integrate with external secret management systems for enhanced security features
By following these best practices, you can effectively manage sensitive information in your Kubernetes clusters while maintaining security, compliance, and operational efficiency.