Kubernetes Security Automation: Kubesec and Kube-bench

Kubesec: what manifest analysis finds before deployment to the cluster

Kubesec is static analysis of Kubernetes configuration: descriptions are checked before deployment to the cluster, not after an incident.

The tool reads a manifest the same way the API server would, and returns a risk score with the specific field indicated — from privileged: true to hostPath to the node root.

Excess container permissions are almost invisible in a diff: a securityContext line or an added capability looks like an ordinary setting.

In practice, such a pod becomes an entry point to the node — through a mounted runtime socket or the root filesystem, then the chain continues with the service account token and the API server.

No less significant is the absence of limits.

Without requests and limits, a single memory leak evicts neighboring workloads; without readOnlyRootFilesystem, code loaded into the container survives a restart; automountServiceAccountToken by default injects a token where it is not needed.

Review misses this for a clear reason: manifests come from charts, generators, and copy-paste, changes arrive in batches, and the check relies on one engineer's attention.

Our engineers describe it this way: "the set of defects repeats from release to release — only the service names change."

Kubernetes manifest checking removes exactly that repetition: every description gets a numeric threshold and a return code, so the rule is embedded in the build pipeline and stops deployment before the pod reaches the cluster. We explain how this is configured for your process and which thresholds are worth fixing.

What automated cluster security checking provides

Automated security checking shifts control left: the container description is assessed before it reaches the cluster. Manifests are checked by Kubesec, node and control plane settings are compared against baseline profiles via kube-bench. Both checks are embedded in the build pipeline and block rollout on a critical finding.

What exactly is checked automatically

Cluster configuration auditing covers container permission control: running as a non-privileged user, prohibiting privilege escalation, dropping unnecessary kernel capabilities, restricting system calls.

Mounting node directories and access to the runtime socket are checked separately — a common container escape path.

The second layer is description hygiene: configured resource limits and requests, read-only root filesystem, service account binding, network policies, and secret access rules.

How this affects releases

The share of rollouts reaching the cluster without configuration findings grows to 9 out of 10: critical findings are caught during description review, not in production.

The analysis itself speeds up — the engineer looks at a prioritized report instead of reading the manifest line by line.

A class of failures due to excess permissions goes away: a container reading others' secrets or mounting a node directory simply does not reach the environment.

The reduction in incidents is also visible in triage speed: the report is tied to a configuration change, so the cause of a rollback is found in minutes, not hours of log searching.

Approaches to checking: Kubesec, baseline reconciliation, policy admission

Approaches to checking differ not in strictness but in trigger point: manifest analysis before apply, live node audit, admission at cluster entry. This determines whether the tool catches an error before rollout or records it already in a running environment.

Static analysis of descriptions

Kubesec reads a pod's YAML description and assesses the fields that add up to risk: privileged mode, host directories, missing readonly-rootfs, extra capabilities.

A threshold in the build pipeline cuts off such a manifest before apply, but the check sees only the file itself — API server defaults and the actual state of nodes remain outside it.

Reconciliation with baseline requirements

kube-bench runs CIS baseline checks separately by component — API server, kubelet, etcd — and shows deviations from the baseline profile.

This is an audit after the fact: it does not prevent a change, but records that settings have diverged from the baseline, and some checks require access to node files and processes.

Description analysis gives quick feedback to the author, policy admission secures cluster entry, baseline reconciliation catches configuration drift, and the checklist remains for what cannot be formalized.

How the process of implementing checks into the cluster is structured

Implementing checks into the cluster is a sequence of work where the scanner is connected last. First you need to understand what is already deployed and which rules are applicable at all, otherwise the report produces hundreds of findings, half of which are noise. Below are the setup stages we go through in this order.

Preparation: inventory and rule scheme

1. Cluster inventory: we collect all resource descriptions — manifests from the repository, charts, manually created objects. We record where the source of truth is and where discrepancies have accumulated between the repository and the live cluster.
2. Rule scheme: we define the control level — warning only or change blocking — check priorities, and exceptions for system namespaces. Kubesec analyzes descriptions statically, so we formulate rules independently of what happens in the running cluster.

Checking against real releases

• Checking against historical releases: we run the rules on past versions of descriptions. This shows what will break on rollback or re-apply — without this step, checks catch only new changes.
• False positive triage: we discuss each disputed rule with the team and record exceptions in the configuration. The goal is not zero findings, but zero findings that no one intends to fix.
• Pipeline integration: checks run during build and before applying changes, with a clear return code and a link to the specific place in the description.
• Handover to the team: documentation on rules, the procedure for adding exceptions, and analysis of common errors — so checks work without our involvement.

What stays in your perimeter: policies, schemes, procedures

Running checks ends with a report, but the value appears later: when rules, access controls, and procedures live with your team as working artifacts. Below is what exactly stays in the perimeter after implementation and how to use it without a contractor.

Policies and admission rules

