A friend who runs a small web studio told me about the afternoon she realised her clients’ content management systems were sitting on a cluster with the doors unlocked. Nothing had been stolen. A routine question from a new customer, “who can reach our database credentials?”, simply had no confident answer. That uncomfortable pause is where KubernetesSecOps begins: the everyday job of securing the cluster your sites run on. These are the questions she ended up asking, in the order she asked them.

What does KubernetesSecOps actually cover for a CMS team?

Think of five jobs. Deciding who may change the cluster. Deciding what is allowed to start. Deciding which services may talk to which. Looking after credentials. Noticing trouble. The Ops Atlas, which has a lengthy write-up on KubernetesSecOps, frames the field exactly this way and adds a useful footnote: the label is rarely used, and most documentation calls it Kubernetes security. For a web studio, that means searching under the common name when you need tutorials.

Is a CMS container really a risk? It just serves pages.

Content systems are busy places. They accept uploads, run plugins, talk to databases and often hold an admin login exposed to the internet. If one container is compromised, the interesting question is what it can reach next. By default, the answer in a cluster is “almost everything”, because pods accept connections from other pods until a NetworkPolicy selects them. A WordPress or headless-CMS pod that can talk to a billing service is a problem waiting for a bad plugin.

Where should the database password live?

This question prompted the biggest surprise for my friend. Kubernetes has an object for credentials called a Secret, and the name suggests protection. The Atlas is blunt about it: with no encryption configured, the cluster’s data store holds secrets in plain form, and the base64 you see on screen is merely formatting. It recommends key-management integration and mentions that tools such as External Secrets Operator or a CSI driver can fetch credentials from an external vault so that the cluster holds fewer of them.

Her fix was modest. She turned on encryption, moved the two most sensitive credentials into an external store, and stopped baking passwords into configuration files committed to a repository.

Who should be allowed to run kubectl?

Everyone wanted access in the beginning: the developers, the freelancer, the hosting consultant and the deployment robot. The Atlas’s guidance on RBAC suggests a smaller circle. Sign in through the company’s identity provider, give each person a role scoped to a namespace, and be particularly careful with permissions that look harmless but are not. Listing secrets exposes the credentials themselves. Writing workloads implicitly reaches any service account those workloads use. Opening a shell in a pod is a back door. Members of the built-in system masters group bypass every check, and the Atlas says never to add users there.

Automation gets the same scrutiny. Giving the deployment pipeline full cluster-admin rights is on the Atlas’s anti-pattern list, because whoever controls the pipeline then controls everything.

What stops a developer from deploying something risky?

Admission control. It inspects each new workload and can warn or refuse. Kubernetes ships Pod Security standards with three levels, and the strictest requires containers to run as non-root, forbid privilege escalation and drop extra capabilities. My friend started with warnings only, so developers saw messages on their next deploy rather than outright failures. After roughly two weeks, with an announced date, she switched to enforcement. She kept a short list of exceptions with names and expiry dates, which cleared up a lot of arguments.

One warning she took seriously: enforcement only governs pods created afterwards. Anything already running keeps running, so she scheduled a sweep.

Are namespaces enough to separate client sites?

They help but do not give hard isolation. Pods from different namespaces can share a node and its kernel. If a studio hosts competing clients, or handles data with contractual obligations, the Atlas’s message is to treat namespaces as organisation and permission scoping, and to combine them with network rules, strict pod settings and possibly separate node pools for sensitive tenants.

How would we know if something went wrong?

Logs, and someone reading them. On a self-managed control plane, audit logging does nothing until an audit policy file exists. Some managed services also leave control-plane logs off until they are enabled, so the setting needs checking in your provider’s console. Audit rules are evaluated top to bottom with the first match winning, and the Atlas suggests recording secrets and config maps only at metadata level so the log never contains the values.

For the observability side of the story, our article on building real-time telemetry loops in the cloud pairs well with this one, because detection is only useful if the signals reach a person who can act.

Could a bug in a shared component hurt us?

Yes, and the Atlas has a vivid example. In March 2025 a set of flaws in a widely deployed ingress controller was announced, the worst scoring 9.8 out of 10. Through the admission webhook, an actor on the pod network could take over a cluster, and by default the controller could read all secrets cluster-wide. The recommended steps were to upgrade or disable the webhook. The project was archived in March 2026, so users must plan a migration. The warning the oversight committees attached has stuck with me: without active checking, a team can stay unaware of its exposure until after someone has broken in.

For a CMS studio the practical lesson is to keep an inventory of what runs in front of your sites, note which components are still maintained, and schedule replacement work before a deadline forces it. Our notes on automating cloud operations without losing resilience cover the automation habits that make such replacements less painful.

How much time does this take?

Less than people fear if it is staged. The Atlas suggests a 30-60-90 rhythm. Month one is for looking around: list the namespaces, set warnings, open the audit logs and run a benchmark. Month two is for guarding, which means enforcing the baseline level, trying deny-all networking on a pilot, encrypting credentials and sending alerts to a person. Month three is for verifying, with the strict profile on any new namespace, images pinned by digest, a trial of signature checks and one drill.

What did she change in the end?

Before the list, one thing about tone. She did not announce a security programme or buy a stack of products. She picked the smallest set of changes that answered her clients’ questions, did them in an order that rarely broke anything, and wrote each one down. That restraint is why the changes lasted.

Here is what stuck.

Three things stuck. A calendar entry for a monthly exception review. A one-page diagram showing which services may talk to which. And a habit of answering client security questionnaires with dated evidence instead of adjectives. The next time a customer asked who could reach their credentials, she had a short, specific reply, and the pause was gone.