#Chapter 6 — Cloud, Container and Kubernetes Security

How to configure a cloud control plane so it produces evidence, detect the identity and misconfiguration attacks that actually happen there, and contain a compromised account, instance, cluster or workload without destroying the only proof you will ever get.

Who needs this: Cloud platform engineers, SREs, security engineers, detection engineers, incident responders, CISOs signing the log-retention budget | Read time: 27 min | Maps to: CSF 2.0 IDENTIFY, PROTECT, DETECT, RESPOND | CIS Controls 3, 4, 5, 6, 8, 13 | ISO 27001 A.8.9, A.8.15, A.8.16, A.5.28

Welcome back, cyber warriors. Pour the coffee, because this is the chapter where the abstractions stop and the commands start.

In May 2026, Sysdig's threat research team watched an LLM-driven attacker work a cloud environment hands-on-keyboard. It exploited a vulnerability in a marimo notebook, enumerated its own escape options, found an exposed Docker socket, launched a privileged container with the host filesystem bind-mounted at /:/host, read /etc/shadow and the SSH keys, then replayed a projected Kubernetes service-account token against the API server and dumped the cluster's entire Secret store — database credentials, AWS keys, OpenAI API keys. The tell that it was an agent and not a person: it parsed a canary directive hidden inside a JSON error response and acted on it, and it unit-tested its own payload delivery with "hello" before running the escape scripts (Sysdig).

Read that chain again and notice what is missing. No IMDS call. No zero-day in Kubernetes. No malware. A misconfigured socket, a mounted token, and standing permission did the whole job. That is the shape of cloud compromise in 2026: cloud-conscious intrusions are up 37% overall and 266% among state-nexus actors, and 35% of cloud incidents involve valid account abuse (CrowdStrike 2026 Global Threat Report). Meanwhile 82% of CrowdStrike's detections in the period were malware-free. Your EDR has nothing to say about any of this. The evidence lives entirely in the control plane, and the control plane only remembers what you paid it to remember.

That last point is the one that costs organizations their investigations. Nearly every major cloud breach of recent years landed on the customer's side of the shared-responsibility line — misconfiguration, identity, exposed data — not on the provider's. And nearly every failed cloud investigation failed for the same banal reason: the logs that would have answered the question had a default retention of seven days, thirty days, or ninety, and the question got asked on day ninety-one.

This chapter is about closing both gaps before you need them closed, and about what to do in the first hour when you did not.

#1. Shared responsibility, as the providers actually write it

Every vendor slide about shared responsibility shows the same two-color stack, and every one of them is technically correct and operationally useless. The useful version is the one in the providers' own words.

AWS frames it as **security of the cloud versus security in the cloud. AWS protects "the infrastructure that runs all of the services offered in the AWS Cloud." You own "the guest operating system (including updates and security patches), other associated application software," and the configuration of firewalls and security groups. The sentence people skip is the one that matters most: "Customer responsibility will be determined by the AWS Cloud services that a customer selects"** (AWS shared responsibility model). Run EC2 and you carry nearly everything above the hypervisor. Use S3 or DynamoDB and AWS operates deeper into the stack, leaving you managing data, encryption options, classification and IAM. Two services, same account, completely different obligations. Your responsibility is not a property of "the cloud" — it is a property of each service you turned on, and it changes every time an engineer adopts a new one.

Microsoft mirrors the model with explicit IaaS / PaaS / SaaS boundaries, and adds the constant that a lot of teams get wrong: data, endpoints, account and access management are always the customer's, in every service model (Microsoft shared responsibility). There is no tier of service you can buy where identity becomes somebody else's problem.

Google states shared responsibility and then argues past it, framing the relationship as "shared fate" — the position being that a clean boundary leaves customers standing alone on the wrong side of it, so Google pairs it with secure-by-default foundations, blueprints and risk-transfer programs (Google Cloud). Whatever you think of the framing, it points at something real: a boundary is not a control.

#Who owns what

That last row is the whole point. Shared responsibility is a responsibility boundary, not a liability boundary. When a provider has an incident, your regulator does not send the provider a letter. It sends you one. Chapter 15 covers what the clocks look like; Chapter 11 covers the contractual clauses that make a provider tell you in time to meet them.

The practical consequence for this chapter is narrower and more urgent: the boundary determines evidence availability. Your forensic capability stops where the provider's plane begins. You cannot subpoena a hypervisor. Everything you will ever know about an incident in your tenant has to have been logged, routed and retained by decisions you made before the incident started.

Actionable takeaway: Build a one-page responsibility matrix per service, not per provider, and make "who owns the logs, and for how long" a mandatory row. Any service in production without an owner named in that row is an unowned service — assign it this week or turn it off.

#2. The control plane is the crown jewel

Every cloud attack you will investigate ends up as a question about API calls: who called what, from where, with which credential, and what did it return. The control-plane log is the only witness. So the first design decision in cloud security is not a tool — it is a retention policy with a budget attached.

The international logging guidance is blunt about the default: "Default log retention periods are often insufficient." The same document notes that "in some cases, it can take up to 18 months to discover a cyber security incident and some malware can dwell on the network from 70 to 200 days before causing overt harm," and it tells you specifically to log "all control plane operations, including API calls and end user logins… configured to capture read and write activities, administrative changes, and authentication events" (Best Practices for Event Logging and Threat Detection, PDF). Note deliberately what it does not do: it sets no single numeric minimum. Anyone telling you "CISA requires twelve months" is quoting OMB M-21-31, a US federal memo binding on federal civilian agencies, not this guidance.

So you have to pick your own number. Here are the defaults you are picking against.

#What each provider actually retains, by default

Two sentences from that table should end up on a wall somewhere.

The first is Microsoft's, and it is the single most expensive fact in cloud IR: "Log retention changes aren't retroactive. When you upgrade from Free to P1 or P2, only data still within the free retention period (up to seven days) is available. Data that has already expired can't be recovered unless it was previously archived." You cannot buy your way out of this on day one of an incident. Upgrading a license mid-investigation gets you the logs from that moment forward, and nothing before it.

The second is Google's, and it cuts the other way: "Administrators cannot delete log event data or change the length of time that the data is available." In Workspace, that is an evidence-integrity feature — an attacker with admin cannot shorten your window. In AWS and Azure, they very much can, which is why Stealth:IAMUser/CloudTrailLoggingDisabled is a GuardDuty finding type in the first place.

#The 2026 licensing traps that destroy evidence

