6 Types of Kubernetes Secrets and How to Use Them

What Are Kubernetes Secrets? 

Kubernetes Secrets store sensitive information like usernames, passwords, tokens, and keys for accessing services within a Kubernetes cluster. This feature offers a secure way to handle such data instead of embedding it directly into configuration files or code. Kubernetes Secrets keep confidential information separate from application details, maintaining a clear security boundary.

Beyond storing sensitive data, Kubernetes Secrets provide mechanisms for accessing this information safely. By integrating with the broader Kubernetes ecosystem, they facilitate granular access controls and automate secret injection into the cluster environment. This process minimizes exposure and reduces the risk of inadvertently sharing sensitive information across deployments.

This is part of a series of articles about Kubernetes monitoring

Why Use Kubernetes Secrets? 

Using Kubernetes Secrets strengthens security by isolating sensitive information from applications. This separation simplifies managing and updating secrets since they are decoupled from application configurations. Updates can occur without altering application deployment, minimizing downtime and increasing system flexibility. This dynamic enhances security and operational efficiency in maintaining your infrastructure.

Additionally, Kubernetes Secrets support encryption both in transit and at rest, crucial for compliance with security standards. By leveraging such encryption, you ensure that even if data is intercepted, it remains inaccessible without the appropriate keys, providing an extra layer of security. Secrets management systems integrated with Kubernetes streamline workflows, allowing automatic rotation and easy revocation, further enhancing security postures.

Related content: Read our guide to Kubernetes management 

Types of Kubernetes Secrets 

1. Opaque Secrets

Opaque Secrets are the most common type of Kubernetes secret, used for arbitrary user-defined data not bound to any specific format. These secrets allow users to store keys in any format required by applications, making them versatile for various data types. Opaque Secrets are typically utilized to keep generic sensitive information that applications need to function securely.

When creating an opaque secret, the data must be base64 encoded, ensuring secure transmission within Kubernetes infrastructure. This encoding requirement keeps the data compact and ready for integration with different Kubernetes resources. Administrators and developers can easily decode the data when necessary, maintaining a secure and efficient method for managing sensitive information across applications.

2. TLS Secrets

TLS Secrets are specifically used for storing Transport Layer Security certificates and private keys. These secrets enable secure communication between services, ensuring data privacy and authenticity over the network. By managing TLS certificates as Kubernetes secrets, users safeguard cryptographic material required for setting up secure connections in the cluster.

Administrators can automate the creation and renewal of TLS Secrets, supporting dynamic environments where certificates change regularly. Tools like Cert-Manager integrate with Kubernetes to manage the lifecycle of TLS certificates automatically. This automation reduces the administrative overhead associated with maintaining TLS credentials manually, providing streamlined security across Kubernetes services.

3. Docker Registry Secrets

Docker Registry Secrets store credentials required to access private Docker registries. These secrets facilitate the use of private container images within Kubernetes, ensuring that only authorized users can pull images. By securely managing registry credentials, Kubernetes maintains interactions with private repositories without exposing sensitive data to unauthorized entities.

To create a Docker Registry Secret, users supply authentication information such as usernames, passwords, or tokens. Kubernetes then encodes these inputs into a secret that pods can reference to access protected images. This integration simplifies image pulls from private registries, enhances security protocols, and maintains efficient deployment processes across clusters.

4. SSH Authentication Secrets

SSH Authentication Secrets store private key data for SSH-based access configurations. These secrets allow applications and services running on Kubernetes to authenticate with external systems using SSH keys, maintaining secure and encrypted communication channels. By encapsulating SSH credentials within secrets, Kubernetes ensures a systematic way of handling authentication data without exposing sensitive keys.

When configuring SSH Authentication Secrets, it’s important to securely generate and manage private keys to prevent unauthorized access. Kubernetes supports the easy rotation and revocation of such keys, ensuring that access remains restricted only to authorized users or services. This protection reinforces secure connections, crucial for any infrastructure relying on SSH-based interactions.

5. Basic Authentication Secrets

Basic Authentication Secrets help store credentials for HTTP Basic authentication. They often contain a combination of username and password, used for simple password-protected web resources. Using secrets to manage Basic Authentication preserves the confidentiality of credentials across applications and services within Kubernetes.

To configure Basic Authentication Secrets, these credentials must be securely encoded, promoting secure data transmission between services. Kubernetes simplifies incorporating these secrets through native support for environment variables or configurations, enabling secure and straightforward application integrations. This usage reduces the risk of credential exposure in unsecured environments.

