Skip to content

Kubernetes – Secrets

Kubernetes is an open-source container orchestration system mainly used for automated software deployment, management, and scaling. Kubernetes is also known as K8s. Kubernetes was originally developed by Google, but it is now being maintained by Cloud Native Computing Foundation. It was originally designed to be interfaced with only Docker runtime, but it now works with containers and CRI-O also. The main purpose of Kubernetes is to automate the operational tasks of container management. It is included with built-in commands for the deployment of applications and rolling out the required changes in the application. It is currently being used by companies like Google, Spotify, and capital one.

What Are Kubernetes Secrets ?

A secret in Kubernetes can be defined as an object that contains a small quantity of sensitive data like a password, a token, or a key. It contains information that is otherwise stored in a container image or pod specification. The main advantage of a secret is that we will not have to include sensitive or confidential data in the application code. There is less risk of losing or exposing secrete during the workflow of creating viewing, and editing Pods because they can be and are created independently of the pods in which they are being used. Secretes can be considered similar to ConfigMaps but the main difference between them is that they are specially designed to store and hold confidential data.

Uses of Kubernetes Secretes

The following are the uses of Kubernetes Secrets:

  • Secrets can be used as a container environment variable.

  • As a file in a volume mounted on at least one of its containers.

  • It can be used by Kubelet when pulling images from the pod.

  • Secretes are also used by the Kubernetes control plane.

Using A Kubernetes Secret

  • Secretes can be exposed as environment variables to be used by a container in a Pod or can be mounted as data volumes. It can even be used directly by other parts of the system without being directly exposed to the pods. If we consider an example a secret can store credentials that other parts of the system should use to interact with the external systems at the pace ourselves.

  • The secret volume sources are validated to ensure that the specific object’s reference actually points to an object of a particular object of secret type. Due to this, the secrete should be created before any pods that depend on it. If the required secrete cannot be fetched due to its non-existence or due to the temporary lack of connection to the AOI server the kubelet periodically retires running that specific Pod. Kubelet also reports the event for that Pod including all the details of the problems fetching the secret.

  • When we are defining a container environment variable based on a Secret we can make it optional. The default setting is that a secrete is required. None of the Pod Containers will start working until all the non-optional Secrete are available. That means if a pod references a specific key in a Secrete, and it exists, but it is missing the name key then the pod fails startup.

Use Case: Dotfiles in a Kubernetes Secret Volume

For increasing the confidentiality of our data we can use dotfiles within the kubernetes secrets. Here the dotfiles are the hidden files that begin filename with (.) Ex: .api_key1 , .api_key2. By using these files inside the secrets we can store our sensitive keys and information safely. The following yaml code illustrates clearly.

In this example, the dotfiles .api_key1 and .api_key2 stores the sensitive API keys within api-keys-secret secret. These keys remains hidden and secured when mounted with api-keys-container ensuring only authorized processes can access them.

apiVersion: v1
kind: Secret
metadata:
  name: api-keys-secrets
type: Opaque
data:
  api_key1: YWJjZGVmZw==
  api_key2: ZGVmZ2hpamtsbQ==
---
apiVersion: v1
kind: Pod
metadata:
  name: api-keys-pod
spec:
  volumes:
  - name: secret-volume
    secret:
      secretName: api-keys-secrets
  containers:
  - name: api-keys-container
    image: registry.k8s.io/busybox
    command:
    - ls
    - "-la"
    - "/etc/secret-volume"
    volumeMounts:
    - name: secret-volume
      readOnly: true
      mountPath: "/etc/secret-volume"

Use case: Kubernetes Secret Visible to One Container in a Pod

We can enhance the security for the sensitive information within a pod by making it visible to only one container that is needed. For example take this scenario they are front and backend applications, front end application container is responsible for user interaction and complex business logic. Other backend application container will handle the message signing responsibility using private key that is stored securely in kubernetes secrets. Here the front end application doesn’t have expose to view the private key and see the sensitive data. The following yaml code illustrates it clearly.

apiVersion: v1
kind: Secret
metadata:
  name: signing-secret
data:
  .private-key: cGFzc3dvcmQ=
---
apiVersion: v1
kind: Pod
metadata:
  name: secure-pod
spec:
  containers:
    - name: frontend-container
      image: myregistry.io/frontend-app
      # Configuration for frontend container...

    - name: signer-container
      image: myregistry.io/signer-app
      command:
        - ls
        - "-la"
        - "/etc/signing"
      volumeMounts:
        - name: signing-volume
          readOnly: true
          mountPath: "/etc/signing"

  volumes:
    - name: signing-volume
      secret:
        secretName: signing-secret

Types Of Kubernetes Secrets

The following are the types of kubernetes Secrets and Its Usage inshort:

Built-in Type Usage
Opaque Used for storing user-defined data
k8s.io/service-account-token Used for storing ServiceAccount Token
k8s.io/dockercfg Used for storing serialized ~/.dockercfg file
k8s.io/dockerconfigjson Used for storing serialized ~/.docker/config.json file
k8s.io/basic-auth Used for storing basic authentication credentials