• Entra and the Unified Audit Log are two different systems. Microsoft says so explicitly: Entra audit and sign-in logs are "separate from the Microsoft 365 Unified Audit Log (UAL). UAL retention is managed through Microsoft Purview Audit and is not affected by Microsoft Entra ID licensing changes." An E5 upgrade does not extend your Entra sign-in retention, and a P2 upgrade does not extend your mailbox audit retention. Budget for both, separately.
• Graph activity logs are licensed but ephemeral. They require P1/P2 and a diagnostic setting routing them to Log Analytics, Sentinel, an Event Hub or Storage. Without the route, the license buys you nothing.
• Two Purview events still require manual activation per mailbox — SearchQueryInitiatedExchange and SearchQueryInitiatedSharePoint, which tell you what an intruder searched for, arguably the highest-signal record of intent you can get. CISA gives the command shape: Set-Mailbox <identity> -<sign-in type> @{Add="SearchQueryInitiated"} (CISA Microsoft Expanded Cloud Logs Implementation Playbook).
• GCP Data Access logs are off. Admin Activity's 400 days lulls teams into believing GCP logging is solved. Data Access — the record of who read what — is opt-in and defaults to 30 days when enabled.
• Azure resource logs are off, one resource at a time. The Activity log tells you somebody opened a Key Vault's access policy; it does not tell you which secrets were read. That is a resource log, it requires a diagnostic setting on that vault, and nobody has ever configured one on every resource by hand. Set it with Azure Policy at the management-group scope so new resources inherit it, or accept that your data-plane evidence is a lottery.
• CloudTrail data events are off. If your question is "which S3 objects did they download," and you have not enabled S3 data events, the honest answer is that you cannot know, and your breach notification has to assume the worst about every object in the bucket.

The cheap version. If you cannot fund a full SIEM ingest of every cloud log, do this instead and you will still be able to investigate. Send the control plane only — CloudTrail management events, Entra sign-in and audit logs, the Azure Activity log, GCP Admin Activity — to cheap object storage with a lifecycle that goes to a cold tier at 30 days and expires at 12 to 18 months, with Object Lock or the platform equivalent turned on. Query it with the provider's own query engine when you need it: CloudTrail Lake takes SELECT-only Trino-dialect SQL with the event data store ID as the FROM value, driven from the CLI with start-query, describe-query, get-query-results, and --delivery-s3-uri to write results to S3 (Lake queries with the CLI). Hot search is a luxury. Having the data at all is not.

Actionable takeaway: This week, run one query per provider — "what is our oldest retained control-plane event?" — and write the answer on the risk register. If the answer is under twelve months, you have an evidence gap, not a logging strategy. Fix the retention before you buy another detection tool, because a detection you cannot investigate is a notification you cannot scope.

#3. The detection stack, provider by provider

You do not need every service on this list. You need to know what each one is actually good at, so you stop paying for overlap and start covering gaps.

Four operational notes that will save you an embarrassing status update.

Security Hub is the normalization layer, and that is worth more than its dashboard. Most teams enable it, look at the compliance score, and never wire it into anything. The IR value is in three places. First, ASFF: Security Hub "processes finding data using the AWS Security Finding Format (ASFF), a standard finding format," which "eliminates the need to manage findings from myriad sources in multiple formats." It receives findings from GuardDuty, Inspector, Macie and the other integrated services, which means your SOAR writes one parser instead of five, and a playbook trigger written against ASFF fields keeps working when you turn on a new detection service. Second, cross-account aggregation is your first scoping question. Security Hub "consolidates your security findings across accounts and provider products" — so "is this confined to one account, or is the same finding type live in six?" is a filter, not an investigation. Ask it before you decide on a per-account or org-level containment. Third, workflow status is your case-tracking hook. Findings carry NEW, NOTIFIED, SUPPRESSED and RESOLVED, settable through aws securityhub batch-update-findings and automation rules (workflow status, Security Hub CSPM). Two traps come with it: Security Hub "only detects and consolidates findings that are generated after you enable" it, so it is worthless for a retrospective question, and marking a finding RESOLVED or SUPPRESSED "doesn't prevent Security Hub CSPM from generating a new finding for the same issue" — suppression is a triage note, not a mute button. Note also that AWS now brands the service Security Hub CSPM; if your runbooks say "Security Hub," check you are pointing at the right product page.

GuardDuty goes quiet on sustained activity. AWS documents it plainly: "If GuardDuty observes continued activity from a remote host, its ML model will identify this as an expected behavior. Therefore, GuardDuty will stop generating this finding" (GuardDuty IAM finding types). Persistent exfiltration eventually stops producing new findings. Never treat finding volume as a proxy for activity volume, and never close an incident because the alerts stopped.

Two GuardDuty families deserve dedicated routing. The UnauthorizedAccess:IAMUser/InstanceCredentialExfiltration.* and .../ResourceCredentialExfiltration.* findings mean credentials are demonstrably outside your control — the Resource variants cover Lambda functions and ECS tasks, not just EC2, and on the .InsideAWS variants you pivot on service.action.awsApiCallAction.remoteAccountDetails.accountId and .affiliated. The behavioral families (Persistence:, PrivilegeEscalation:, Exfiltration:IAMUser/AnomalousBehavior) mean escalation or staging is in progress, and Stealth:IAMUser/CloudTrailLoggingDisabled means somebody is turning off the witness. Chapter 14.3 lists the full trigger set for the account-takeover playbook.

Plan around the SCC tiering change. The Security Command Center Enterprise service tier shuts down on 21 May 2027, and organizations on Enterprise move automatically to Premium on or after that date (SCC release notes). If your GCP detection design assumes Enterprise-tier features, put the migration on the roadmap now rather than discovering the gap in a renewal cycle.

Actionable takeaway: For every cloud detection you own, record three separate facts — do we have the telemetry, does the logic exist and is it enabled, and has it fired on a validated test within the last 90 days. Chapter 9 covers the coverage model in full. Anything not green on all three is a named gap with a named owner, not a covered technique.

#4. CSPM and CIEM: the two problems that actually cause the breach

Cloud security spending skews toward threat detection, and cloud breaches skew toward misconfiguration and standing permission. That mismatch is the whole reason these two acronyms exist.

CSPM — Cloud Security Posture Management — answers "is anything configured wrongly." Public buckets, unencrypted volumes, open management ports, disabled logging, unrestricted security groups, missing IMDSv2 enforcement. It is a continuous config audit, mapping to CIS Control 4 and CSF's PR.PS.

CIEM — Cloud Infrastructure Entitlement Management — answers "who could do what if they wanted to." This is the harder and more valuable question, because permission is invisible until it is used. A role with * on s3 looks identical in a console to a role with three scoped actions, right up until the morning it is used to copy a database.

CIEM is the more urgent of the two because non-human identities now dominate cloud estates. CI runners, service accounts, app registrations and workload identities vastly outnumber human accounts and carry standing privilege that no MFA prompt ever guards; Mandiant records the theft of hard-coded keys and personal access tokens as a routine MFA-bypass path (M-Trends 2026), and the Sysdig case above ended in a Secret dump with no human credential involved at any point. Chapter 4 owns machine identity lifecycle; what belongs here is the cloud-specific measurement: for each principal, what could it reach, and when did it last actually use that reach?

The expensive version is a commercial CSPM/CIEM platform with graph-based blast-radius analysis across accounts and providers. On a large multi-cloud estate it earns its keep, mostly by making "who could reach this data" a query instead of a project.

The cheap version works, and you can start it this quarter:

1. Turn on the provider's own posture service. AWS Security Hub standards, GCP Security Command Center, and the equivalent Azure posture capabilities give you a config baseline with no new vendor.
2. Baseline against the CIS Benchmarks. These are consensus-developed prescriptive configuration baselines with AWS, Azure and GCP Foundations profiles plus containers and Kubernetes, each offering Level 1 (safe, broadly applicable) and Level 2 (defense-in-depth, may reduce functionality) profiles (CIS Benchmarks). Start at Level 1 everywhere; go to Level 2 on anything holding regulated data. These are the natural evidence for CIS Control 4 and ISO 27001 A.8.9.
3. Run IAM Access Analyzer's unused-access analyzers and treat the output as a work queue. Unused roles, unused access keys, unused passwords and unused services/actions on active principals are your least-privilege backlog, already sorted by the only thing that matters — nobody is using it, so removing it breaks nothing. Unused-access and internal-access analyzers are not Region-dependent; external access analyzers are, so create one in every Region you operate in.
4. Use policy generation, not guesswork, when you rebuild a role. Access Analyzer can generate a policy from the principal's actual CloudTrail activity. That is how you re-scope a role you just stripped during an incident, without a week of trial-and-error 403s.
5. Pick a framework to organize the work. The CSA Cloud Controls Matrix v4.1 (released 27 January 2026) gives 207 controls across 17 domains with mappings to other standards, and pairs with the CAIQ for assessing your own providers (CCM v4.1). New assessments should start on v4.1 rather than v4.0.x.

One prioritization rule beats any vendor's severity score: fix the misconfigurations that grant identity first. A public S3 bucket is a data-exposure incident. An over-permissive role trust policy is every incident, forever, because it is the machine that manufactures the next compromise.

Actionable takeaway: Stand up an unused-access analyzer in every account this month and delete the top 20 unused privileged grants it finds. It is free, it is reversible, and it is the highest-yield security work available to a team with no budget.

#5. IMDS and SSRF-to-credentials

The instance metadata service exists so a workload can get credentials without an engineer embedding a key. It is a genuinely good design. It is also a credential vending machine reachable at a fixed link-local address from anything running on the host — which means any server-side request forgery in your application is, potentially, a credential theft primitive. Shai-Hulud, the self-replicating npm worm, specifically harvests from cloud metadata endpoints alongside CI pipelines (Unit 42, CISA alert). This is not an edge case any more; it is a standard step in commodity tooling.

#What it looks like in CloudTrail

AWS's own CloudTrail investigation guidance gives you the pivots (Part 1, Part 2). Learn these fields; they are the difference between "we think something happened" and a defensible timeline.

The classic signature is an ASIA credential belonging to an instance role, calling from a source IP that is not in AWS. Add ec2RoleDelivery: "1.0" and you have both the theft and the mechanism in one record.

AWS's investigation checklist from Part 2 is worth following literally: query all Regions for that role's session activity, correlate CloudTrail timestamps against VPC Flow Logs for the actor's source IP, and then hunt IAM write events for persistence — CreateUser, CreateAccessKey.

#Enforcing IMDSv2

IMDSv2 requires a session token obtained via a PUT request, which defeats the naive SSRF pattern. The commands are documented (modify instance metadata options):

# Require IMDSv2 (session token required) on an existing instance.
# --http-endpoint must be set whenever --http-tokens is set.
aws ec2 modify-instance-metadata-options \
    --instance-id i-1234567890abcdef0 \
    --http-tokens required \
    --http-endpoint enabled

# Restrict how many network hops the PUT response may travel.
# A limit of 1 blocks container-to-IMDS in many topologies — that is the point,
# and also the reason it can break things. Test before fleet-wide rollout.
aws ec2 modify-instance-metadata-options \
    --instance-id i-1234567890abcdef0 \
    --http-put-response-hop-limit 3 \
    --http-endpoint enabled

# Turn IMDS off entirely on an instance that does not need it.
aws ec2 modify-instance-metadata-options \
    --instance-id i-1234567890abcdef0 \
    --http-endpoint disabled

Do the pre-flight check or you will cause an outage. AWS documents it: the MetadataNoToken CloudWatch metric tracks IMDSv1 calls, and "when MetadataNoToken records zero IMDSv1 usage for an instance, the instance is then ready to require IMDSv2" (configure IMDS options). Watch the metric until it is flat at zero, then enforce. Reversing that order is how a well-intentioned hardening sprint takes down a payments service.

Precedence matters when you roll this out at scale: launch parameter beats account-level default beats the AMI's ImdsSupport: v2.0 setting. Account-level enforcement is HttpTokensEnforced via ModifyInstanceMetadataDefaults; once it is enabled, a launch specifying HttpTokens=optional fails. That is the control you want in a production account — it makes the insecure configuration unlaunchable rather than merely discouraged. Note also that a hop limit of 1 "can cause issues" in container environments, which is exactly where you most want it; treat container topologies as a per-cluster test, not a fleet-wide flag flip.

Part 2's containment line, for an instance you already believe is compromised, is aws ec2 modify-instance-metadata-options --http-tokens required --http-put-response-hop-limit 1.

Actionable takeaway: Enable account-level IMDSv2 enforcement (HttpTokensEnforced) in every non-production account today and every production account after MetadataNoToken sits at zero. Enforcement at the account default is worth ten times the same setting applied instance-by-instance, because it survives the next Terraform module somebody copies from a blog post.

#6. Cloud containment: the ordered actions, and what each one destroys

This is the section to bookmark. Everything below is plain, sequenced and boring on purpose — a responder reading it at 03:00 should find no jokes and no ambiguity.

The governing principle: preserve, then scope, then contain in one burst, then verify. The order exists because cloud evidence is short-lived and cloud containment is loud. A containment action taken before preservation can permanently remove the only record of what happened. A containment action taken piecemeal hands the adversary a window between each step.

#The ordered containment table

#The commands, and the traps inside them

Revoking IAM role sessions is not the same as removing permissions. AWS states it directly: "Temporary security credentials are valid until they expire… You can revoke these credentials, but you must also change permissions for the IAM user or role" (disabling permissions for temporary credentials). Session duration ranges from 900 seconds to 129,600 seconds (36 hours), default 43,200 seconds (12 hours) — so a session you fail to kill can outlive your entire first shift.

The console's "Revoke active sessions" attaches an inline policy named AWSRevokeOlderSessions to the role (requiring PutRolePolicy), denying all access to sessions assumed in the past and approximately 30 seconds into the future to absorb propagation delay. "Any user who assumes the role more than approximately 30 seconds after you choose Revoke active sessions is not affected" — which is why step 4's SCP and step 5's permission change both matter. The policy AWS attaches looks like this (revoke IAM role sessions):

{
  "Version": "2012-10-17",
  "Statement": {
    "Effect": "Deny",
    "Action": "*",
    "Resource": "*",
    "Condition": {
      "DateLessThan": {"aws:TokenIssueTime": "2014-05-07T23:47:00Z"}
    }
  }
}