6. Service Account Tokens

Service Account Tokens are Kubernetes Secrets containing tokens used for in-cluster authentication and API access. These tokens allow applications running in pods to interact with the Kubernetes API, facilitating automated service account configuration management. Ensuring these tokens remain secure is key, as they grant permissions based on assigned roles within the cluster.

Administrators can specify permissions and access controls associated with each service account, enhancing security with minimal privilege principles. Kubernetes makes managing these tokens straightforward, supporting automatic rotation and updates to maintain security integrity. Utilizing Service Account Tokens effectively requires fine-tuning cluster security policies and ensuring tokens are managed according to best practices.

Tips from the expert

Itiel Shwartz

Co-Founder & CTO

Itiel is the CTO and co-founder of Komodor. He’s a big believer in dev empowerment and moving fast, has worked at eBay, Forter and Rookout (as the founding engineer). Itiel is a backend and infra developer turned “DevOps”, an avid public speaker that loves talking about things such as cloud infrastructure, Kubernetes, Python, observability, and R&D culture.

In my experience, here are tips that can help you better manage and utilize Kubernetes Secrets:

Use Kubernetes Secret resources as volumes when dealing with frequent access:

Instead of exposing secrets as environment variables, mount them as volumes. This method reduces the risk of secrets being captured in process dumps and provides a more secure way to reference sensitive data within containers.

Set up secret versions with external tools:

When using external secret managers (e.g., HashiCorp Vault or AWS Secrets Manager), implement versioning of secrets. This allows for easier rollback if a new secret causes issues and supports gradual secret rotation without immediate disruption to running services.

Use Kubernetes CSI Secrets Store to securely mount external secrets:

The Kubernetes Secrets Store CSI driver allows secrets from external stores like Azure Key Vault or AWS Secrets Manager to be mounted directly into pods as files. This adds an extra layer of security by offloading secret storage to managed services.

Employ custom secret encryption strategies:

Beyond Kubernetes’ built-in encryption, consider additional layers of encryption before storing data in a secret. For instance, encrypt sensitive data (like private keys) at the application level and store the encrypted result in a secret to ensure multi-layer protection.

Monitor for unused secrets:

Regularly audit and clean up unused or obsolete secrets. Over time, secrets can accumulate, especially in dynamic or rapidly evolving environments. Automate this process with scripts or monitoring tools to ensure secret hygiene.

Creating and Managing Kubernetes Secrets 

These instructions are adapted from the Kubernetes documentation.

Create a Secret

To create a Kubernetes secret, you can either provide the sensitive data directly in the command or store it in files that you pass as input. Here’s how you can do it:

Using raw data: If you’d like to pass the data directly in the command, use the kubectl create secret generic command. For example, to store a username (admin) and password (S!B\*d$zDsb=), you would run:

kubectl create secret generic db-user-pass \

--from-literal=username=admin \  
--from-literal=password='S!B\*d$zDsb='

Ensure to escape special characters such as $, \, *, =, and ! by wrapping the string in single quotes. This prevents the shell from misinterpreting them.

Using source files: Alternatively, you can store sensitive data in files and pass them to the command. This method avoids the need for escaping special characters:

echo -n 'admin' > ./username.txt
echo -n 'S!B\*d$zDsb=' > ./password.txt

Once the files are ready, create the secret with:

kubectl create secret generic db-user-pass \
--from-file=./username.txt \  
--from-file=./password.txt 

The default key for each secret is the filename, but you can specify custom key names by modifying the command:

kubectl create secret generic db-user-pass \
--from-file=username=./username.txt \
--from-file=password=./password.txt

Verify the Secret

After creating a secret, you can verify its existence using:

kubectl get secrets

The output will display a list of secrets, including the one you just created:

NAME              TYPE       DATA      AGE
db-user-pass      Opaque     2         51s

To see more details about the secret, use:

kubectl describe secret db-user-pass

This command shows metadata and general information without exposing the actual secret values, ensuring sensitive data is not displayed unintentionally.

Decoding Secrets

To view the actual contents of a secret, you’ll need to decode the base64-encoded data. First, retrieve the encoded values:

kubectl get secret db-user-pass -o jsonpath='{.data}'

Then, to decode a specific field like the password, use:

echo 'UyFCXCpkJHpEc2I9' | base64 --decode

This method can expose sensitive data, so use it cautiously. A safer approach would be to combine the retrieval and decoding in one step:

kubectl get secret db-user-pass -o jsonpath='{.data.password}' | base64 --decode

