Book a consultation

Cloud Security

Kubernetes and Container Security Consulting

We harden Kubernetes platforms against a documented standard — RBAC, network policy, pod security, admission control, secrets, image provenance and runtime visibility — and leave your platform team with policy as code they can maintain.

The problem we solve

Kubernetes defaults optimise for getting workloads running, not for containing them. Flat pod networking, permissive RBAC, containers running as root and mounted service account tokens are all normal until someone deliberately changes them.

Container images compound the problem. Base images go stale, builds pull unpinned dependencies, registries accept anything that can authenticate, and nothing verifies that the image running in production is the artefact the pipeline actually built.

When something does go wrong, most teams have no runtime visibility inside the container and no audit trail granular enough to reconstruct what happened.

Kubernetes security is mostly a configuration and supply-chain problem. The clusters that hold up under scrutiny are the ones where the hardened configuration is expressed as code, enforced at admission, and reapplied every time a new cluster is created.

Our approach

Adapted to your environment and constraints — but the shape of the work is consistent.

  1. Assess against a real benchmark

    We review the cluster against the CIS Kubernetes Benchmark and the relevant managed-service benchmark for EKS or GKE — control plane configuration, API server exposure, etcd encryption, node hardening, audit logging and add-on posture.

  2. Tighten identity and isolation

    RBAC review to remove cluster-admin sprawl and wildcard verbs, service account token hygiene, namespace and tenancy boundaries, Pod Security Admission or equivalent, and cloud IAM binding via IRSA or GKE Workload Identity rather than node-level credentials.

  3. Control traffic

    Default-deny NetworkPolicy with explicit allow paths, ingress and egress control, service mesh mTLS where it earns its complexity, and protection of the control plane and metadata endpoints.

  4. Secure the image supply chain

    Minimal and pinned base images, build-time vulnerability scanning with a severity policy, SBOM generation, image signing, and admission control that refuses unsigned or non-compliant images — Binary Authorization on GKE or an OPA Gatekeeper / Kyverno policy set elsewhere.

  5. Add runtime visibility

    Kubernetes audit log collection and alerting, runtime threat detection, drift detection between the deployed and declared state, and incident response runbooks for cluster-level events.

Expected outcomes

What changes as a result of the engagement.

  • Clusters measured against a benchmark, with gaps closed and tracked
  • cluster-admin and wildcard RBAC reduced to a small, reviewed set
  • Default-deny networking with explicit, documented allow paths
  • Only signed, scanned, policy-compliant images admitted to production
  • Cloud credentials bound to workloads rather than nodes
  • Runtime detection and audit logging that supports investigation
  • Guardrails enforced as policy as code, not tribal knowledge

Typical deliverables

Confirmed in the proposal before work starts, and adjusted to scope.

  • Kubernetes security assessment against CIS benchmarks
  • Cluster hardening plan with prioritised remediation
  • RBAC model and reviewed role definitions
  • NetworkPolicy set and segmentation design
  • Admission control policy pack (Gatekeeper or Kyverno)
  • Container image build and hardening standard
  • Image signing, SBOM and provenance pipeline design
  • Secrets management design for cluster workloads
  • Runtime detection and audit logging configuration
  • Kubernetes incident response runbooks

What this covers

The specific capabilities available under this service. Engagements usually draw on a subset — we scope to the problem, not the catalogue.

Cluster hardening

  • CIS Kubernetes Benchmark assessment
  • Control plane and API server hardening
  • etcd encryption at rest
  • Node and OS hardening
  • Kubernetes audit logging
  • Managed service configuration (EKS / GKE / AKS)

Workload isolation

  • RBAC least-privilege design
  • Pod Security Admission
  • Namespace and multi-tenancy design
  • NetworkPolicy default-deny
  • Service mesh and mTLS
  • Resource limits and quota policy
  • IRSA / GKE Workload Identity

Image supply chain

  • Base image standards and pinning
  • Image vulnerability scanning policy
  • SBOM generation
  • Image signing and verification
  • Binary Authorization
  • Registry access control
  • Admission control (OPA Gatekeeper, Kyverno)

Runtime

  • Runtime threat detection
  • Drift detection
  • Secrets management (External Secrets, Secret Manager)
  • GitOps deployment security
  • Cluster incident response runbooks

Who this is for

  • Platform teams operating EKS, GKE, AKS or self-managed clusters
  • Engineering organisations running multi-tenant Kubernetes
  • Teams adopting Kubernetes as part of a cloud modernisation programme
  • Companies whose auditors have asked how container workloads are isolated

Recognise your situation? A 30-minute discovery call is the fastest way to find out whether this is the right engagement.

Book a security consultation

Common questions

We use a managed service. Isn't the cluster already secure?

Managed services secure the control plane, not your configuration. RBAC, network policy, pod security, image provenance, secrets and workload identity remain your responsibility under the shared responsibility model, and those are where most real findings sit.

Gatekeeper or Kyverno?

Either works. Kyverno is usually faster for teams that want policies in YAML; Gatekeeper suits organisations already invested in Rego and OPA elsewhere. We recommend based on what your platform team will realistically maintain.

These engagements are often scoped together — the underlying risks overlap.

DevSecOps & AppSec

DevSecOps

Build security into the delivery pipeline instead of bolting it on at the end — secure SDLC, CI/CD hardening, IaC scanning, supply-chain controls and guardrails engineers will actually keep.

Cloud Security

GCP Security

Google Cloud security architecture, IAM and organisation policy, VPC design, Security Command Center, Workload Identity and GKE hardening — built and maintained as code.

Cloud Security

AWS Security

Secure AWS architecture, least-privilege IAM, detection with GuardDuty and Security Hub, and posture management that keeps multi-account estates defensible as they grow.

Discuss your security challenges

Tell us what you are trying to secure and where it hurts. We will tell you what we would do first, whether or not you engage us.

Book a security consultation Explore our services