Few areas of technology collect folk wisdom as fast as container security. Teams inherit rules of thumb from conference slides, vendor pages and half-remembered incidents, and then act on them as if they were measured facts. This article tests six popular beliefs about KubernetesSecOps, the day-to-day practice of securing clusters and the workloads on them, against what a careful reference source actually says. Where a claim rests on a survey or a worked example, I say so.
The main source is the Ops Atlas page called KubernetesSecOps in the Atlas, a long entry that is candid about the fact that the label itself is barely used and that most practitioners search for “Kubernetes security” instead. That honesty is a good place to start, because it removes the first myth for free.
Myth 1: “KubernetesSecOps is a job title or a certification”
It is neither. The Atlas is explicit that the phrase names a body of work, not a role and not an exam. The credential people usually have in mind is the Certified Kubernetes Security Specialist exam, which builds on the administrator certification. If a job advert asks for “KubernetesSecOps certified” candidates, the advert is confused, and a candidate who has the security specialist credential is probably what it wants.
Evidence rating: strong. This is a definitional point and easy to verify against the Kubernetes documentation’s own security section.
Myth 2: “Base64 in my secrets means they are protected”
Base64 is a way of representing data as text. Anyone can reverse it in a second, and the Atlas states plainly that it is not an encryption method. Worse, unless an administrator enables encryption at rest, Secret objects sit unencrypted in the cluster’s data store. The recommended route is a key-management integration; the first version of that mechanism was deprecated in release 1.28 and disabled by default in 1.29, so teams that configured it years ago should check which version they run.
One subtle wrinkle: if the “identity” provider remains in the list of encryption options, data written before encryption was switched on stays readable. Turning encryption on protects new writes, and old data needs rewriting.
Evidence rating: strong, with a practical caveat about rewriting existing objects.
Myth 3: “Namespaces isolate teams from each other”
They separate names and scope permissions, which is valuable. They do not give hard isolation, because pods in different namespaces can land on the same node and share a kernel. The Atlas treats namespaces as an administrative boundary and recommends adding network rules, stricter pod settings and, where the stakes justify it, separate node pools or clusters.
A related, more recent development is user namespaces, which the Atlas lists as stable from release 1.36. They reduce what a compromised container can do on the host, but they are a mitigation layered on top, not a replacement for planning isolation.
Evidence rating: strong for the sharing-a-kernel point, moderate for how much any given mitigation reduces risk in your setup.
Myth 4: “If a scan of my permissions comes back clean, the cluster is clean”
Scanning tools that analyse RBAC are useful, yet the Atlas lists real blind spots. Some ignore API groups or the specific resource names a grant refers to, and others cannot see the indirect routes that exist through operators, where a controller with broad rights acts for a user with narrow ones. Writing to workloads, for instance, implicitly gives access to any service account those workloads use, and through it to secrets.
The honest summary is that a clean run is a good sign and not a proof. Pair it with a manual look at the riskiest permissions: listing secrets, opening shells in pods, impersonation, approving certificate requests and editing admission webhook configurations.
Evidence rating: moderate. It depends on which scanner you use, so test your own tool against a deliberately over-permissive account.
Myth 5: “Block every vulnerable image at the door and you are safe”
It sounds rigorous and fails in practice. Among the anti-patterns the Atlas lists is rejecting every image that a scanner flags at admission time. Findings change daily, many flagged issues are unreachable in a given workload, and an admission webhook that blocks on a scoreboard will eventually block an urgent fix or a rollback. Admission is better used for stable, checkable properties: images pulled by digest, signatures present, pod settings within bounds.
The Atlas also separates this from pipeline work. Signing and scanning belong earlier, in the delivery pipeline; the cluster verifies at admission because people can run kubectl or Helm and skip the pipeline altogether.
Evidence rating: moderate. This is a design recommendation, not an experiment, but it matches how rollouts fail in the wild.
Myth 6: “Our policy engine is enforcing, so everything running is compliant”
Three things undermine this. Enforcement applies to pods as they are created, so anything already running stays running. Rules written against a Deployment instead of the pods it creates may not trigger as intended. And a webhook that fails open lets requests through whenever it is unavailable, while one that fails closed can stall the cluster. The Atlas notes that, as of October 2026, one widely used engine defaults to closed and another to open, so this must be a deliberate configuration choice, made per tier of risk.
The sensible workflow it describes runs from audit mode, to warnings with an announced date, to enforcement, with an exception register where every entry expires.
Evidence rating: strong for the mechanics, since they follow from how admission works.
What the numbers can and cannot tell you
The Atlas includes a worked example from an imaginary estate of 46 workload namespaces: 40 at baseline level or above (87.0 percent), 22 at the restricted level (47.8 percent) and 31 with default-deny networking (67.4 percent). These are illustration, not benchmarks. Use the method, counting coverage per namespace, rather than the percentages as a standard to meet.
A 2024 vendor survey of 600 people is also quoted there. Roughly two thirds said security worries had held back a release, and close to nine out of ten admitted to an incident during the preceding twelve months, whether at runtime, in the build and deploy stage, or through misconfiguration. Self-reported answers from a small, commissioned sample deserve a modest weight. They show the problem is common without telling you how common it is for a company of your size or in your sector, and they say nothing about severity. Treat the figure as a prompt to look at your own incident log, not as a target or a comparison point.
A quick scoring sheet for your own beliefs
- Write down the three security claims your team repeats most often.
- For each, name the artefact that would prove it: a configuration export, a log line, a test result.
- Mark claims with no artefact as “assumed”, and schedule a check for each.
For more on turning claims into checks inside a services business, see the piece on a roadmap for onboarding clients to digital services, and for the planning mindset behind it, the earlier article on mastering growth planning step by step.
The common thread in all six myths is a preference for the comfortable explanation over the measured one. The discipline rewards the opposite habit: ask what a default actually does, check whether a control covers what you think, and write the answer down with a date.