• Manifest checking rule profile: prohibition of privileged containers, mounting node directories, and running as superuser — with thresholds at which rollout stops rather than receives a warning.
• Cluster admission rules: which namespaces are available to teams, what cannot be created directly, what restrictions apply to images and resource limits.
• Role and permission scheme: roles, bindings, service accounts — a separate minimum for the on-call engineer and for the build pipeline.
• Temporary exception procedure: each has an owner, reason, and review date, otherwise the exception turns into a permanent deviation.
• Node and control plane checking rules: baseline settings and the list of deviations you have consciously accepted as permissible.

Documentation and incident response procedure

• Checking procedure: what is run, how often, who reviews the report, and within what timeframe the finding is closed.
• On-call shift instructions: how to read a finding, what blocks rollout, whom and when to escalate to.
• Run and finding log: dates, statuses, owners — it shows dynamics, not a one-day snapshot.
• Team documentation: how to add a rule, update the check profile, connect a new repository.

Case: how releases changed after implementing checks

A product team with a dozen services kept security on manual review: manifests were read by eye, cluster nodes changed without formal acceptance. Implementation took three weeks — from workload inventory to enabling blocking rules in the mandatory build path.

What it was like before implementation

Configuration defects were found late and at different stages. Containers ran with excessive permissions, resource limits were not set, host directories were mounted inside.

Every fourth rollout was rolled back, manifest review took 40–60 minutes, and there were about nine operations findings per release.

What changed after

Two independent steps were added to the path: static manifest analysis via Kubesec with a score threshold and blocking of critical rules, and regular reconciliation of node configuration with an industry security profile.

The report points to the specific manifest line and goes to the change author before merge, not after an incident.

Two months later, the share of defective rollouts fell from 24% to 4%, the number of findings per release — from nine to two, and review time dropped to 10–15 minutes. Rollbacks became isolated, and configuration incident triage no longer required a separate meeting.

"Checks stopped being a ritual: an engineer sees a violation and fixes it before merge, not while analyzing the consequences," — Operations Director.

How Kubesec differs from Kube-bench and when each is needed

Kubesec and Kube-bench cover different scopes of checks. Kubesec reads object descriptions — YAML or a rendered Helm template — and assesses what is visible before deployment: privileged containers, hostPath, securityContext, missing resource limits. The output is a risk score and a list of specific lines that reduce it.

Kube-bench comes from the other side: it reconciles the actual settings of running nodes and control components with the requirements of an industry standard. It checks startup parameters, permissions on configuration files, kubelet settings, access to the state store.

It is run as a job in the cluster or directly on the node — that is, it reflects reality, not intent.

The difference between the tools is not in strictness but in the control point. Kubesec is a build-time rejection: a manifest with a privileged container simply will not pass the check.

Kube-bench is a report on environment state that shows settings have diverged after manual intervention or a node update.

Choosing a tool for the task is determined by which class of failure is more impactful. To keep risk out of the cluster, start with Kubesec. To confirm compliance with requirements and catch configuration drift, start with Kube-bench.

In practice, both stand in the same process: the first checks what we are about to deploy, the second checks what is already running.

Doubts about automated checks: load and false positives

Automated security checks work at two points: manifest analysis before apply and reconciliation of node configuration with a baseline profile (Kubesec and kube-bench).

These are different contours with different impact of error, so they should not be enabled as a single rollout step.

In practice, implementation rests on four questions — from false positives to who drives findings to resolution.

Will checks slow down the rollout process?

Manifest analysis is file reading without calls to the control server; the addition to the step is measured in seconds. Node reconciliation runs on a schedule, outside the release window, and does not overlap with rollout.

Will it work on an already deployed cluster?

Yes: the agent is installed on nodes, analysis is connected to the pipeline, and services do not need to be rebuilt. The first pass provides an inventory — how many containers have extended permissions, who writes to node directories, where limits are missing. The profile is tightened gradually, by groups, so as not to stop running services.

Who fixes what is found?

The platform team maintains rules, templates, and the exception list; each service's development team fixes its own manifests. Findings become tasks prioritized by risk type, and repeated violations are cut off during analysis — before they reach the cluster.

Let's discuss the task and come back with a cluster check plan

So that the check plan relies on the real configuration rather than a standard template, we start with a conversation about the task. We need to understand which workloads live in the cluster, who has access to the API, and how image build and deployment are structured. This is enough to separate checks that reduce risk from those that only create noise.

Then we fix the scope of work and the collaboration procedure: what we do, where your engineers are needed, and at which points we coordinate changes. Below is what we clarify at the start and what you receive after the conversation.

• We clarify the current state: where manifests are stored, who makes changes, and whether there is control at the image build stage.
• We review requirements: internal security policies, industry standards, and the allowed window for production changes.
• We agree on the check plan: Kubesec — manifests and images, kube-bench — node and control plane settings; what goes into the mandatory set and what goes into monitoring mode.
• We provide an assessment of the work by stage: scope, sequence, dependencies — with no hidden items.
• We describe the collaboration procedure: access and roles, change procedure, coordination points, reporting format.
• We document handover of the result: check configurations in your repository, embedded in the build pipeline, documentation on triaging findings.

Describe the task — we will come back with an assessment and a check plan for your cluster.