Kubernetes Secrets: A Practical Guide

Kubernetes secrets blog banner

What Are Kubernetes Secrets? 

The term Kubernetes secrets can have two meanings: managing secrets such as passwords, tokens, and SSH keys in a Kubernetes environment, and the specific Kubernetes mechanism called Secrets, which allows you to manage this sensitive information. 

Most of our article will focus on the second meaning, explaining how the built-in Kubernetes Secrets mechanism works. However, Kubernetes Secrets are not meant to be a comprehensive solution for managing secret data, and you should consider using a dedicated secrets management solution compatible with Kubernetes.

The Secrets resource in Kubernetes works similar to a ConfigMap, but is intended to hold confidential data. This distinction is not enforced by Kubernetes, but rather agreed upon by convention. Here is an example of a Secret manifest in Kubernetes:

apiVersion: v1
kind: Secret
  name: my-secret
type: Opaque
  key1: value1
  key2: value2

This is part of a series of articles about secret management.

Why Is Kubernetes Secrets Management Important? 

Managing sensitive data is a critical aspect of any production system. In the context of Kubernetes, sensitive data could include items like API tokens, database passwords, or TLS certificates. If such information were exposed, it could lead to a data breach or compromise of your Kubernetes infrastructure.

The Kubernetes Secrets mechanism provides a basic way to store and manage such sensitive information. By using Secrets, you can ensure sensitive data is not exposed in logs or accidentally leaked to unauthorized users.

Additionally, Secrets provide a way to decouple sensitive data from the application code. This means you don’t have to hardcode sensitive data into applications, making it easier to manage and update it as needed.

Types of Kubernetes Secrets 

Here are the main types of secrets supported by the Kubernetes Secrets resource.

Opaque Secrets

Opaque is the default type of secret. This type is used when the secret contains arbitrary key-value pairs. The keys and values can be anything you want, making opaque secrets versatile for many use cases.

For example, you might use an opaque secret to store database credentials. The secret could include keys like username and password, with corresponding values. The application could then use these credentials to connect to the database.

Service Account Token Secrets

Service account token secrets are used to store tokens that identify Kubernetes service accounts. Kubernetes automatically creates these secrets and attaches them to service accounts.

These secrets let applications running in your cluster authenticate to the Kubernetes API. This is useful for applications that need to manage Kubernetes resources.

Docker Config Secrets

Docker config secrets are used to store Docker registry login credentials. If your application’s Docker images are stored in a private registry, your pods need credentials to pull those images. Docker config secrets let you provide these credentials without including them in your pod specification or Dockerfiles.

Basic Authentication Secret

Basic authentication secrets are used to store credentials for basic HTTP authentication. These secrets contain two keys: username and password.

For example, you might use a basic authentication secret if your application needs to authenticate to a web service that uses basic HTTP authentication.

SSH Authentication Secrets

SSH authentication secrets are used to hold SSH private keys. They can be used to authenticate with services that require SSH authentication.

This type of secret is especially useful when you need to establish secure connections to external services.

TLS Secrets

TLS secrets are used to store a certificate and its corresponding private key. These secrets are useful for applications that use TLS for secure communications.

For example, if you’re running a web server in your cluster, you could use a TLS secret to provide the server’s SSL certificate and private key. The web server could then use these to establish secure connections with clients.

Bootstrap Token Secrets

Bootstrap token secrets are used for establishing trust between a client and the API server in the process of bootstrapping a new node.

These secrets are a critical part of the Kubernetes node bootstrapping process, ensuring only authorized nodes can join your cluster.

Learn more in our detailed guide to Kubernetes secrets types (coming soon)

Tutorial: Creating and Using Kubernetes Secrets 

Create Secrets Using kubectl

Creating secrets using kubectl is the most straightforward method to manage your Kubernetes secrets.

To start, ensure that you have kubectl installed and properly configured to interact with your Kubernetes cluster. You can use the kubectl create secret command to make a secret. Here’s an example:

kubectl create secret generic my-secret --from-literal=key1=value1 --from-literal=key2=value2

In this command, my-secret is the name of your secret, while --from-literal allows you to specify the key-value pairs that make up the secret. Another way to define secrets is to provide a file that kubectl should take the secret’s data from, using the flag  --from-file=<filename>

Create Secrets in a Manifest File

Creating secrets in a manifest (YAML configuration file) provides an alternative method for managing your Kubernetes secrets. This approach is often used when you need to store secrets that have multiple key-value pairs or when you want to store your secrets in version control.

To create a secret in a configuration file, you need to create a YAML or JSON file that describes the secret. Here’s a sample YAML file for a secret:

apiVersion: v1
kind: Secret
  name: my-secret
type: Opaque
  key1: value1
  key2: value2

