Security · Topic 26 of 23 · Part V — Specialized assessment targets

Cloud assessment

The structural primitives are different: identity replaces the network as the dominant boundary, the control plane is a first-class target, and the provider's testing policy applies alongside the client's consent.

Syllabus: § Assessment of Infrastructure → Cloud and container assessment
Topic 26 · Cloud & containers

Not just "AWS with nmap"

By the end of this topic you can:
  • Distinguish the assessment problem for IaaS, PaaS, SaaS, containers, and serverless.
  • Scope a cloud assessment with proper attention to provider policies, shared responsibility, and tenancy.
  • Use control-plane access (read-only IAM) to drive the assessment, not just data-plane scanning.
  • Identify the most common cloud misconfigurations across AWS, Azure, and GCP.
  • Assess Kubernetes clusters as production infrastructure.
  • Recognise the distinct telemetry, attack patterns, and remediation paths cloud environments require.

Scoping a cloud assessment

Provider policies

  • AWS, Azure, GCP, Oracle, Alibaba all publish pen-testing policies — confirm at scoping time; they change.
  • AWS and GCP allow testing customer-owned resources without advance notification; specific test types (DoS, mass scans) remain prohibited.
  • PaaS dependencies (RDS, App Service, BigQuery) are generally off-limits.
  • SaaS (M365, Salesforce, Workday) — assume out-of-scope unless a special arrangement exists.

What scope must include

  • Account IDs (AWS), subscription / tenant IDs (Azure), project IDs (GCP).
  • IAM roles or service principals granted to the tester.
  • Whether managed services, containers, serverless, and SaaS integrations are in scope.
  • Authority to consent = the entity paying the bill; verify the client can authorise testing of the account.
Multi-tenant Tests must not affect other tenants sharing the same underlying infrastructure.

Service model determines assessment shape

Model What the tester sees Assessment focus
IaaS EC2, Azure VMs, GCE VMs, networks, storage, load balancers Network + host assessment + IAM roles on instances, IMDS exposure, storage-account exposure
PaaS Lambda, App Service, Cloud Run Application with VM abstracted Application surface, runtime identity & permissions, platform-level controls
SaaS M365, Salesforce, ServiceNow Configuration only Tenant config, identity integration (SCIM, SSO), admin roles, sharing settings, DLP
Containers EKS, AKS, GKE Orchestrator RBAC, network policy, image supply chain, runtime security
Serverless Lambda, Functions Function code + invocation surface + identity Invocation authentication, function identity permissions, secrets in code, egress

Control plane vs. data plane

Data plane

Services doing their job: EC2 running, S3 returning data, RDS answering queries.

On-premises analogy: the traffic on the wire.

Control plane

APIs that manage those services: launching instances, creating buckets, attaching IAM roles.

On-premises analogy: the admin who can reconfigure everything.

Key insight In the cloud, the control plane is an API call away. A read-only Auditor or SecurityReader role on the control plane surfaces orders of magnitude more findings than any amount of network scanning.
  • Most impactful findings target the control plane: over-privileged IAM, role-assumption paths, cross-account trust.
  • CloudTrail / Azure Activity Log / GCP Cloud Audit Logs = control-plane telemetry. Without it, incident response is blind.

IAM is the perimeter

On-premises: the firewall is the perimeter. In the cloud: IAM is the perimeter.

Common IAM weaknesses

  • Over-broad managed policies (AdministratorAccess, *:*, Azure Owner, GCP roles/editor).
  • Service accounts with broad permissions attached to many workloads.
  • Cross-account / cross-tenant trust with weak constraints.
  • No or weak MFA on privileged accounts.
  • Long-lived static credentials instead of short-lived federated credentials.

Higher-order risks

  • Privilege-escalation via IAM itself — a role that can edit IAM can grant itself anything. Tools: Pacu, ScoutSuite, Cloudsplaining.
  • Blast radius at org root — IAM granted at organisation root rather than account scope.
  • No periodic access review — permissions accumulate, never removed.

These are not exotic findings — they are the findings on most cloud engagements.

AWS-specific surfaces

  • S3 bucket misconfiguration. Public buckets, world-readable policies, cross-account exposure. Tools: s3scanner, AWS Config rules.
  • IMDSv1 still enabled. Legacy instances allow v1, enabling SSRF-to-credentials attacks. Fix: enforce IMDSv2.
  • IAM and STS. Excessive permissions, AssumeRole abuse, IAM-policy privilege escalation. Tool: Pacu.
  • Security groups / NACLs. Permissive ingress (0.0.0.0/0 on SSH, RDP, database ports).
  • VPC peering / Transit Gateway. Bidirectional network reachability across VPCs and accounts; frequently unintended.
  • Lambda resource policies. Cross-account invocation; over-privileged execution roles.
  • Secrets in environment variables, user-data, or CloudFormation templates committed to git.
  • CloudTrail not multi-region. Without full-region coverage, response is partially blind.

Azure and GCP surfaces

Azure

  • Entra ID. Conditional Access coverage, MFA on privileged roles, guest user policies, service principal credentials.
  • Storage Accounts. Anonymous blob access, over-broad SAS tokens, key rotation hygiene.
  • RBAC scope. Owner at management-group level cascades broadly across all subscriptions.
  • Managed Identities / Service Principals. Over-permissioned and shared across workloads.

Tools: MicroBurst, ROADtools, AzureHound / BloodHound, ScoutSuite.

GCP

  • IAM hierarchy. Org → Folder → Project → Resource; roles at higher levels cascade.
  • Service Account act-as. iam.serviceAccountTokenCreator and iam.serviceAccountUser are common privilege-escalation paths.
  • GCS buckets. allUsers / allAuthenticatedUsers exposure.
  • Audit logs. Data Access logs are off by default for most services — a major detection gap.