1. Opaque Secrets

  • These are the default secret types i.e., if don’t specify any type while creating, this Opaque secrets type is used default. It is used for storing general user-defined data values. We have to generic as subcommand to use this type, if you want to specify. The following is an empty

  • Example: Used for storing API keys or database passwords

  • The following command creates a empty secret type Opaque:

kubect create secret generic mysecret

2. ServiceAccount Token Secrets

  • This type of secret type is used to identify the serviceAccount It is used for storing credentials that are used by pods to authenticate with the kubernetes API Server.

  • Example: Used for storing Access Tokens for communicating with kubernetes resources.

  • The following yaml code illustrates it clearly:

apiVersion: v1
kind: Secret
metadata:
  name: sa-token-secret
  annotations:
    kubernetes.io/service-account.name: "sa-name"
type: kubernetes.io/service-account-token
data:
  token: <base64-encoded-token>

3. Docker Config Secrets

  • It used for serializing the docker configuration files that are used for authenticating with docker registries.

  • Example: Used for storing credentials for accessing private docker repositories.

  • The following yaml code helps in you better understanding of docker config secrets:

apiVersion: v1
kind: Secret
metadata:
  name: docker-config-secret
type: kubernetes.io/dockerconfigjson
data:
  .dockerconfigjson: <base64-encoded-config-json>

4. Basic Authentication Secrets

  • It is used for storing credentials of basic HTTP authentication. The following yaml code illustrates you clearly about creating basic Authentication secrets types with yaml code:

  • Example: It is used for storing Username and Password for accessing a web service.

apiVersion: v1
kind: Secret
metadata:
  name: ssh-auth-secret
type: kubernetes.io/ssh-auth
data:
  ssh-privatekey: UG91cmluZzYlRW1vdGljb24lU2N1YmE= # base64 encoded private key

5. SSH Authentication Secrets

  • It is used for storing credentials for SSH Authentication.The following yaml code helps you in better understanding the ssh Authentication secrets creation.

  • Example: Used for storing Username and passwords for accessing a web service.

apiVersion: v1
kind: Secret
metadata:
  name: ssh-auth-secret
type: kubernetes.io/ssh-auth
data:
  ssh-privatekey: UG91cmluZzYlRW1vdGljb24lU2N1YmE= # base64 encoded private key

6. TLS Secrets

  • It is used for storing data that is used for TLS encryption and decryption. The following yaml code helps you in better understanding of creating TLS secrets type:

  • Example: Stores TLS certificates and keys for securing communication between services.

apiVersion: v1
kind: Secret
metadata:
  name: tls-secret
type: kubernetes.io/tls
data:
  tls.crt: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUNVakNDQWJzQ0FnMytNQTBHQ1NxR1NJYjNE
    # base64 encoded certificate
  tls.key: RXhhbXBsZSBkYXRhIGZvciB0aGUgVExTIGNydCBmaWVsZA== # base64 encoded private key

7. BootStrap Token Secrets

  • This secret type is used for storing tokens that are used during the node bootstrap process to sign. The following yaml code helps in understanding and creating the bootstrap token secrets:
apiVersion: v1
kind: Secret
metadata:
  name: tls-secret
type: kubernetes.io/tls
data:
  tls.crt: LS0tLS1CRUdJTiBDRVJUSUZJQ0FURS0tLS0tCk1JSUNVakNDQWJzQ0FnMytNQTBHQ1NxR1NJYjNE
    # base64 encoded certificate
  tls.key: RXhhbXBsZSBkYXRhIGZvciB0aGUgVExTIGNydCBmaWVsZA== # base64 encoded private key

Ways To Create Kubernetes Secrets

When we're working with kubernetes, the management of passwords, tokens and certificates are important. Kubernetes comes up with multi-mode of solutions for securely store and access the data. Here, lets discuss the 3 general methods for creating kubernetes secrets.

  1. Create kubernetes secrets using kubectl

  2. Create kubernetes secrets using A manifest file

  3. Create kubernetes secrets using A Generator like Kustomize

Creating Kubernetes Secrets Using Kubectl

  • It is a quick and straightforward way of creating kubernetes secrets from command line. It is suitable for creating secrets on the fly during development or testing phases.

  • In this secrets creation, it supports accessing data from literals, files offering flexibility of handling sensitive data. The following command is used for creating secrets with string literals:

kubectl create secret generic my-secret --from-literal=username=admin --from-literal=password=secretpassword
  • The following command is used for creating secrets from one or more files:
kubectl create secret generic my-secret --from-file=ssh-privatekey=~/.ssh/id_rsa

Create Kubernetes Secrets Using A Manifest File

  • It comes with facilitating a declarative way of defining secrets using YAML or JSON manifest files. It facilitates with easy sharing and replication of secrets configurations on different environments.

  • The following is the simple Yaml file for creating kubernetes secrets.

apiVersion: v1
kind: Secret
metadata:
  name: my-secret
type: Opaque
data:
  username: YWRtaW4= # base64 encoded username
  password: cGFzc3dvcmQ= # base64 encoded password
  • After the saving the above file code as mysecret-file.yaml execute the file and create secrets using following command:
