Kubernetes Assurance
Cluster posture across EKS, AKS, GKE and OpenShift — security, reliability and the configuration drift nobody notices until it bites.
Runs today, on Google Cloud
Connect a Google Cloud project and this module reads it. Today that means:
- GKE control-plane endpoint exposure
- Node auto-upgrade and auto-repair on every node pool
- Workload Identity, cluster by cluster
- Shielded nodes and other node hardening
It reads Google Cloud only, not AWS or Azure, and it does not track remediation. Everything further down this page is where the module is going, not what it does now. The wider review is work we do as an engagement — Kubernetes Health Check.
Why this module exists
Clusters accumulate. Each one is configured slightly differently, upgrades slip, and nobody can answer which of them would survive a node failure at 3am.
What it is being built to surface
Descriptions of intent. No findings exist yet, because nothing is connected yet.
Cluster inventory
Every cluster, its version, and how far behind support it has drifted.
Security posture
RBAC breadth, privileged workloads, network policy coverage, admission control.
Reliability signals
Missing probes, absent resource limits, single-replica workloads carrying production traffic.
Cost and waste
Over-requested workloads, idle nodes, and cost attributed to the team that caused it.
What the module covers
- Cluster inventory and configuration hygiene
- RBAC, network policy and security posture
- Resource limits, probes and reliability signals
- Upgrade readiness and cost optimisation
Tell us what this would need to catch
We are designing this against real environments. If this is a problem you have, the fastest way to shape it is a conversation with the engineers building it.
Talk to an Engineer