Application Environment, Configuration and Security

A ConfigMap holds non-sensitive configuration; a Secret holds sensitive data such as passwords or tokens, structured the same way. Both are consumed the same two ways: as an environment variable (env[].valueFrom.configMapKeyRef or secretKeyRef) or as a mounted volume, where each key becomes a file. Neither storage mechanism is exclusive to sensitivity level — a Secret is simply the object Kubernetes treats as sensitive by convention and tooling, not one that's cryptographically protected on its own.

That last point matters more than it sounds: Secret values are base64-encoded, not encrypted. Base64 is a reversible encoding, not a cipher — anyone with API read access to a Secret can decode it in one command. Genuine protection comes from RBAC controlling who can read the Secret at all, plus, if needed, separately configuring encryption at rest for etcd.

Update behavior differs sharply by consumption method. A ConfigMap or Secret consumed as an environment variable is fixed at container start — changing the object later has no effect until the Pod is restarted. One consumed as a volume mount updates eventually: the kubelet checks freshness on its periodic sync, so the total delay is roughly the sync period plus a cache propagation delay. A container using a ConfigMap or Secret as a subPath volume mount never receives updates at all, regardless of how long you wait.

Setting immutable: true on a ConfigMap or Secret — stable since Kubernetes v1.21 — locks its data permanently: the flag itself cannot be reverted, and the data cannot be edited afterward. The only way to change it is to delete and recreate the object, and since existing Pods keep their old mount point, those Pods should be recreated too.

A request is what the scheduler uses to place a Pod — it only schedules a Pod onto a node with at least that much spare capacity. A limit is a hard ceiling: CPU usage above the limit gets throttled, while memory usage above the limit can get the container killed by the out-of-memory handler. These two numbers, present or absent per container, decide a Pod's Quality of Service (QoS) class. Guaranteed requires every container to set both a CPU and a memory request equal to its limit. Burstable covers anything that doesn't meet Guaranteed but sets at least one request or limit somewhere. BestEffort is a Pod where no container sets any request or limit at all.

QoS class decides eviction order when a node runs low on resources: BestEffort Pods are evicted first, then Burstable, and Guaranteed Pods last.

A ResourceQuota is a namespace-scoped object that caps total resource consumption — or total object counts, such as the number of Pods or Services — across everything in that namespace. A namespace-wide quirk worth knowing: once a namespace has a ResourceQuota covering compute resources (CPU or memory), every Pod submitted to that namespace must specify its own requests and limits, or it is rejected outright at admission — the quota can't account for a Pod whose consumption it can't measure.

A LimitRange is a different, complementary namespace-scoped object: it supplies default requests and limits for any container that omits them, and can also enforce per-container minimum and maximum bounds. Where a ResourceQuota caps totals, a LimitRange fills gaps and bounds individual containers.

Every request to the Kubernetes API server passes through three stages in order: authentication (who is making this request), authorization (is that identity allowed to do this — RBAC is the usual mechanism), and admission control (mutating and validating webhooks and built-in controllers that can still modify or reject an already-authorized request). Any stage can stop the request before it reaches etcd.

Every Pod runs as a ServiceAccount — the default one for its namespace if none is specified. How that identity's token reaches the Pod has changed: a long-lived, non-expiring token stored in an auto-created Secret used to be generated for every ServiceAccount automatically; since Kubernetes v1.24, that automatic Secret is no longer created by default. Instead, Pods get a short-lived, audience-bound token delivered through a projected volume — stable behavior since v1.22 — refreshed automatically before it expires.

A securityContext can be set at the Pod level (applies to every container) or the container level (overrides the Pod level for that one container, field by field). Useful fields: runAsUser sets the numeric UID a process runs as; runAsNonRoot: true doesn't pick a UID for you — it only refuses to start the container if the UID it would run as turns out to be root. allowPrivilegeEscalation: false blocks a process from gaining more privileges than its parent had. readOnlyRootFilesystem: true mounts the container's root filesystem read-only. capabilities.drop: ["ALL"], optionally followed by adding back only the specific Linux capabilities actually needed, is the least-privilege pattern for capabilities.

If a Pod never talks to the Kubernetes API at all, automountServiceAccountToken: false — set on the Pod or its ServiceAccount — stops a token from being mounted into it in the first place, removing a credential the Pod has no use for.

A CustomResourceDefinition (CRD) registers a brand-new kind of object with the Kubernetes API, under apiextensions.k8s.io/v1 — the older v1beta1 version stopped being served as of Kubernetes v1.22, with v1 available since v1.16. Once a CRD is registered, instances of that kind — custom resources — can be created, read, updated and deleted with kubectl exactly like any built-in object, validated against the schema the CRD declares, and stored in etcd the same way.

On its own, that's all a CRD does: define a schema and a place to store structured data. Nothing watches it, and nothing acts on it — creating a custom resource with no controller behind its CRD just stores data, with no operational effect whatsoever.

An Operator is a custom controller that watches instances of a CRD and reconciles real state to match what they declare — a database operator, for example, watching BackupSchedule objects and actually creating the Jobs, volumes or external API calls needed to make backups happen on that schedule. The CRD defines what — the shape of the data. The operator's controller defines what to do about it. A CRD without a controller is inert data; the operator is what turns a custom resource into something that actually does something in the cluster.