Three exceptions that will bite you mid-incident:

• You cannot revoke the session for a service-linked role.
• Roles created from IAM Identity Center permission sets cannot be edited in IAM — you must revoke the active permission-set session in Identity Center instead.
• If a resource-based policy independently allows the principal, revoking the role session is not sufficient. You need an explicit Deny on the resource, keyed on aws:PrincipalArn or aws:SourceIdentity.

For surgical denies that do not nuke a role every other workload depends on, condition on aws:SourceIdentity (immutable once set, and it survives role chaining), aws:PrincipalArn, or aws:userId — AROAXROLE1:* denies every session for a role, AROAXROLE2:<session-name> denies exactly one. The AWS-managed AWSDenyAll policy is the blunt instrument when you want the whole principal dead. And tell your responders to clear their own client caches (rm -r ~/.aws/cli/cache on Linux/macOS, del /s /q %UserProfile%\.aws\cli\cache on Windows) or they will spend twenty minutes debugging a credential that no longer exists.

Quarantine SCPs beat in-account denies during an active incident.

# Attach a quarantine policy to a root, OU, or 12-digit account ID.
aws organizations attach-policy \
  --policy-id p-examplepolicyid111 \
  --target-id ou-examplerootid111-exampleouid111

(attach-policy, SCP concepts) The reason this is the better containment lever is structural: the SCP lives in the management account, outside the compromised account's control, so a principal holding admin in the member account cannot detach it. An inline deny on a role can be removed by the attacker and is subject to IAM eventual consistency. The AWS CIRT playbook documents exactly this pattern — a deny-all conditioned on the offending identitystore:userId or aws:TokenIssueTime, attached at the Root or a target OU (Compromised IAM Credentials playbook).

Three exclusions, and they are the difference between contained and only feeling contained:

• SCPs have no effect on users or roles in the management account. AWS states it twice on the same page: "SCPs don't affect users or roles in the management account. They affect only the member accounts in your organization." An SCP attached at the root still returns success, and the CLI gives you no warning that the principal you are chasing is exempt.
• SCPs cannot restrict any action performed through a service-linked role. "SCPs do not affect any service-linked role."
• SCPs exist only in an organization with all features enabled. They "are available only in an organization that has all features enabled" — an organization on consolidated billing only cannot use this lever at all. Find out which one you have before the incident, not during it.

If the compromised principal lives in the management account, the SCP is not your lever. Nothing you attach at the root will touch it. Contain on the identity side instead: attach an explicit deny to the principal, deactivate its access keys, revoke its role sessions, and — for an Identity Center user — revoke the permission-set session in Identity Center. That is the case where the blunt AWSDenyAll policy and the aws:PrincipalArn conditions above are doing the actual work, and the SCP is doing none.

Key rotation runs backwards during an incident. AWS's no-downtime rotation sequence is create → update applications → verify with get-access-key-last-used → set Inactive → confirm → delete (update access keys). For a compromised key, invert it: deactivate first, then create the replacement. Set it to Inactive rather than deleting it — an inactive key still tells you it existed, who created it and when it was last used; a deleted one tells you nothing.

Instance isolation, and the caveat that breaks naive playbooks. AWS's documented procedure is: create a dedicated Isolation security group with no rule permitting 0.0.0.0/0 (0-65535) in either direction, associate it with the instance, then remove all other security group associations (remediating a compromised EC2 instance).

# Replaces the instance's security groups with the isolation group.
# You must specify at least one security group ID.
aws ec2 modify-instance-attribute \
  --instance-id i-1234567890abcdef0 \
  --groups sg-0isolation

Now the caveat, quoted: "The existing tracked connections won't be terminated as a result of changing security groups — only future traffic will be effectively blocked by the new security group." An established C2 channel survives your isolation. For that you need NACLs based on the network IoCs, which AWS's own ransomware response playbook covers in its "Enforce NACLs based on network IoCs" section (Ransom_Response_EC2_Linux). Google documents the identical trap on its side: "Adding firewall rules doesn't close existing connections."

Evidence handling across accounts. Snapshots are Region-scoped, so copy to move Regions. If the snapshot is encrypted, you must also share the customer-managed KMS key that encrypted it, or the forensic account receives an unreadable blob. The forensic role should have read-only access to collected artefacts (forensic investigation environment strategies, SEC10-BP03, capture backups and snapshots).

Federation containment is a demolition tool. There is no disable operation for an OIDC provider — only delete: aws iam delete-open-id-connect-provider --open-id-connect-provider-arn <arn>. It is idempotent, and AWS is explicit about the consequence: "Deleting an OIDC provider does not update roles that reference it. Any attempt to assume such roles will fail" (delete-open-id-connect-provider). That failure is the containment effect, and it is also an outage across every CI pipeline and workload that federated through it. The surgical alternative is remove-client-id-from-open-id-connect-provider, which drops one audience rather than the whole trust.

GCP has its own version of the "revocation is not enough" trap, and it is the most important sentence in a GCP containment playbook: "Disabling a service account key does not revoke short-lived credentials that were issued based on the key." The documented remedy is to disable or delete the service account itself, which immediately stops any workload using it (disable and enable service account keys).

# Disable a suspect key. NOTE: tokens already minted from this key remain valid.
gcloud iam service-accounts keys disable KEY_ID \
    --iam-account=SA_NAME@PROJECT_ID.iam.gserviceaccount.com \
    --project=PROJECT_ID

Azure has no SCP, and pretending otherwise will cost you an hour. There is no policy object that sits above a subscription and denies arbitrary actions to a compromised principal the way an SCP does. Two things are commonly mistaken for one. Azure deny assignments look exactly right — they attach deny actions to a principal at a scope and beat any role assignment — but Microsoft is blunt: "You can't directly create your own deny assignments. Deny assignments are created and managed by Azure" (deny assignments). They arrive via deployment stacks and managed resources, not via your incident. Azure Policy with the deny effect is assignable by you at management-group scope, and it is the closest analogue — but read what it actually does: it "prevent[s] a resource request that doesn't match defined standards… The request is returned as a 403 (Forbidden)" (deny effect). That blocks resource creation and update. It does not block reads, and it does not block data-plane actions. It will stop an attacker deploying crypto-mining VMs. It will not stop them reading your storage accounts.

So on Azure the containment lever is identity-side, and it is removal rather than denial. Enumerate before you delete — az role assignment delete removes every assignment matching the query:

# ALWAYS run list first. delete removes every assignment matching these arguments.
az role assignment list \
  --assignee 00000000-0000-0000-0000-000000000000 \
  --scope /subscriptions/<subscription-id> \
  --include-inherited

# Remove the compromised principal's assignments at the subscription scope.
az role assignment delete \
  --assignee 00000000-0000-0000-0000-000000000000 \
  --scope /subscriptions/<subscription-id>

# Delete a compromised service-principal secret. Record --key-id in the evidence
# register first: Azure has no "inactive" state, so the credential is simply gone.
az ad sp credential delete \
  --id 00000000-0000-0000-0000-000000000000 \
  --key-id <key-id>