In this file, my-secret is the name of your secret, while data is where you specify your key-value pairs. Note that the values must be base64 encoded.

Use kubectl describe to See Existing Secrets

Once you’ve created your Kubernetes secrets, you can use the kubectl describe command to see their status and metadata, although it will not display the actual secret data.

Here’s how to use kubectl describe to view your secrets:

kubectl describe secrets my-secret

The output will look something like this:

In this command, my-secret is the name of your secret. The output will display the metadata of your secret, including the name, namespace, labels, annotations, and type.

Edit a Secret’s Metadata

There might be times when you need to edit a Kubernetes secret. This could happen when you need to update the value of a key, add a new key-value pair, or remove an existing one.

To edit a secret, you can use the kubectl edit command. However, note that this command only allows for editing the metadata of a secret. To change the data of the secret, you need to recreate the secret.

Here’s an example of how to edit a secret:

kubectl edit secrets my-secret

In this command, my-secret is the name of your secret. This will open a text editor where you can edit the metadata of your secret, like this:

Best Practices for Managing Kubernetes Secrets 

Here are a few best practices that can help you manage Kubernetes secrets effectively.

Limit Access Using RBAC

Role-Based Access Control (RBAC) plays a critical role in securing your Kubernetes environment by allowing you to specify who has access to what. You can use the built-in Kubernetes RBAC functionality to restrict access to your secrets.

The first step in limiting access is to determine who needs access to the secrets. Not everyone in your organization should have access to all secrets. This principle of least privilege should guide you when configuring RBAC for secrets.

Next, define roles and role bindings that align with your access requirements. A role in Kubernetes defines a set of permissions to perform actions (like read, write, or update) on a set of resources, such as secrets. Role bindings link these permissions to specific users, groups, or service accounts.

Encrypt Secrets at Rest

When secrets are at rest, they are stored in etcd, the distributed key-value store that Kubernetes uses to maintain cluster state.

By default, data in etcd is not encrypted at rest. This means that anyone with access to the etcd data can potentially read your Kubernetes secrets. This is a significant security risk, especially if your etcd data is stored in a shared or insecure environment.

To mitigate this risk, you should enable encryption at rest for your Kubernetes secrets. This can be done by configuring a Kubernetes feature called KMS (Key Management Service) provider. A KMS provider is a plugin that provides key management for Kubernetes, allowing you to encrypt and decrypt data using a managed service.

Use Environment Variables Sparingly

Environment variables are a common way to pass configuration information to applications. However, when it comes to secrets, using environment variables should be done sparingly.

The reason for this is simple: environment variables are not secure. They can be accessed by any process running on the same machine, making them an attractive target for attackers. Furthermore, environment variables are often logged or displayed in debugging information, potentially exposing your secrets.

A better alternative to environment variables is to use Kubernetes secrets as files. By mounting a secret as a file in a pod, you can provide your application with the secret it needs without exposing it to unnecessary risks.

Automate Secret Management

Finally, try to automate as much of the process as possible. Manual secret management is error-prone and inefficient. By automating secret management, you can ensure consistent application of best practices, reduce human error, and save time.

Automation can be achieved through the use of secret management tools and automation scripts. For example, you can use a secret management tool to automatically rotate secrets, ensuring that your secrets are always fresh and reducing the chance of a secret being compromised. Secret management tools can also help you centrally manage secrets, monitor access to secrets, and create an audit trail of the usage of secrets over time.

Learn more in our detailed guide to Kubernetes Secrets best practices (coming soon)

Related content: Read our guide to GitHub secrets

Kubernetes Secret Management with Configu

Configu is a configuration management platform comprised of two main components:

Configu Orchestrator

As applications become more dynamic and distributed in microservices architectures, configurations are getting more fragmented. They are saved as raw text that is spread across multiple stores, databases, files, git repositories, and third-party tools (a typical company will have five to ten different stores).

The Configu Orchestrator, which is open-source software, is a powerful standalone tool designed to address this challenge by providing configuration orchestration along with Configuration-as-Code (CaC) approach.

Configu Cloud

Configu Cloud is the most innovative store purpose-built for configurations, including environment variables, secrets, and feature flags. It is built based on the Configu configuration-as-code (CaC) approach and can model configurations and wrap them with unique layers, providing collaboration capabilities, visibility into configuration workflows, and security and compliance standardization.

Unlike legacy tools, which treat configurations as unstructured data or key-value pairs, Configu is leading the way with a Configuration-as-Code approach. By modeling configurations, they are treated as first-class citizens in the developers’ code. This makes our solution more robust and reliable and also enables Configu to provide more capabilities, such as visualization, a testing framework, and security abilities.

Learn more about Configu

Try Configu for free
Painless end-to-end configuration management platform
Get Started for Free