Cloud, Kubernetes and IaC

Almost no cloud breach you read about in the press comes from an exotic exploit. It comes from an IAM role with a wildcard set in a hurry, a secret forgotten in CI history, a misconfigured bucket or a service account that can, through three individually harmless steps, become administrator. Automated tools see each one separately and classify them “low.” The value comes from putting them together — and that requires someone who understands how privileges chain in a real account.

What we assess

• Configuration posture against CIS Benchmarks (AWS/Azure/GCP, Kubernetes, Docker) and NIST 800-190, then manual review of what tools classify as low but chains into real impact
• Identity and privileges — the core of cloud risk. We map who can become what: trust policies, cross-account roles, AssumeRole chains, wildcard permissions, over-privileged service accounts, OIDC federation. We don’t give you a permission list — we give you the graph “from role X, an attacker reaches admin”
• Kubernetes — from three angles, as in a real attack: external, from a compromised pod and from the control plane. We check RBAC, admission control (OPA/Gatekeeper, Kyverno), Pod Security Standards, network policies, secrets, exposed components (kubelet, etcd, dashboard), privileged pods and hostPath
• Containers and images — CVEs in the base image, containers running as root, embedded secrets, unpinned tags, SBOM
• Pipeline secrets — in code and in CI/CD history; runner identity, OIDC trust toward cloud, artefact signing
• IaC — Terraform, CloudFormation, ARM/Bicep, Helm; and the drift between what’s declared in code and what’s actually in production (manual changes, “just this once”)

What you get

• Posture report mapped to CIS/NIST, with severity and exploitability — not a scanner export
• IAM privilege escalation graph, with concrete demonstrated paths
• Kubernetes attack narrative (foothold → lateral movement → cluster-admin)
• Prioritised remediation, with IaC-level fixes and guardrail recommendations (policy-as-code), so the same mistakes don’t come back on the next deploy