# Isolate a VM by swapping its NIC to a pre-built isolation NSG.
# Build the isolation NSG in advance, in every VNet, like the AWS one in step 9.
az network nic update \
  --resource-group <resource-group> --name <nic-name> \
  --network-security-group <isolation-nsg>

And the Azure trap that mirrors the GCP one: removing a role assignment or deleting a credential does not invalidate an access token the attacker already holds. Entra access tokens stay valid until they expire, and Entra "can't directly revoke a session token issued by an application." Removing the assignment stops the next token; it does not stop the one in flight. This is the same shape as the GCP short-lived-credential trap above and the AWS session trap above it — three providers, three different commands, one identical failure. Pair every removal with session revocation and a Conditional Access block on the identity side (Chapter 14.3), and treat the token lifetime as your real containment clock.

For the identity half of this — Entra session revocation, Conditional Access blocks, OAuth grant removal, Google Workspace signOut and token deletion — see Chapter 14.3, which owns the full account-takeover playbook, and Chapter 4 for the standing controls. The short version you need here: revocation is the control that matters and expiry is not, because in Continuous Access Evaluation sessions token lifetime increases to long-lived, up to 28 hours, and CAE propagation can take up to 15 minutes (continuous access evaluation).

Actionable takeaway: Rehearse this table as a drill in a non-production account, timed, with the snapshot and export steps actually executed. Every step you have never run will take three times as long during an incident, and step 11 — stopping the instance — is the one people run first and regret permanently. Preserve. Then contain. In that order, on every incident, without a debate about it.

#7. Kubernetes and containers

Kubernetes is where all of the above compounds, because a cluster is simultaneously a compute platform, an identity provider and a secret store, and its default settings favor developer velocity over your investigation.

#First: do you even have the audit log?

There is a tuning rule here that most teams miss and every privilege-escalation investigation depends on. Metadata level on all verbs is not enough. You need Request level on Secrets, ServiceAccounts and RBAC objects, because the request body is what shows the escalation — which role, which subject, which secret. Metadata tells you a RoleBinding was created; Request tells you it bound cluster-admin to the attacker's service account. That is the entire finding.

#Finding the blast radius

The EKS best-practices guide gives verbatim one-liners for the three questions you will ask first (EKS incident response and forensics):

# Which node is the suspect pod running on?
kubectl get pods <name> --namespace <namespace> -o=jsonpath='{.spec.nodeName}{"\n"}'

# Every pod using a given service account, with its node.
kubectl get pods -o json --namespace <namespace> \
  | jq -r '.items[] | select(.spec.serviceAccount == "<service account name>") | "\(.metadata.name) \(.spec.nodeName)"'

# Every pod running a compromised image, cluster-wide.
IMAGE=<malicious image>
kubectl get pods -o json --all-namespaces \
  | jq -r --arg image "$IMAGE" '.items[] | select(.spec.containers[] | .image == $image) | "\(.metadata.name) \(.metadata.namespace) \(.spec.nodeName)"'

#The warning that matters more than any command in this chapter

Do not delete the pod.

AWS states it plainly: "Gather forensic evidence before removing the node — an attacker might attempt to destroy evidence through termination." Pods are ephemeral by design. Deleting one destroys the container's writable layer and all in-memory state, and if it is managed by a Deployment, the controller helpfully schedules a replacement — which may re-run the attacker's payload from the same compromised image, restarting the incident with your only evidence already gone.

Capture first, in this order:

1. Memory from the node (LiME or an equivalent acquisition tool; AWS also names its Automated Forensics Orchestrator for Amazon EC2).
2. Network state — netstat for connections and open ports.
3. Container runtime state — docker top, docker logs, docker inspect, docker diff, docker checkpoint; for containerd and CRI-O runtimes, the crictl equivalents.
4. Volume snapshots of the node's persistent storage.

Kubernetes gives you two non-destructive live-triage moves, and they should be your reflex (debug running pods):

# Attach an ephemeral debug container to the RUNNING pod. Does not restart it.
kubectl debug -it POD_NAME --image=busybox --target=CONTAINER_NAME

# Take a copy of the pod to examine, leaving the original running and observable.
kubectl debug POD_NAME --copy-to=POD_NAME-debug --image=DEBUG_IMAGE

Only after capture: kubectl delete pods POD_NAME --grace-period=10, or delete the Deployment so that no replacement is scheduled — which is GKE's documented sequence, and the correct one when the image itself is the problem.

#Quarantine without deletion

Network-policy quarantine. A deny-all policy scoped to the compromised pod's labels:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny
spec:
  podSelector:
    matchLabels:
      app: web
  policyTypes:
  - Ingress
  - Egress

Verify enforcement; do not assume it. NetworkPolicy is enforced by the CNI, not by Kubernetes itself. On EKS it requires the VPC CNI network-policy feature, or Calico or Cilium. A cluster without a policy-enforcing CNI will accept this object, report success, and enforce absolutely nothing. Test this in a drill, on every cluster, before you depend on it in an incident. An object that applies cleanly and does nothing is worse than no control at all, because it produces confident status updates that are false.

Node isolation.

kubectl cordon <node-name>                 # marks unschedulable; does NOT evict anything
kubectl drain --ignore-daemonsets <node>   # evicts, respecting PDBs and grace periods
kubectl uncordon <node-name>               # reverse it

drain "respect[s] the desired graceful termination period, and respect[s] the PodDisruptionBudget you have defined" (safely drain a node) — meaning a PodDisruptionBudget can block your containment drain. Kubernetes recommends the AlwaysAllow unhealthy-pod eviction policy for exactly this reason. Find out which of your PDBs would block a drain before you need to drain.

GKE's documented quarantine pattern is the elegant one: pin the compromised pod in place while moving every healthy workload off the node (mitigate security incidents in GKE):

kubectl cordon NODE_NAME
kubectl label pods POD_NAME quarantine=true
kubectl drain NODE_NAME --pod-selector='!quarantine'

Then cut egress at the VPC layer:

gcloud compute instances add-tags NODE_NAME --zone COMPUTE_ZONE --tags quarantine

gcloud compute firewall-rules create quarantine-egress-deny \
  --network NETWORK_NAME --action deny --direction egress \
  --rules tcp --destination-ranges 0.0.0.0/0 --priority 0 --target-tags quarantine

Remember Google's caveat: adding firewall rules does not close existing connections. On EKS, additionally detach IAM roles from the compromised worker node and remove IAM policies from pod-assigned roles, which is what stops the cluster compromise from becoming a cloud control-plane compromise.

#Service-account tokens — what actually revokes one

