ACSETalk to us
  1. Home
  2. Clouds
  3. Kubernetes

Kubernetes

Fix the workload in the manifest, not in the cluster.

ACSE checks the security settings of the workloads running in your clusters and the managed cluster settings around them. When something is wrong, it changes the source your team owns, whether that is plain YAML, a Helm values file or a Kustomize overlay, and dry-runs the change before anyone reviews it.

Talk to usSee how it works
Kubernetes, fixed in the manifestA cluster of three nodes with their pods. One pod runs a privileged container; the fix is a patch to its manifest.privileged containerMANIFEST PATCHsecurityContext:- privileged: true+ privileged: falseCLUSTER · NODES · PODS
01

No drift between cluster and repo

The fix lands in the manifest that deploys the workload, so the next rollout keeps it instead of undoing it.

02

Changes that apply cleanly

Every patch is dry-run against a pinned Kubernetes API schema before it reaches review, so your team sees a change that will be accepted.

03

One review for every estate

A privileged container goes through the same approval, verification and evidence as a public bucket.

What ACSE checks

The settings that widen a breach

A workload that asks for more than it needs widens what an attacker gets if it is compromised, and what a runaway job can take from its neighbors.

01

Privilege

Privileged containers and containers that allow privilege escalation.

02

Identity in the container

Containers that run as root instead of a non-root user.

03

Filesystem

Containers whose root filesystem is writable when it does not need to be.

04

Resource limits

Containers with no CPU or memory limits, which can starve the rest of the node.

05

Managed cluster settings

On Amazon EKS: a public API endpoint, control-plane audit logging and encryption of Kubernetes secrets.

06

Exceptions with an expiry

A workload that truly needs a privilege gets an approved exception with an owner and an end date, labelled wherever it appears.

From finding to pull request

How a Kubernetes fix is made

Fixes come from remediation directives, rules that describe the change, applied by a deterministic engine. No model edits your manifests at runtime.

  1. Find the sourceACSE resolves which repository and file deploy the workload: a plain manifest, a Helm chart’s values or a Kustomize overlay.
  2. Write the changeThe directive for that check becomes a JSON or strategic merge patch, applied to the exact field that needs to change.
  3. Dry-run itThe patched manifest is validated offline against a pinned Kubernetes API schema, so an invalid field never reaches review.
  4. Open a draft pull requestThe change opens as a draft at the exact commit. A person approves it with MFA, and your team merges as usual.
A fix you can readA storage bucket shown as an exploded drawing. Versioning and encryption are already in place; the public access block is the change ACSE proposes, as a draft pull request.VERSIONINGenabled · checkedPUBLIC ACCESS BLOCKthe fix · in a draft prDEFAULT ENCRYPTIONaws:kms · checkedaws_s3_bucket.data

Evidence

Proof that the fix held

After your pipeline rolls out the change, ACSE re-reads the workload, records the outcome and watches for regression through an observation window.

Every step, from the finding to the approval to the verified state, is signed and chained in a store you own. An auditor can check it offline with no ACSE account.

The record lives with youRecords for a finding, the proposed fix, the decision, the merge and the verification are chained, each holding the hash of the one before, and written to append-only storage in the customer’s own account.YOUR ACCOUNTobject lock · append-onlyfindingproposaldecisionmergeverifiedeach record holds the hash of the last

Questions

What people ask us

Does ACSE run anything inside my cluster?

No. ACSE reads workload and cluster configuration through the Kubernetes API with a read-only identity, and delivers fixes to your repositories. It does not install agents, admission controllers or sidecars.

Does ACSE scan container images?

No. ACSE checks configuration, not image contents or vulnerabilities. It works alongside the scanners you already use.

What if a workload needs to run privileged?

Request an exception. Once approved, it carries an owner, an approver and an expiry, and it is labelled in every view. When it expires, the finding reads open again without anyone acting.

Which managed Kubernetes services are covered?

Amazon EKS cluster settings are checked through the AWS pack. Workload checks apply to any conformant cluster ACSE can reach with a read-only identity.

Keep reading

Related

Platform

Fix

ACSE turns a cloud misconfiguration into a validated pull request in your own Terraform, generated by rules and approved by a person. Never auto-merged.

ReadLearn

Policy as code

Policy as code makes security rules versioned and testable. Learn where policies run, a healthy lifecycle, the common pitfalls and how to simulate first.

ReadClouds

AI infrastructure

ACSE checks the cloud configuration around AI: GPU node pools, model and training-data storage, network exposure and the identities that reach them.

Read

Talk to us

See ACSE on your cloud.

Tell us what you run and what your auditors ask for. We’ll show you the loop end to end: a real finding, a fix as code, an approval with MFA and the sealed record.

Talk to usExplore the platform