Editing and Deleting Secrets

To update an existing secret, you can run:

kubectl edit secrets db-user-pass

This command opens the secret in your default editor, allowing you to modify its values. Be mindful of updating the base64-encoded data correctly.

If you no longer need a secret, you can delete it with:

kubectl delete secret db-user-pass

This command removes the secret from your cluster, ensuring that the sensitive data is no longer accessible to your applications.

Best Practices for Managing Secrets in Kubernetes 

Avoid Storing Secrets in Plain Text

Avoiding storing secrets in plain text is a key security practice, imperative for safeguarding sensitive information. Plain text secrets are vulnerable to exposure through unprotected channels, risking unauthorized access. Instead, secrets should always be encoded or encrypted before storage, ensuring they remain obscured to unauthorized viewers.

Kubernetes ecosystems should integrate measures like base64 encoding or at-rest encryption to protect secrets, facilitating secure data handling. Adopting such practices shields sensitive credentials from exposure during transmission or storage, maintaining confidentiality and integrity. Organizations must enforce policies for secure storage and transmission protocols to enhance information security.

Use External Secret Management Tools

Leveraging external secret management tools enhances security by offering methods for storing, accessing, and auditing secrets. Tools like HashiCorp Vault or AWS Secrets Manager integrate with Kubernetes, providing centralized secret management with features like dynamic secrets and access logs.

These tools afford scalability and automation, reducing manual secret management tasks, and ensuring consistent security policies across environments. By employing external secret solutions, organizations streamline IT operations, enabling efficient secret lifecycle management and ensuring compliance with organizational security standards.

Regularly Rotate and Update Secrets

Regular rotation and update of secrets are critical to maintaining secure Kubernetes environments, reducing vulnerabilities related to stale credentials. This practice limits the usable lifespan of secrets, mitigating the risk of abused access from compromised or outdated secrets. Rotation ensures that even if exposed, secrets have minimal impact over time.

Integration of rotation scripts into Kubernetes workflows enables seamless transition of updated credentials across applications, minimizing disruption. Organizations benefit from maintaining procedures for systematic rotation and updates within their security frameworks, enhancing overall data protection and operational resilience.

Limit Access with RBAC Policies

Limiting access through RBAC policies in Kubernetes is fundamental to securing secrets, ensuring only authorized entities interact with sensitive data. By defining clear roles and permissions, RBAC allows precise control over which users or services can access or modify secrets. This granularity helps avoid privilege escalation and minimizes security risks.

Regular assessments of RBAC configurations are necessary to align access with evolving organizational roles and needs. Active management of RBAC policies ensures that only essential permissions are granted, supporting a minimal privilege model vital for robust security. Monitoring and auditing access patterns are crucial elements of maintaining effective RBAC enforcement.

Monitor and Audit Secret Usage

Monitoring and auditing secret usage is essential for identifying unauthorized access attempts and understanding access patterns. By implementing real-time monitoring tools, administrators gain visibility into how secrets are used across the system, allowing rapid response to anomalies. This monitoring supports comprehensive security oversight and compliance verification.

Auditing involves regularly reviewing access logs and system behaviors to identify potential threats or deviations from established norms. Integrating audits into routine operations promotes transparency and accountability, driving continuous improvement in security practices. These actions protect against breaches and align with organizational risk management strategies.

Simplifying Kubernetes Management with Komodor

Komodor is a dev-first Kubernetes operations and reliability management platform. It excels in providing a simplified and unified UI through which you can manage the daily tasks associated with Kubernetes clusters. At its core, the platform gives you a real-time, high-level view of your cluster’s health, configurations, and resource utilization. This abstraction is particularly useful for routine tasks like rolling out updates, scaling applications, and managing resources. You can easily identify bottlenecks, underutilized nodes, or configuration drift, and then make informed decisions without needing to sift through YAML files or execute a dozen kubectl commands.

Beyond just observation, Komodor integrates with your existing CI/CD pipelines and configuration management tools to make routine tasks more seamless. The platform offers a streamlined way to enact changes, such as scaling deployments or updating configurations, directly through its interface. It can even auto-detect and integrate with CD tools like Argo or Flux to support a GitOps approach! Komodor’s “app-centric” approach to Kubernetes management is a game-changer for daily operational tasks, making it easier for both seasoned DevOps engineers and those new to Kubernetes to keep their clusters running smoothly, and their applications maintaining high-availability.

If you are interested in checking out Komodor, use this link to sign up for a Free Trial.