This is the part almost every pre-2025 playbook gets wrong. Modern Kubernetes service-account tokens are bound: their validity is tied to an API object — a Pod, a Secret, or a Node (Node binding GA in v1.33) — and private JWT claims carry that object's metadata.name and metadata.uid. "If a referenced object is deleted or doesn't exist (or its metadata.uid doesn't match), authentication with that token fails immediately." For objects pending deletion with finalizers, tokens fail 60 seconds after the deletionTimestamp (managing service accounts).

That gives you a revocation decision tree:

Verify what a captured token is bound to before you decide, using a TokenReview — kubectl create -o yaml -f tokenreview.yaml with an authentication.k8s.io/v1 TokenReview carrying spec.token. The status returns authentication.kubernetes.io/pod-name, pod-uid, node-name and node-uid. And when you mint a replacement, bind it deliberately: kubectl create token my-sa --bound-object-kind="Pod" --bound-object-name="test-pod".

Strip the RBAC too. Deleting a ServiceAccount without removing its RoleBindings and ClusterRoleBindings leaves the grant sitting there, waiting for a recreated ServiceAccount of the same name to inherit it. That is not eradication; that is a scheduled re-compromise.

#The escalation paths, per platform

• EKS: anything on the node that can reach IMDS can retrieve the node IAM role credentials — the classic vector is a hostNetwork: true pod, or a hop limit of 2 that lets a container reach the metadata service. IRSA exchanges projected service-account tokens for IAM roles, so an over-broad IRSA trust policy, or an sts:AssumeRoleWithWebIdentity condition that does not pin sub to a specific namespace and service account, lets any pod in the cluster assume that role (privilege escalation in EKS via worker node instance roles, Wiz EKS best practices).
• GKE: Workload Identity works primarily through metadata-server emulation, so most applications authenticate automatically with no explicit volume configuration — which is why Google's own incident-mitigation guidance recommends Shielded GKE nodes to prevent metadata server access if a container escape occurs.
• AKS: Workload Identity (federated credentials on a user-assigned managed identity) versus the node's kubelet identity — the same IMDS-reachability problem applies.
• Cross-platform: container-escape CVEs turn a pod compromise into a node compromise, which turns into a cloud-credential compromise. Have these in the playbook: three critical runC vulnerabilities disclosed in November 2025 affecting Docker, Kubernetes, containerd and CRI-O, and CVE-2025-23266 (CVSS 9.0) in the NVIDIA Container Toolkit (Wiz on container escape). Older but still-referenced examples include CVE-2023-3676 (Kubernetes privilege escalation) and CVE-2023-3089 (CRI-O breakout). Chapter 10 owns the prioritization process for all of these.

Actionable takeaway: Audit automountServiceAccountToken across every namespace and set it to false wherever the workload does not call the API server, then enable Request-level audit logging on Secrets, ServiceAccounts and RBAC objects. Those two changes remove the most common escalation primitive and give you the evidence to see the next one. Chapter 14.10 carries the complete Kubernetes compromise playbook.

#8. Serverless and multi-cloud

#Serverless

Serverless shrinks your patching obligation and expands your identity obligation, which is a trade most teams accept without noticing the second half. Three things change materially.

Your invocation record is opt-in. Lambda invocations are CloudTrail data events, and data events are off by default. Without them you have management-plane visibility into who deployed the function and nothing whatsoever about who called it. Enable them for functions handling regulated data or holding privileged roles.

The credential-theft finding is a different one. GuardDuty's UnauthorizedAccess:IAMUser/ResourceCredentialExfiltration.OutsideAWS and .InsideAWS cover Lambda functions and ECS tasks, not just EC2. If your alerting routes only the InstanceCredentialExfiltration variants, you are blind to exactly the compute model you adopted partly for security reasons.

Containment is permission-shaped, not host-shaped. There is no instance to isolate and no security group to swap. The levers are the ones in §6: deny the execution role's permissions, revoke its sessions, remove event-source mappings and triggers, and — if the function itself is the malicious artefact — remove the deployment. Preservation still comes first: capture the function's code, configuration, environment variables and layer versions before you change anything, because a redeploy overwrites the evidence of what was running.

One more, easy to miss: IAM Access Analyzer's external-access analyzers cover Lambda alongside S3, IAM roles, KMS keys, SQS, Secrets Manager, SNS, EBS volume snapshots, RDS snapshots, ECR, EFS and DynamoDB. A snapshot shared to an unknown account is an exfiltration channel that leaves almost no other trace.

#Multi-cloud

Multi-cloud is not three times the work. It is three times the work plus the integration cost of reconciling three incompatible mental models, which is the part nobody budgets for.

The specific failure is that containment semantics differ per provider, in ways that are individually documented and collectively lethal:

A responder who has internalized the AWS model and applies it to GCP will disable the key, watch the API calls continue, and lose twenty minutes deciding whether their tooling is broken. That is a training problem with a documentation answer: write the per-provider revocation semantics into one card and put it in the war room.

Four rules that make multi-cloud tractable:

1. One timeline, one clock. Normalize everything to UTC with ISO 8601 formatting (2024-07-25T20:54:59.649Z), millisecond granularity where available, from a validated time source — exactly what the allied logging guidance calls for. It is the difference between a timeline and a pile of files.
2. One control framework, mapped per provider. Use CSA CCM v4.1 or the CIS Benchmarks as the common spine and map each provider to it, rather than maintaining three independent standards that drift apart.
3. Structured logs, one schema. JSON, consistent field order, automated normalization — the guidance calls normalization "particularly important" for SaaS logs "that can change over time or without notice."
4. Do not buy three of everything. Native detection in each provider plus one aggregation layer beats three partially-deployed third-party platforms. The failure mode of multi-cloud tooling is not insufficient coverage; it is four consoles nobody checks and an alert firing into a channel that was archived last quarter.

Actionable takeaway: Write a one-page per-provider revocation card — for AWS, Azure/Entra and GCP, what kills a session, what kills a credential, and what each one does not reach — and laminate it into the incident war-room kit. The five minutes a responder spends reading it is the cheapest control in this chapter.

Cloud security is not really about the cloud. It is about whether you configured a machine that keeps receipts, whether you know which of your thousands of standing permissions actually get used, and whether the person who gets paged at 03:00 knows to take the snapshot before they kill the pod. None of that requires an enterprise budget. All of it requires deciding, in advance and in writing, what you will do — because the control plane will absolutely do what you told it to, exactly as fast as an attacker can ask.

Log everything that grants power, revoke before you reset, and never, ever delete the pod first.

#Chapter checklist

• CLD-01A responsibility matrix exists per cloud service in production (not per provider), naming the owner of configuration, identity, data and logs for each. [IG1] [GV.RR] [ID.AM]
• CLD-02Control-plane logging is enabled in every account, subscription and project — CloudTrail management events, Entra audit and sign-in logs, the Azure Activity log exported past its 90-day platform window, GCP Admin Activity — with no unlogged region, account, subscription or tenant. [IG1] [DE.CM] [CIS 8] [A.8.15]
• CLD-03Control-plane logs are exported to storage outside the account that generates them, with object-lock or equivalent immutability, and lifecycle rules on those buckets require security sign-off to change. [IG2] [PR.DS] [CIS 8] [A.5.28]
• CLD-04Documented log retention for control-plane events is at least twelve months, with the risk assessment behind the chosen number recorded on the risk register. [IG2] [DE.CM] [CIS 8]
• CLD-05CloudTrail data events are enabled for S3 buckets and Lambda functions that hold or process regulated data. [IG2] [DE.CM] [CIS 8]
• CLD-06GCP Data Access audit logs are enabled for projects holding regulated data, and their retention is configured beyond the 30-day _Default. [IG2] [DE.CM] [CIS 8]
• CLD-07Microsoft Purview Audit retention is configured deliberately, and where a 10-year add-on has been purchased, a matching custom retention policy has been created and targeted. [IG2] [DE.CM]
• CLD-08SearchQueryInitiatedExchange and SearchQueryInitiatedSharePoint are activated for privileged and high-risk mailboxes. [IG3] [DE.CM]
• CLD-09Every cloud detection has a documented data-source precondition check that fails loudly when the source stops reporting or was never populated. [IG2] [DE.AE]
• CLD-10IMDSv2 is enforced at the account level (HttpTokensEnforced) in all production accounts, and the MetadataNoToken metric reads zero for the fleet. [IG2] [PR.PS] [CIS 4] [A.8.9]
• CLD-11A detection exists for CloudTrail events where ec2RoleDelivery is "1.0", and for ASIA instance-role credentials used from a source IP outside AWS. [IG2] [DE.CM]
• CLD-12An unused-access analyzer runs in every account, and its findings are worked as a tracked remediation queue with an owner and a cadence. [IG2] [PR.AA] [CIS 5] [CIS 6]
• CLD-13External-access analyzers exist in every Region in use, not only the primary Region. [IG2] [ID.AM] [PR.AA]
• CLD-14Cloud accounts are baselined against the relevant CIS Benchmark at Level 1 minimum, and at Level 2 for any account holding regulated data, with drift reported. [IG1] [PR.PS] [CIS 4] [A.8.9]
• CLD-15A pre-built quarantine SCP (or equivalent org-level policy) exists in the management account, has been tested in a drill, and its attachment requires Incident Commander approval. The runbook states that it does not restrict management-account principals or service-linked roles, and names the identity-side alternative for those cases. [IG2] [RS.MI] [A.5.26]
• CLD-16A dedicated isolation security group exists in each VPC with no 0.0.0.0/0 (0-65535) rule in either direction, and the runbook documents that changing security groups does not terminate established connections. [IG2] [RS.MI]
• CLD-17A forensics account exists with read-only access to collected artefacts, and the cross-account snapshot procedure — including sharing the customer-managed KMS key for encrypted snapshots — has been executed end-to-end in a drill within the last 12 months. [IG3] [RS.AN] [A.5.28]
• CLD-18A one-page per-provider revocation card (what kills a session, what kills a credential, what each does not reach) is in the incident war-room kit and reviewed annually. [IG1] [RS.MA] [A.5.24]
• CLD-19Kubernetes control-plane audit logging is enabled on every cluster, with Request-level auditing on Secrets, ServiceAccounts and RBAC objects. [IG2] [DE.CM] [CIS 8]
• CLD-20automountServiceAccountToken is set to false for every workload that does not call the API server, verified by policy rather than by convention. [IG2] [PR.AA] [CIS 4]
• CLD-21NetworkPolicy enforcement has been positively verified on every cluster (a deny-all policy demonstrably blocks traffic), not merely assumed from the presence of a CNI. [IG2] [PR.IR] [CIS 13]
• CLD-22The Kubernetes response runbook requires evidence capture — memory, runtime state, volume snapshot — before any pod or node deletion, and the requirement has been exercised in a tabletop or functional drill. [IG2] [RS.AN] [A.5.28]
• CLD-23PodDisruptionBudgets that would block a containment drain have been identified per cluster, with a documented override procedure. [IG3] [RS.MI]
• CLD-24IRSA / Workload Identity trust policies pin the sub claim to a specific namespace and service account, with no cluster-wide assumable roles. [IG3] [PR.AA] [CIS 6]
• CLD-25Cryptomining findings in container environments are triaged as suspected full control-plane compromise, including a mandatory check of whether the cluster Secret store was read. [IG2] [RS.AN]
• CLD-26A diagnostic setting exports the Azure Activity log beyond its 90-day platform window for every subscription, and resource diagnostic logs are enforced by Azure Policy at management-group scope for resources holding regulated data. [IG2] [DE.CM] [CIS 8] [A.8.15]

#Sources

1. AWS Shared Responsibility Model — https://aws.amazon.com/compliance/shared-responsibility-model/
2. Microsoft — Shared responsibility in the cloud — https://learn.microsoft.com/en-us/azure/security/fundamentals/shared-responsibility
3. Google Cloud — Shared responsibilities and shared fate — https://cloud.google.com/architecture/framework/security/shared-responsibility-shared-fate
4. AWS CloudTrail concepts (retention, event types) — https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-concepts.html
5. Run and manage CloudTrail Lake queries with the AWS CLI — https://docs.aws.amazon.com/awscloudtrail/latest/userguide/lake-queries-cli.html
6. Microsoft Entra data retention — https://learn.microsoft.com/en-us/entra/identity/monitoring-health/reference-reports-data-retention
7. Manage audit log retention policies (Microsoft Purview) — https://learn.microsoft.com/en-us/purview/audit-log-retention-policies
8. CISA — Microsoft Expanded Cloud Logs Implementation Playbook (Jan 2025) — https://www.cisa.gov/sites/default/files/2025-01/microsoft-expanded-cloud-logs-implementation-playbook-508c.pdf
9. Google Cloud Logging — retention and buckets — https://cloud.google.com/logging/docs/buckets
10. Google Workspace — Data retention and lag times — https://knowledge.workspace.google.com/admin/reports/data-retention-and-lag-times
11. CISA/ACSC and partners — Best Practices for Event Logging and Threat Detection — https://www.cisa.gov/resources-tools/resources/best-practices-event-logging-and-threat-detection (PDF: https://www.ic3.gov/CSA/2024/240822.pdf)
12. Amazon GuardDuty IAM finding types — https://docs.aws.amazon.com/guardduty/latest/ug/guardduty_finding-types-iam.html
13. Amazon Detective finding groups — https://docs.aws.amazon.com/detective/latest/userguide/understanding-groups.html
14. IAM Access Analyzer overview — https://docs.aws.amazon.com/IAM/latest/UserGuide/what-is-access-analyzer.html
15. Microsoft Defender XDR — CloudAppEvents table — https://learn.microsoft.com/en-us/defender-xdr/advanced-hunting-cloudappevents-table
16. Google Security Command Center — Event Threat Detection overview — https://docs.cloud.google.com/security-command-center/docs/concepts-event-threat-detection-overview
17. Google Security Command Center — threat detection overview — https://docs.cloud.google.com/security-command-center/docs/overview-threats
18. Google Security Command Center release notes (Enterprise tier shutdown) — https://docs.cloud.google.com/security-command-center/docs/release-notes
19. CIS Benchmarks — https://www.cisecurity.org/cis-benchmarks
20. CSA Cloud Controls Matrix v4.1 — https://cloudsecurityalliance.org/artifacts/cloud-controls-matrix-v4-1
21. AWS Security Blog — Incident response guide for AWS CloudTrail investigations, Part 1 — https://aws.amazon.com/blogs/security/incident-response-guide-for-aws-cloudtrail-investigations-part-1/
22. AWS Security Blog — Incident response guide for AWS CloudTrail investigations, Part 2 — https://aws.amazon.com/blogs/security/incident-response-guide-for-aws-cloudtrail-investigations-part-2/
23. AWS — Remediating compromised AWS credentials — https://docs.aws.amazon.com/guardduty/latest/ug/compromised-creds.html
24. AWS — Modify instance metadata options for existing instances — https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/configuring-IMDS-existing-instances.html
25. AWS — Configure instance metadata options — https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/configuring-instance-metadata-options.html
26. AWS — Revoke IAM role temporary security credentials — https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_revoke-sessions.html
27. AWS — Disabling permissions for temporary security credentials — https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_control-access_disable-perms.html
28. AWS — Update access keys — https://docs.aws.amazon.com/IAM/latest/UserGuide/id-credentials-access-keys-update.html
29. AWS — Remediating a potentially compromised EC2 instance — https://docs.aws.amazon.com/guardduty/latest/ug/compromised-ec2.html
30. AWS CLI — ec2 modify-instance-attribute — https://docs.aws.amazon.com/cli/latest/reference/ec2/modify-instance-attribute.html
31. AWS CLI — organizations attach-policy — https://docs.aws.amazon.com/cli/latest/reference/organizations/attach-policy.html
32. AWS — Service control policies concepts — https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html
33. AWS CLI — iam delete-open-id-connect-provider — https://docs.aws.amazon.com/cli/latest/reference/iam/delete-open-id-connect-provider.html
34. AWS Security Blog — Forensic investigation environment strategies in the AWS Cloud — https://aws.amazon.com/blogs/security/forensic-investigation-environment-strategies-in-the-aws-cloud/
35. AWS Well-Architected — SEC10-BP03 Prepare forensic capabilities — https://docs.aws.amazon.com/wellarchitected/latest/framework/sec_incident_response_prepare_forensic.html
36. AWS Security IR — Capture backups and snapshots — https://docs.aws.amazon.com/security-ir/latest/userguide/capture-backups-and-snapshots.html
37. aws-samples — Compromised IAM Credentials playbook — https://github.com/aws-samples/aws-customer-playbook-framework/blob/main/docs/Compromised_IAM_Credentials.md
38. aws-samples — Ransom Response EC2 Linux playbook — https://github.com/aws-samples/aws-customer-playbook-framework/blob/main/docs/Ransom_Response_EC2_Linux.md
39. Google Cloud — Disable and enable service account keys — https://docs.cloud.google.com/iam/docs/keys-disable-enable
40. Microsoft — Continuous access evaluation — https://learn.microsoft.com/en-us/entra/identity/conditional-access/concept-continuous-access-evaluation
41. Microsoft — Revoke user access in an emergency — https://learn.microsoft.com/en-us/entra/identity/users/users-revoke-access
42. Amazon EKS — Control plane logging — https://docs.aws.amazon.com/eks/latest/userguide/control-plane-logs.html
43. EKS Best Practices Guide — Incident Response and Forensics — https://aws.github.io/aws-eks-best-practices/security/docs/incidents/
44. Kubernetes — Safely drain a node — https://kubernetes.io/docs/tasks/administer-cluster/safely-drain-node/
45. Kubernetes — Debug running pods — https://kubernetes.io/docs/tasks/debug/debug-application/debug-running-pod/
46. Kubernetes — Managing service accounts — https://kubernetes.io/docs/reference/access-authn-authz/service-accounts-admin/
47. Google Cloud — Mitigate security incidents in GKE — https://docs.cloud.google.com/kubernetes-engine/docs/how-to/security-mitigations
48. Sysdig — Agentic threat actor hits the orchestration plane — https://webflow.sysdig.com/blog/agentic-threat-actor-hits-the-orchestration-plane-ai-agent-driven-container-escape
49. CrowdStrike 2026 Global Threat Report findings — https://www.crowdstrike.com/en-us/blog/crowdstrike-2026-global-threat-report-findings/
50. Mandiant M-Trends 2026 — https://cloud.google.com/blog/topics/threat-intelligence/m-trends-2026
51. Unit 42 — npm supply chain attack (Shai-Hulud) — https://unit42.paloaltonetworks.com/npm-supply-chain-attack/
52. CISA alert — Widespread supply chain compromise impacting npm ecosystem — https://www.cisa.gov/news-events/alerts/2025/09/23/widespread-supply-chain-compromise-impacting-npm-ecosystem
53. Christophe Tafani-Dereeper — Privilege escalation in EKS by compromising the instance role of worker nodes — https://blog.christophetd.fr/privilege-escalation-in-aws-elastic-kubernetes-service-eks-by-compromising-the-instance-role-of-worker-nodes/
54. Wiz — EKS security best practices — https://www.wiz.io/academy/container-security/eks-security-best-practices
55. Wiz — Container escape — https://www.wiz.io/academy/container-security/container-escape
56. Dark Reading — Pernicious permissions: Kubernetes cryptomining and cloud data heist — https://www.darkreading.com/cyber-risk/pernicious-permissions-kubernetes-cryptomining-cloud-data-heist
57. Azure Monitor — Activity log (90-day retention, export) — https://learn.microsoft.com/en-us/azure/azure-monitor/platform/activity-log
58. Azure Monitor — Resource logs (not collected by default) — https://learn.microsoft.com/en-us/azure/azure-monitor/essentials/resource-logs
59. Microsoft Defender for Cloud — overview (CNAPP, CSPM, CWPP) — https://learn.microsoft.com/en-us/azure/defender-for-cloud/defender-for-cloud-introduction
60. Azure RBAC — Deny assignments (cannot be directly created) — https://learn.microsoft.com/en-us/azure/role-based-access-control/deny-assignments
61. Azure Policy — deny effect — https://learn.microsoft.com/en-us/azure/governance/policy/concepts/effect-deny
62. AWS — Introduction to Security Hub CSPM (ASFF, cross-account aggregation) — https://docs.aws.amazon.com/securityhub/latest/userguide/what-is-securityhub.html
63. AWS — Setting the workflow status of findings in Security Hub CSPM — https://docs.aws.amazon.com/securityhub/latest/userguide/finding-workflow-status.html
64. Azure CLI — az role assignment — https://learn.microsoft.com/en-us/cli/azure/role/assignment
65. Azure CLI — az ad sp credential — https://learn.microsoft.com/en-us/cli/azure/ad/sp/credential
66. Azure CLI — az network nic — https://learn.microsoft.com/en-us/cli/azure/network/nic