Tools: GCPBucketBrute, ScoutSuite, Prowler, gcloud CLI.

Containers and Kubernetes

Kubernetes is production infrastructure for most modern enterprises — not an exotic target.

Core assessment dimensions

  • API server exposure. Is the endpoint reachable from the internet? With what authentication?
  • RBAC. Cluster-admin bindings; pod rights to read secrets, list namespaces, exec into other pods.
  • Pod security. Privileged containers, hostPath/hostNetwork/hostPID, missing security contexts, running as root.
  • Network policy. Default-deny or default-allow; per-namespace; egress coverage.

Additional dimensions

  • Secrets handling. Kubernetes Secrets are base64 only; KMS encryption at rest is not the default.
  • Supply chain. Image registries, signing (cosign/Sigstore), admission control (Kyverno, OPA Gatekeeper).
  • etcd exposure. Direct etcd access bypasses RBAC entirely.
  • kubelet exposure. An unauthenticated kubelet API is a complete cluster compromise path.

Tools: kubescape, kube-bench, kube-hunter, peirates, Krane, Trivy/Grype.

Serverless assessment focus

Serverless flips the question from "what is running?" to "what can invoke this, and what can it do?"

  • Invocation surface. Who or what can trigger the function? Public API Gateway, EventBridge, S3/GCS trigger, Pub/Sub — are invocations authenticated?
  • Runtime identity. What does the function's execution role allow? Usually more than the function actually needs.
  • Function code. Hardcoded secrets, library vulnerabilities, dependency confusion, build-time supply-chain risks.
  • Network egress. Often unrestricted by default — a data-exfiltration path.
Default-insecure pattern A serverless deployment that relies on provider defaults frequently has both excessive permissions and inadequate isolation.

Detection in the cloud

What the blue team can see

  • CloudTrail / Activity Log / Cloud Audit Logs. The fundamental control-plane telemetry.
  • GuardDuty / Defender for Cloud / Security Command Center. Provider-native detection — reasonable baselines, not comprehensive.
  • Service-specific logs. S3 access, VPC Flow Logs, ELB / ALB, application logs in CloudWatch / Log Analytics / Cloud Logging.
  • External SIEM ingestion. Splunk, Sentinel, Chronicle in mature environments.

Common detection gaps

  • GCP Data Access logs disabled for most services.
  • CloudTrail not multi-region.
  • Alerts fire but route nowhere.
  • Defender for Cloud at free tier only.
  • No coverage of management-group-level changes.
High-value finding "We performed X and no telemetry captured it" — demonstrating a blind spot is as valuable as finding a misconfiguration.

Supply chain and CI/CD are in scope

The path from source code to cloud production is itself part of the attack surface.

  • Source control. GitHub / GitLab / Bitbucket; OIDC trust to the cloud account; branch protection; secret scanning.
  • CI/CD pipelines. GitHub Actions, GitLab runners, Jenkins, Azure DevOps. Cloud credentials in pipeline environment; OIDC federation vs. long-lived keys.
  • Container registries. ECR, ACR, GCR / Artifact Registry — image signing, scan policy.
  • Infrastructure-as-Code. Terraform / Pulumi / Bicep / CloudFormation repos and state stores (S3 + DynamoDB, Terraform Cloud) are part of the environment.
Common modern attack path Compromise a developer machine → pull a long-lived cloud key from ~/.aws/credentials or git history → full IAM access. Defence: short-lived federated credentials with no static keys anywhere.

Typical cloud-account assessment methodology

1Scope & policy — accounts, provider policy, tester IAM roles
2Inventory — full control-plane enumeration (aws-recon, ScoutSuite, native config services)
3IAM analysis — broad roles, escalation paths, cross-account trust, dormant identities
4Resource config — storage exposure, network exposure, encryption, logging
5Workload assessment — containers, serverless, managed databases
6Detection & response — logging coverage, alerting paths, response capability
7Supply chain — source, CI/CD, registries, IaC
8Findings — IAM-driven, config-driven, supply-chain-driven

Check — SCP enforcement limits

Reflection

A client says "we use AWS Organizations; SCPs prevent risky actions". What follow-up tests do you run before believing this?

Reveal answer

Enumerate the SCPs at each OU level; identify accounts excluded from SCPs (management account, audit account); test whether SCPs apply to root user actions; verify they cover all AWS regions actually in use; check for explicit overrides that defeat the SCP's intent. SCPs are a control — not a substitute for IAM least-privilege.

What you take home

  • Cloud assessment is not network assessment in the cloud — the control plane and IAM are the primary targets.
  • A read-only auditor role on the control plane yields more findings than weeks of data-plane scanning.
  • Provider policies add a third consent layer on top of the engagement contract and client authority.
  • IAM is the perimeter; over-privileged roles, static credentials, and escalation paths are the dominant findings.
  • Kubernetes is production infrastructure; treat API server, RBAC, and pod security as first-class assessment items.
  • Detection gaps (disabled audit logs, single-region CloudTrail) are reportable findings in their own right.
  • The CI/CD pipeline and IaC repos are in scope — they are a direct path to full cloud-account compromise.

Next: further topics in Part V cover specialised targets. Review the AWS, Azure, and GCP shared-responsibility models before the next session.

END · TOPIC 26

Identity is the perimeter.

Before the next session: look up one SCP, one IAM escalation path in Cloudsplaining's documentation, and verify whether your own test environment has CloudTrail enabled in all regions.