Cloud & Kubernetes security assessment

Find out what one leaked key or one compromised container can reach.

Your cloud accounts and clusters are reviewed in two layers: a read-only look at how everything is configured, then hands-on testing from an agreed starting point, such as a leaked access key or a compromised pod, to see how far it actually gets.

Discuss my scope

What’s tested

AWS · Azure · GCP · EKS · AKS · GKE · self-managed

What the cloud and Kubernetes assessment covers
Starting point	A read-only review, then hands-on testing from one leaked key or one compromised pod
You provide	A read-only role and kubeconfig, an architecture overview and a test pod
We test	Who can do what IAM privilege escalation · role chaining Trust between accounts cross-account trust · SSO · CI/CD credentials Exposure and storage public endpoints · bucket policies Secrets env vars · images · metadata service Inside the cluster RBAC · service-account tokens Isolation network policies · namespaces Container escape privileged pods · host mounts Container to cloud IRSA · workload identity
The goal	How far one leaked key or one compromised pod gets
Based on	CIS Benchmarks for AWS, Azure, GCP and Kubernetes
You get	Critical findingsreported straight away Reportevery attack path, the exact resource and policy to change Readout and retesta call, then one retest after your fixes

Read-only review; hands-on steps only from agreed starting points.

What a finding looks like

Each attack path is shown step by step, with the exact resource and policy to change, so the fix that breaks the path is obvious.

What every report contains →

Critical CLOUD-01

The web app’s pod can read every secret in the cluster

cluster prod · namespace web · serviceaccount web-app

Impact: Whoever compromises the public web app gets the database passwords and cloud keys of every other service.
Proof: From a shell in the web pod, its mounted token listed and read secrets in all namespaces, including payments.
Fix: Bind the service account to a role limited to its own namespace and the secrets it needs, and stop mounting tokens in pods that never call the API.

FAQ

What comes with every engagement?

Every engagement is led by a senior tester and done by hand. During testing, a shared chat channel and a weekly call keep you up to date, and anything critical is reported straight away. After the report you get a readout call and one retest.
Will anything change in our environment?

The configuration review is read-only. Hands-on testing runs only from the starting points and towards the goals agreed in advance, and nothing destructive is tried.
How is this different from a cloud security scanner?

A posture tool lists every setting that differs from a benchmark, often hundreds. It can’t show which three of them chain into access to your customer database. This assessment does, and ranks findings by it.
Production or staging?

Either. The configuration that matters is usually production’s, and read-only access can’t change it. Hands-on steps can run in staging if it mirrors production.
Will the report help with SOC 2, ISO 27001 or a customer questionnaire?

Yes. It states the scope, the method, every finding and the retest results, which is what auditors and customers’ security teams ask to see.
What isn’t part of this test?

Cost optimisation, on-premises networks and physical infrastructure, and denial-of-service testing. The applications running in your cloud are tested separately.
Do you sign an NDA?

Yes, before any details are shared.
What language is the report in?

The report is in English.
Select a question

Get in touch

Tell us what you would like assessed: which cloud providers, roughly how many accounts, and whether you run Kubernetes.

What happens next

We reply within 24 hours
By email, with a link to book a call with the team.
Intro call
We learn what you need and answer your questions.
Proposal
Scope, timing and price, in writing. Nothing starts before an NDA is signed.

Prefer email? Write to hello@alteasecurity.com