Secure your Kubernetes surface
Privileged workloads, cluster-admin bindings, and missing network policy caught at the cluster level. We don’t connect to Kubernetes to collect evidence for its own sake — we connect to secure it, and the compliance artefacts follow from that work.
Book a Demo[01] What This Surface Exposes
Where Kubernetes goes wrong
Kubernetes goes wrong at the workload level: a pod running privileged or a service account bound to cluster-admin undoes every boundary above it.
- Pods running privileged, as root, or mounting the host filesystem
- ClusterRoleBindings granting cluster-admin to service accounts or broad groups
- Namespaces with no NetworkPolicy, leaving east-west traffic entirely unrestricted
- Secrets stored unencrypted in etcd, or mounted into pods that have no need of them
- API server or dashboard reachable beyond the intended network boundary
[02] What We Secure
What we watch, catch and fix on Kubernetes
On Kubernetes we resolve the RBAC graph to show which service accounts can escalate to cluster-admin, and by exactly what path.
- Workload security context audited against the actual need, not against a generic baseline
- RBAC graph resolved to show which service accounts can escalate to cluster-admin and by what path
- Network policy coverage measured per namespace, so an unprotected namespace is visible rather than assumed safe
- Image provenance for running workloads tied back to the registry and the pipeline that built them
- Drift between the manifests in git and the objects actually running in the cluster
[03] Where It Lands
Where Kubernetes lands in your registers
Every cloud resource we discover becomes an entry in your asset register with an owner, a criticality rating, and its data classification. Access reviews cover the IAM principals attached to it, and the risk register carries the mapping between the asset and the risks it actually carries — so a public bucket is a named risk against a named asset, not a line item in a scan report.
[04] How We Engage
On Kubernetes specifically
On Kubernetes, we apply network policies and tighten security contexts in non-production directly, then stage them through your release process for production. Cluster RBAC redesign and admission control rollout we project-manage.
Platform licence
Everything you need to find and fix it yourself, with no ceiling on the depth of the answer.
- Every connected tool monitored for misconfiguration and drift, with findings mapped to the assets and risks they affect
- Remediation guidance that tells you what is wrong and exactly how to fix it — however deep or awkward the issue is. We are engineers running a security company, so the answer is the real one, not a link to vendor documentation
- Assets, access reviews, and risk register populated from the tools themselves rather than from spreadsheets
- Unlimited integrations and unlimited users, with anything missing built within two weeks
Managed service
Every tool you connect through Konfirmity comes under our care, with our team doing the work.
- Continuous misconfiguration and drift monitoring across every connected tool, watched by our analysts rather than by a dashboard waiting for you
- Incident response led by us, with containment coordinated with your team
- Remediation performed directly wherever you have granted us the authority to act — and where we cannot act, we project-manage the fix to completion rather than handing you a ticket
- Decision support on the tools themselves: where something is failing you on capability or costing more than it returns, we will tell you, and help you replace it
[05] Kubernetes FAQs
Does Konfirmity install anything in our cluster?
Konfirmity reads through the Kubernetes API using a ClusterRole scoped to get, list and watch. There is no agent, no sidecar, and no admission webhook, so there is nothing in the request path that could affect availability. Where you want admission-time enforcement we help you configure your own policy controller.
Which Kubernetes distributions do you support?
Konfirmity supports any conformant Kubernetes distribution reachable over the API, including EKS, GKE, AKS, OpenShift and self-managed clusters. Where the cluster sits on a private network we connect through your existing bastion or a scoped egress path rather than requiring you to expose the API server.
Amazon Web Services
Google Cloud Platform
Microsoft Azure
Terraform
Docker