Secret

Kubernetes Secrets store data in a base64-encoded format. This is not an encryption method but a encoding scheme that allows binary data to be stored as a string within YAML or JSON manifests. The primary purpose is to avoid special character interpretation issues, not to provide confidentiality. The data can be easily decoded by anyone with access to the Secret object.

• Example: A password S3cr3t! is encoded as UzNjcjN0IQ==.
• Security Note: Always enable Encryption at Rest for the cluster's etcd datastore to provide actual encryption for Secret data.

Secrets can be consumed by Pods in two primary ways:

• Volume Mounts: The Secret's key-value pairs are presented as individual files within a mounted volume. The file content is the decoded value of the key. This is the preferred method for large or structured data like TLS certificates.
• Environment Variables: Secret values can be injected directly into a container's environment. This method is simpler but less secure for highly sensitive data, as environment variables may be exposed in logs or through debugging tools.

This decoupling allows application configuration to be updated without rebuilding container images.

A Secret can be marked as immutable. Once set, this field prevents any modifications to the Secret's data. This provides significant security and performance benefits:

• Security: Eliminates the risk of accidental or malicious updates to live credentials.
• Performance: Reduces load on the kube-apiserver and etcd, as watches for changes on these objects can be disabled.

To update an immutable Secret, you must delete and recreate it, which typically requires a Pod restart to pick up the new data.

Kubernetes defines several built-in Secret types (via the type field) that trigger cluster-specific behaviors and validations:

• Opaque: The default type for arbitrary user-defined data.
• kubernetes.io/service-account-token: Holds a token identifying a ServiceAccount. Used automatically by the cluster.
• kubernetes.io/dockerconfigjson: Stores credentials for pulling images from a private Docker registry.
• kubernetes.io/tls: Holds a TLS certificate and its private key. Ingress controllers often use this type.
• bootstrap.kubernetes.io/token: Used for node bootstrap during cluster join.

Using the correct type enables integration with other cluster components.

Every Pod is associated with a ServiceAccount. Kubernetes automatically creates and mounts a special Secret of type kubernetes.io/service-account-token into each Pod. This Secret contains:

• The namespace of the Pod.
• A CA certificate for the cluster's API server.
• A cryptographically signed JSON Web Token (JWT).

The Pod uses this token to authenticate to the kube-apiserver based on the RBAC permissions bound to its ServiceAccount. This automates secure API access for in-cluster processes.

While Secrets are safer than plaintext, they are not fully secure by default. Key practices include:

• Enable Encryption at Rest: Configure the EncryptionConfiguration for the kube-apiserver to encrypt Secret data in etcd.
• Limit Access with RBAC: Use Role-Based Access Control to restrict get, list, and watch permissions on Secrets.
• Use External Secret Operators: For production, consider tools like External Secrets Operator or HashiCorp Vault to centralize management and provide rotation, auditing, and fine-grained access policies.
• Avoid Environment Variables for High-Sensitivity Data: Prefer volume mounts.
• Regularly Rotate Credentials: Implement processes to update Secrets and restart dependent workloads.

A Kubernetes API object used to store non-confidential configuration data as key-value pairs. Unlike Secrets, ConfigMaps are not encrypted and their data is stored as plain text. They are consumed by Pods as:

• Environment variables
• Command-line arguments
• Configuration files in a volume

Example Use Case: Storing application feature flags, UI themes, or non-sensitive API endpoint URLs for an edge AI inference service.

An identity for processes running inside a Pod to authenticate to the Kubernetes API server. Each Pod is automatically assigned a default ServiceAccount. ServiceAccounts are tied to RBAC (Role-Based Access Control) roles to define permissions. They are often used in conjunction with Secrets, as the API server automatically mounts a Secret containing a service account token into each Pod. This is fundamental for secure inter-service communication within an edge AI cluster.

A Kubernetes admission controller that can modify incoming API requests before they are persisted to the cluster's data store (etcd). This is a powerful security and automation pattern often used with Secrets:

• Automatically inject Secrets as environment variables or volumes into Pod specifications.
• Rewrite image pull secrets for private container registries.
• Add sidecar containers that handle secret retrieval from external vaults.

This enables a "secure-by-default" configuration for edge AI workloads, ensuring models always have access to necessary credentials without manual Pod specification.

A Kubernetes framework that defines security policies for Pods. The Restricted profile, which is the baseline for production, enforces critical security constraints relevant to Secret usage:

• Prevents privilege escalation.
• Requires the container to run as a non-root user.
• Forbids running containers in privileged mode.
• Mandates the use of read-only root filesystems.

These controls limit the impact of a compromised container that has access to mounted Secrets, a crucial defense for edge AI devices that may be physically accessible.