Skip to content
04 Defensive

Kubernetes & Cloud-Native Security

Cluster hardening, CIS benchmarks, admission control, supply-chain security, and runtime defense. CKS-led.

What we put our name behind

CKS-led, with a rollback plan on every control change

Every engagement is led by a Certified Kubernetes Security Specialist, with findings scoped to specific namespace, pod, and cluster resources — not generic "tighten RBAC" advice. Every control change we recommend ships with a tested rollback plan, so your platform team can apply it in production without flying blind.

Overview

Kubernetes gives you a lot of rope. Defaults are friendly to developers, not to security teams, and every managed offering (EKS, GKE, AKS) hands you a different subset of controls to configure. Most clusters we audit have at least one finding in the critical range within the first hour — over-permissive service accounts, exposed dashboards or legacy kubelet read-only ports on older nodes, unsigned images, or admission controllers that never got enabled.

We audit Kubernetes clusters the way a CKS is trained to: CIS Benchmark as the baseline, then layered controls for the gaps the benchmark doesn't cover. RBAC least-privilege, admission control via OPA/Gatekeeper or Kyverno, network policies, supply-chain hardening with Sigstore and SBOMs, runtime defense, and secrets management. We don't just hand you a scanner report — we hand you a prioritized remediation plan your platform team can actually execute.

What's included

Every engagement is senior-led and scoped in writing before kickoff.

01

CIS Kubernetes Benchmark assessment

Automated scanning with kube-bench plus manual review of every deviation. We tell you which findings are genuinely risky and which are benchmark noise for your environment.

02

RBAC & least-privilege review

Full audit of ClusterRoles, Roles, and their bindings. We flag every service account with more permissions than its workload needs, and give you a concrete plan to tighten them without breaking deployments.

03

Admission control & policy

Review of admission controllers, Pod Security Standards enforcement, and policy engines (OPA/Gatekeeper, Kyverno). If you don't have one, we'll help you pick and deploy it.

04

Network policy audit

Every namespace should have default-deny. Most don't. We map actual workload communication, then generate NetworkPolicies that enforce it without breaking anything.

05

Supply-chain security

Image provenance, SBOM generation (Syft), signing with Sigstore/cosign, verification with admission policies, and dependency vulnerability scanning in CI.

06

Runtime defense

Falco rules tuned to your workloads, eBPF-based runtime tooling evaluation, and incident-response playbooks for cluster-level compromises.

07

Secrets management

Review of Kubernetes Secrets usage, External Secrets Operator, sealed-secrets, and integration with cloud KMS. Includes a plan to eliminate plaintext secrets in manifests and Git.

What you get

  • CIS Benchmark compliance report with risk-rated deviations
  • RBAC least-privilege remediation plan with concrete manifests
  • Admission control policy pack ready to deploy
  • Network policy templates for every namespace in scope
  • Supply-chain hardening runbook (signing, SBOM, verification)
  • Executive summary for leadership
  • Verification retest of every critical and high finding, completed within 60 days of report delivery (request by day 45)

Ideal for

  • Platform teams scaling past the "it works" stage into "it's secure" stage
  • Companies preparing for SOC 2, ISO 27001, or PCI audits with Kubernetes in scope
  • Engineering orgs that inherited a cluster from a previous team and want an honest review
  • Teams adopting GitOps who need secure-by-default cluster baselines

Frequently asked

Do you support managed Kubernetes (EKS, GKE, AKS)?
Yes. All three. Each has a different set of cloud-provider controls (IAM integration, managed add-ons, node groups) that get reviewed alongside the standard Kubernetes posture.
How is this different from running kube-bench ourselves?
kube-bench is table stakes. It catches benchmark deviations but can't tell you which deviations matter for your environment, which ones are false-positives in a managed offering, or how to actually fix the ones that do matter. We start where the scanner stops.
Can you also do pentesting on our cluster?
Yes — we combine cluster hardening (defensive) with cluster pentesting (offensive) in a single engagement when requested. You see the posture gap from both sides.
Will this break our workloads?
No. Every policy we recommend is rolled out in audit mode first, observed for at least a week, and only enforced after we've verified no legitimate traffic is being blocked. We've done this enough times to know where the sharp edges are.

Ready to scope a kubernetes security engagement?

A 30-minute call with a senior specialist. Written scope before kickoff. No SDRs.