Cloud, Kubernetes & IAM Security Testing
Scoped testing of cloud infrastructure with a read-only-first approach. We assess IAM, storage exposure, network boundaries, DNS hygiene, and Kubernetes permissions without disrupting production systems.
950+ GitHub stars on our AWS security training.
IAM Deep Dive
We model how a compromised service account would enumerate roles, trust policies, and federation paths. That attacker behavior drives our testing: we start read-only, then validate escalation and lateral movement routes with scoped, safe checks.
Example finding
A CI role can assume an admin role in a shared services account through an overly broad trust policy. We document the exact policy chain and the least-privilege fix.
Storage & Public Exposure
We follow the same paths an attacker would use after initial access: enumerate buckets, snapshots, images, and registries to see what is reachable without production disruption. That behavior shapes our testing so exposure is verified safely and tied back to clear access policies.
Example finding
A backup bucket is readable by any authenticated cloud user due to a wildcard policy. We map the policy to the impacted data and the minimum fix.
Network & Perimeter
We model how an attacker would move once a workload is compromised: enumerate security groups, route tables, and egress paths to understand what is reachable. That behavior guides our testing, so we validate inbound exposure, confirm egress guardrails, and trace reachable services without disrupting traffic.
Example finding
A permissive security group and open load balancer listener expose an internal service to the internet. We document the exact rule set and the least-disruptive boundary fix.
DNS Hygiene & Takeover Paths
We trace how an attacker would chain DNS records to external services after a team decommissions infrastructure. That behavior drives our testing: we enumerate records across managed DNS, validate live targets, and confirm which routes could be reclaimed, all without touching production workloads.
Example finding
A stale CNAME points to a decommissioned cloud service. We document the exact record, the takeover path, and the safest cleanup step.
Kubernetes: Attacker-in-a-Pod
We model what an attacker can do after landing in a single pod, then use that behavior to drive our testing. We validate RBAC bindings, service account permissions, secrets access, and lateral movement paths, and we tie every check back to the exact control that keeps cluster scope contained.
Example finding
A default service account is bound to a ClusterRole that allows listing secrets across namespaces. We document the binding chain and the least-privilege fix.
Logging, Detection & Benchmarks
We model how an attacker would avoid detection after initial access, then let that behavior shape our testing. We review audit trails such as CloudTrail and Activity Logs, check retention and centralization, and map CIS benchmark gaps to the specific controls that prevent real-world misuse.
Example finding
Org-wide audit trails are not enabled for a subset of accounts, leaving key actions unrecorded. We document the exact logging gap and the least-disruptive path to centralized coverage.
Cloud, Kubernetes & IAM FAQ
What will the final report include for cloud and Kubernetes?
You receive a structured report with an executive summary plus detailed findings tied to IAM, storage, network, DNS, and Kubernetes controls. Each finding includes evidence, impact context, and remediation guidance so internal reviews are straightforward.
How do you provide evidence without risky actions?
We document the exact configuration or policy path that enables the issue and include safe, reproducible steps. Where possible, we use read-only proofs and targeted validation checks that avoid production disruption.
What access do you need, and how is it scoped?
We start with read-only access and specify any targeted permissions needed for validation. The access list is agreed in advance so your team knows exactly what is required and why.
Do you include remediation guidance for IAM and K8s issues?
Yes. We provide least-privilege fixes, safer policy patterns, and configuration guidance for each finding. The goal is to make remediation defensible and easy to review.
Can you cover multi-cloud and hybrid environments?
Yes. We map scope by provider and account, then document cross-cloud trust paths and federation points so coverage is clear across environments.
Safe next step
Talk through your cloud scope first.
No commitment required.
Share the environments and access boundaries you want reviewed. We will outline a read-only-first plan, confirm what we will and will not touch, and provide a fixed quote if it is useful.
Discuss cloud scopeor view a sample report first