kubectl apply -f mysecret-file.yaml

Create Kubernetes Secrets Using A Generator Like Kustomize

  • This type of method supports seamless integration with Kustomize ( a K8s native configuration management tool ). It facilitates with generating and customizing secrets dynamically based on overlays or patches.

  • It offers enhanced flexibility and scalability for managing complex secret configurations across multiple developments.

apiVersion: v1
kind: Secret
metadata:
  name: my-secret
type: Opaque
data:
  api-key: <base64-encoded-api-key>
  • After saving the above code file as base-secret.yaml and then execute it with following command:
kustomize build overlays/ | kubectl apply -f -

Kubernetes Secrets vs Configmap

The following are the differences between Kubernetes Secrets and Kubernetes Configmap:

Features Kubernetes Secrets Kubernetes ConfigMaps
Data Sensitivity Used for storing sensitive data such as passwords, tokens, and certificates Suitable for storing non-sensitive configuration data like application settings, environment variables, and configuration files
Data Encoding Data is encoded in base64 for basic security, but not encryption Data is stored in plain text without encoding or encryption
Access Control Supports RBAC (Role-Based Access Control) for fine-grained access control Access control is limited to the namespace level
Use Cases Used for storing sensitive and confidential data required by applications (running pods) Used for storing configuration data exposed to pods as environment variables or mounted files
Data Storage Stores data securely within the Kubernetes cluster Stored alongside Kubernetes resources within the etcd data store

Kubernetes Secrets Vs Vault

The following are the difference between Kubernetes Secrets and Vault:

Features Kubernetes Secrets Vault
Data Sensitivity Used for storing basic sensitive data such as passwords, tokens, but lacks advanced security features Used for storing critical and highly sensitive data with advanced encryption and access control mechanisms
Encryption Uses base64 encoding for basic security but lacks encryption for data at rest Provides strong encryption mechanisms for data at rest and in transit (AES-256 encryption)
Access Control Provides access control limited with RBAC (Role-Based Access Control) Offers fine-grained access control policies, LDAP integration, and identity-based access management
Dynamic Secrets Does not natively support dynamic secret management and generation Supports dynamic secret generation and management, enhancing security by reducing the exposure of long-lived secrets
Integration Provides basic Kubernetes integration for secret management within the cluster Seamless integration with Kubernetes for centralized management across clusters and environments

How to Manage Kubernetes Secrets ?

Management of kubernetes secrets involves steps for securely handing sensitive data within the kubernetes cluster. Some of the managing kubernetes secrets are discussed as follows:

  • Creation: On using kubectl commands create secrets for storing sensitive data such as passwords, tokens or certificates.

  • Access Control: Implement Role Based Access Control ( RBAC ) to restrict the access of secrets based on users.

  • Encryption: Consider on using external solutions like Hashicorp Vault for enhancing security of secret data at rest and in transit.

  • Rotation: Regularly rotating the secrets helps in minimizing the risk of unauthorization and maintaining the security policies.

How to Use Kubernetes Secrets as Files In Containers ?

On using Kubernetes secrets as files we can provide a convenient way of securely accessing sensitive data within pods. The following are some of the uses of kubernetes secrets as files in containers:

  • Mounting Secrets: Mount the secrets as volumes or individual files in a pod containers using volume mounts or environment variables.

  • Files Access: Try on accessing the secret data within containers as files from specific directories or as environment variables.

  • Security: Ensure to maintain proper permissions and access controls that are configured to restrict access of secret files within containers.

  • Integration: The seamless integration of secret files into the application workflows facilitates secure retrival and utilization of sensitive information during runtime.

Working With Kubernetes

Working with kubernetes involves better understanding of its core concepts and effective management of resources within the cluster. The following are some of the points suggested for working with kubernetes:

  • Resource Management: We can deploy and manage the resources such as Pods, deployments, services and other resources using declarative YAML manifests or using imperative kubectl commands.

  • Scaling: The scaling of applications horizontally or vertically to meet the changes as per demand can be done using k8s scaling features such asHorizontal Pod Autoscaler (HPA) or Vertical Pod Autoscaler ( VPA ).

  • Monitoring: On monitoring the resource utilization, cluster health and application performance with the help of built-in kubernetes monitoring tools or third party solutions.

  • Maintenance: Try on performing routine maintenance tasks such as upgrades, patches and backups for ensuring stability, reliability of kubernetes cluster.

Alternatives to Kubernetes Secrets

If there is a need to protect your data then Secrete is not the only option available. There are some other alternatives available.

  • We can use ServiceAccount and its tokens to identify the cluster if the cloud native component has the need for authentication to another application that is also running within the same Kubernetes Cluster.

  • We can use third-party tools that can be run by us either outside or from within the cluster that provides secrets management.

  • If we need authentication we can implement a custom signer for X.509 certificates and then use CertificateSigningRequests to let that custom signer issue certificates to Pods that required them.

  • We can use a device plugin to expose node local encryption hardware to a specific Pod.

There is no compulsion to use only services or one of these options. We can even combine two or more options based on our requirements.