Configuring Secrets

TOC

Understanding Secrets

In Kubernetes (k8s), a Secret is a fundamental object designed to store and manage sensitive information, such as passwords, OAuth tokens, SSH keys, TLS certificates, and API keys. Its primary purpose is to prevent sensitive data from being directly embedded in Pod definitions or container images, thereby enhancing security and portability.

Secrets are similar to ConfigMaps but are specifically intended for confidential data. They are typically base64-encoded for storage and can be consumed by pods in various ways, including being mounted as volumes or exposed as environment variables.

Usage Characteristics

  • Enhanced Security: Compared to plaintext configuration maps (Kubernetes ConfigMap), Secrets offer better security by storing sensitive information using Base64 encoding. This mechanism, combined with Kubernetes' ability to control access, significantly reduces the risk of data exposure.

  • Flexibility and Management: Using Secrets provides a more secure and flexible approach than hardcoding sensitive information directly into Pod definition files or container images. This separation simplifies the management and modification of sensitive data without requiring changes to application code or container images.

Supported Types

Kubernetes supports various types of Secrets, each tailored for specific use cases. The platform typically supports the following types:

  • Opaque: A general-purpose Secret type used to store arbitrary key-value pairs of sensitive data, such as passwords or API keys.

  • TLS: Specifically designed to store TLS (Transport Layer Security) protocol certificate and private key information, commonly used for HTTPS communication and secure ingress.

  • SSH Key: Used to store SSH private keys, often for secure access to Git repositories or other SSH-enabled services.

  • SSH Authentication (kubernetes.io/ssh-auth): Stores authentication information for data transmitted over the SSH protocol.

  • Username/Password (kubernetes.io/basic-auth): Used to store basic authentication credentials (username and password).

  • Image Pull Secret (kubernetes.io/dockerconfigjson): Stores the JSON authentication string required for pulling container images from private image repositories (Docker Registry).

Usage Methods

Secrets can be consumed by applications within pods through different methods:

  • As Environment Variables: Sensitive data from a Secret can be injected directly into a container's environment variables.

  • As Mounted Files (Volume): Secrets can be mounted as files within a pod's volume, allowing applications to read sensitive data from a specified file path.

Note: Pod instances in workloads can only reference Secrets within the same namespace. For advanced usage and YAML configurations, refer to the Kubernetes official documentation.

Creating an Opaque type Secret

kubectl create secret generic my-secret \
  --from-literal=username=admin \
  --from-literal=password=Pa$$w0rd

YAML

apiVersion: v1
kind: Secret
metadata:
  name: my-secret
type: Opaque
data:
  username: YWRtaW4= # base64 of "admin"
  password: UGEkJHcwcmQ= # base64 of "Pa$$w0rd"

You can decode them like:

echo YWRtaW4= | base64 --decode  # output: admin

Creating a Docker registry type Secret

kubectl create secret docker-registry my-docker-creds \
  --docker-username=myuser \
  --docker-password=mypass \
  --docker-server=https://index.docker.io/v1/ \
  --docker-email=my@example.com

YAML

apiVersion: v1
kind: Secret
metadata:
  name: my-docker-creds
type: kubernetes.io/dockerconfigjson
data:
  .dockerconfigjson: eyJhdXRocyI6eyJodHRwczovL2luZGV4LmRvY2tlci5pby92MS8iOnsidXNlcm5hbWUiOiJteXVzZXIiLCJwYXNzd29yZCI6Im15cGFzcyIsImVtYWlsIjoibXlAZXhhbXBsZS5jb20iLCJhdXRoIjoiYlhsMWMyVnlPbTE1Y0dGemN3PT0ifX19

K8s automatically converts your username, password, email, and server information into the Docker standard login format:

{
  "auths": {
    "https://index.docker.io/v1/": {
      "username": "myuser",
      "password": "mypass",
      "email": "my@example.com",
      "auth": "bXl1c2VyOm15cGFzcw=="  # base64(username:password)
    }
  }
}

This JSON is then base64 encoded and used as the data field value of the Secret.

Use it in a Pod:

imagePullSecrets:
  - name: my-docker-creds

Creating a Basic Auth type Secret

apiVersion: v1
kind: Secret
metadata:
  name: basic-auth-secret
type: kubernetes.io/basic-auth
stringData:
  username: myuser
  password: mypass

Creating a SSH-Auth type Secret

Use Case: Store SSH private keys (e.g., for Git access).

apiVersion: v1
kind: Secret
metadata:
  name: ssh-key-secret
type: kubernetes.io/ssh-auth
stringData:
  ssh-privatekey: |
    -----BEGIN OPENSSH PRIVATE KEY-----
    ...
    -----END OPENSSH PRIVATE KEY-----

Creating a TLS type Secret

Use Case: TLS certs (used by Ingress, webhooks, etc.)

kubectl create secret tls tls-secret \
--cert=path/to/tls.crt \
--key=path/to/tls.key

YAML

apiVersion: v1
kind: Secret
metadata:
  name: tls-secret
type: kubernetes.io/tls
data:
  tls.crt: <base64>
  tls.key: <base64>

Creating a Secret by using the web console

  1. Go to Container Platform.

  2. In the left navigation bar, click Configuration > Secrets.

  3. Click Create Secret.

  4. Configure the parameters.

    Note: In the form view, sensitive data such as the input username and password will automatically be encoded in Base64 format before being stored in the Secret. The converted data can be previewed in the YAML view.

  5. Click Create.

How to Use a Secret in a Pod

As Environment Variables

env:
  - name: DB_USERNAME
    valueFrom:
      secretKeyRef:
        name: my-secret
        key: username

From the secret named my-secret, take the value with the key username and assign it to the environment variable DB_USERNAME.

As Mounted Files (Volume)

volumes:
  - name: secret-volume
    secret:
      secretName: my-secret

volumeMounts:
  - name: secret-volume
    mountPath: "/etc/secret"

Follow-up Actions

When creating workloads for native applications in the same namespace, you can reference the Secrets that have already been created.

Operations

You can click the (⋮) on the right side of the list page or click Actions in the upper right corner of the details page to update or delete the Secret as needed.

OperationDescription
UpdateAfter adding or updating a Secret, workloads that have referenced this Secret (or its configuration items) via environment variables need to have their Pods rebuilt for the new configuration to take effect.
Delete
  • After deleting a Secret, workloads that have referenced this Secret (or its configuration items) via environment variables may be impacted due to the inability to find the reference source when rebuilding Pods.
  • Please do not delete the Secrets automatically generated by the platform, as this may prevent the platform from functioning properly. For example: Secrets of type service-account-token that contain authentication information for namespace resources and Secrets in system namespaces (such as kube-system).