Cloud & Kubernetes Security
Kubernetes attack surface and cluster-compromise paths — kube-api access, RBAC, privileged pods, hostPath, anonymous etcd and node-level escalation.
15 questions
JuniorTheoryVery commonWhat does least privilege mean in cloud IAM, and why are wildcard policies risky?
What does least privilege mean in cloud IAM, and why are wildcard policies risky?
Least privilege grants only the actions and resources a workload truly needs, through short-lived roles instead of long-lived users and keys. A wildcard in the action or resource field grants everything, so one leaked credential means account-wide access.
Common mistakes
- ✗Treating long-lived access keys as equivalent to short-lived roles
- ✗Assuming a wildcard policy is safe because the credential stays secret
- ✗Scoping permissions for humans but leaving machine identities broad
Follow-up questions
- →How do permission boundaries cap what a delegated admin can grant?
- →Why is an unused role with a wildcard resource still an audit finding?
JuniorTheoryVery commonWhat makes an object-storage bucket public, and how does Block Public Access help?
What makes an object-storage bucket public, and how does Block Public Access help?
Effective access is the union of the bucket policy, object ACLs and account settings — any one of them can open the bucket, so it looks private while an ACL exposes it. Block Public Access overrides them at account level, and posture scanning catches drift.
Common mistakes
- ✗Checking only the bucket policy and ignoring object ACLs
- ✗Assuming exposure of your own bucket is the provider's responsibility
- ✗Reading Block Public Access as merely hiding the bucket from listings
Follow-up questions
- →How does posture-management tooling
CSPMdetect a newly public bucket? - →Why can a bucket be private while one object stays world-readable?
MiddleTheoryVery commonWhy is a broad cross-account trust policy dangerous when a vendor needs read access to your bucket?
Why is a broad cross-account trust policy dangerous when a vendor needs read access to your bucket?
The trust policy decides who may assume the role. If it trusts a whole external account or a wildcard principal, any identity there can assume it and act with your permissions — the confused-deputy problem. Pin the exact principal and require a tenant-unique external ID.
Common mistakes
- ✗Trusting a whole external account instead of one named role
- ✗Thinking the vendor's permission policy limits who can assume your role
- ✗Treating the external ID as cosmetic rather than an anti-confused-deputy check
Follow-up questions
- →How would you detect over-broad trust policies across every account you own?
- →Why does a resource policy on the bucket still matter once the role is scoped?
JuniorTheoryCommonHow does a security group differ from a network ACL, and why start from default-deny?
How does a security group differ from a network ACL, and why start from default-deny?
A security group is stateful and attaches to the workload — return traffic is allowed automatically and it holds allow rules only. A network ACL is stateless, filters at the subnet edge and supports deny rules. Both start closed by default.
Common mistakes
- ✗Adding an outbound rule for return traffic a stateful group already allows
- ✗Believing a new security group starts open until rules are added
- ✗Expecting deny rules in a security group instead of a network ACL
Follow-up questions
- →When is a subnet-level network ACL the right place to block a source range?
- →Why is a group that references another group safer than a wide address range?
MiddleTheoryCommonWhy is a disabled cloud audit trail a red flag, and how is log integrity protected?
Why is a disabled cloud audit trail a red flag, and how is log integrity protected?
The audit trail is the only record of which identity called which API, so turning it off destroys the evidence and is itself a classic intruder move. Ship every account's trail to one separate append-only log account, validate log files, and alert on a stopped trail.
Common mistakes
- ✗Treating a stopped trail as routine noise rather than an incident signal
- ✗Keeping the log destination in the same account as the workload
- ✗Assuming transport encryption gives log integrity at rest
Follow-up questions
- →Why should the log account be outside the reach of workload administrators?
- →Which permissions must never be granted on the audit log destination?
MiddleDesignCommonYour analytics bucket holds customer exports. A partner company, running in its own cloud account, must read one prefix of that bucket from its reporting service; your internal ETL role must keep writing to every prefix. Constraints — nothing in the bucket may ever be reachable anonymously; the partner must not receive long-lived access keys from you; an organisation-level guardrail must make a public grant impossible even if an engineer writes one by mistake; every read by the partner must be attributable to a named identity in the audit trail; the design must survive a new bucket being created next quarter without repeating the review. Describe the access design — who gets which permission, where each control lives, and how you would detect drift.
Your analytics bucket holds customer exports. A partner company, running in its own cloud account, must read one prefix of that bucket from its reporting service; your internal ETL role must keep writing to every prefix. Constraints — nothing in the bucket may ever be reachable anonymously; the partner must not receive long-lived access keys from you; an organisation-level guardrail must make a public grant impossible even if an engineer writes one by mistake; every read by the partner must be attributable to a named identity in the audit trail; the design must survive a new bucket being created next quarter without repeating the review. Describe the access design — who gets which permission, where each control lives, and how you would detect drift.
Turn Block Public Access on at account level, plus an organisation guardrail denying any public grant. The partner assumes a role you own, pinned to their principal with an external ID; the bucket policy allows read on one prefix only, and the ETL role write. Reads stay attributable.
Common mistakes
- ✗Treating an unguessable prefix name as an access control
- ✗Granting a whole partner account instead of one named role
- ✗Relying on manual review instead of an organisation-level guardrail
Follow-up questions
- →How does the guardrail keep next quarter's new bucket safe without a review?
- →What would you alert on if the partner's role started reading other prefixes?
MiddleDesignCommonYour hosted CI system deploys one service into the production cloud account. Today the pipeline holds a permanent cloud access key with administrator rights in a project secret. Constraints — no long-lived cloud credentials may live in the CI system at all; only the deploy job of one repository's release branch may obtain production access; the credential must expire within the job; the role may update that one service and nothing else; a compromised build runner must not be able to read customer data, create identities, or disable logging; every deployment must be attributable to a commit in the audit trail; a second team will onboard the same way next month. Describe the design and the controls that keep it least-privilege.
Your hosted CI system deploys one service into the production cloud account. Today the pipeline holds a permanent cloud access key with administrator rights in a project secret. Constraints — no long-lived cloud credentials may live in the CI system at all; only the deploy job of one repository's release branch may obtain production access; the credential must expire within the job; the role may update that one service and nothing else; a compromised build runner must not be able to read customer data, create identities, or disable logging; every deployment must be attributable to a commit in the audit trail; a second team will onboard the same way next month. Describe the design and the controls that keep it least-privilege.
Replace the stored key with OIDC federation — the role's trust policy pins the repository, branch and job claims, so tokens are short-lived and unusable elsewhere. Scope the permission policy to that one service, add a permission boundary, and let the audit trail tie each session to a commit.
Common mistakes
- ✗Assuming an encrypted CI secret makes a permanent admin key acceptable
- ✗Federating without pinning repository and branch claims in the trust policy
- ✗Relying on CI job history instead of the cloud audit trail for attribution
Follow-up questions
- →How do you onboard the second team without widening the existing role?
- →What signal shows the deploy role being assumed from an unexpected branch?
MiddleTheoryCommonHow does envelope encryption work, and why can a KMS key policy grant access on its own?
How does envelope encryption work, and why can a KMS key policy grant access on its own?
Data is encrypted with a per-object data key, itself wrapped by a master key that never leaves the key service; only the wrapped key travels with the data. The key policy is a second authorization layer — it can grant use of the key even where no IAM policy does.
Common mistakes
- ✗Thinking the master key itself encrypts the data and leaves the key service
- ✗Assuming IAM alone decides who can use a key
- ✗Believing a key policy can only restrict, never grant, access
Follow-up questions
- →How does a separate key per tenant limit the blast radius of one key compromise?
- →Why review key policies when auditing who can read an encrypted bucket?
MiddleDebuggingCommonAn instance role's credentials show up in the audit trail from an outside address. What is misconfigured?
An instance role's credentials show up in the audit trail from an outside address. What is misconfigured?
The instance still accepts the token-less v1 metadata protocol and carries a wildcard role, so a request-forgery flaw in the app let its credentials be read and replayed off-host — the foreign address using the instance role is the tell. Require IMDSv2 and hop limit one, scope the role.
Open full question →Common mistakes
- ✗Reading the foreign source address as a NAT gateway rather than credential replay
- ✗Leaving HttpTokens optional because IMDSv2 is described as backwards compatible
- ✗Fixing only the metadata options and leaving the wildcard role in place
Follow-up questions
- →Which audit-trail query finds every instance role used from outside your ranges?
- →Why does a hop limit of one matter once tokens are already required?
MiddleTheoryCommonWhy keep cloud secrets in a managed secret store rather than env vars, and why rotate them?
Why keep cloud secrets in a managed secret store rather than env vars, and why rotate them?
Environment variables, machine images and user-data are readable by anyone who can describe the instance or open a build log, and never expire. A secret store keeps the value out of the image, gates reads by IAM policy, logs access and rotates, so a leak is short-lived.
Common mistakes
- ✗Treating an environment variable as private to the process that reads it
- ✗Assuming an immutable machine image cannot be read back by others
- ✗Skipping rotation because the secret store already encrypts the value
Follow-up questions
- →How does a workload authenticate to the secret store without a bootstrap secret?
- →What log signal shows a secret being read by an unexpected principal?
MiddleDesignCommonYou are placing a payment-processing service into a cloud network. It must read and write one object-storage bucket and call two provider APIs, plus exactly one external partner endpoint. Constraints — no inbound connection from the internet may reach it; traffic to the bucket must never traverse the public internet; outbound traffic to anything other than the partner endpoint must be impossible, not merely logged; operators need administrative sessions without a public bastion host; a compromised application container must not be able to reach the company's other workloads; the design must be auditable by a reviewer who reads only configuration. Describe the network design and the control at each boundary.
You are placing a payment-processing service into a cloud network. It must read and write one object-storage bucket and call two provider APIs, plus exactly one external partner endpoint. Constraints — no inbound connection from the internet may reach it; traffic to the bucket must never traverse the public internet; outbound traffic to anything other than the partner endpoint must be impossible, not merely logged; operators need administrative sessions without a public bastion host; a compromised application container must not be able to reach the company's other workloads; the design must be auditable by a reviewer who reads only configuration. Describe the network design and the control at each boundary.
Put the workload in private subnets with no internet gateway route. Reach the bucket and provider APIs through private endpoints whose policies name only your resources. Send the one partner call through an egress proxy with an allowlist. Use the provider's session service, not a bastion, and a separate account.
Common mistakes
- ✗Assuming a public subnet is safe as long as no inbound port is open
- ✗Logging egress instead of making unapproved destinations unreachable
- ✗Reaching object storage over the internet endpoint because traffic is encrypted
Follow-up questions
- →What does an endpoint policy add beyond the bucket policy itself?
- →How does a separate account bound the blast radius of this workload?
JuniorTheoryOccasionalWhy are anonymous kube-api access and privileged pods the most dangerous defects in a Kubernetes cluster?
Why are anonymous kube-api access and privileged pods the most dangerous defects in a Kubernetes cluster?
Anonymous kube-api is credential-free control-plane access — read or create any resource, i.e. cluster control. A privileged pod (privileged, hostPath, host network) is near-root on its node: mounts host FS, reads other pods' secrets, escapes.
Common mistakes
- ✗Underestimating anonymous kube-api as access to only health endpoints
- ✗Treating a privileged pod as isolated the same as an ordinary one
- ✗Thinking Kubernetes blocks anonymous access by default
Follow-up questions
- →How does a privileged pod with hostPath lead to node compromise?
- →Why is kube-api access equivalent to cluster control?
MiddleTheoryOccasionalWhy does a server-side request forgery SSRF flaw expose instance role credentials, and what does IMDSv2 change?
Why does a server-side request forgery SSRF flaw expose instance role credentials, and what does IMDSv2 change?
The metadata service answers on a link-local address, so an SSRF flaw makes the instance fetch its own role credentials and hand them back — the attacker inherits its IAM permissions. IMDSv2 demands a session token plus a low hop limit, which a blind SSRF cannot supply.
Common mistakes
- ✗Believing the metadata endpoint is unreachable from application code
- ✗Reading IMDSv2 as a performance change rather than an access control
- ✗Assuming role credentials sit on disk instead of behind the metadata service
Follow-up questions
- →How would you audit which instances still accept the v1 metadata protocol?
- →Why does a hop limit of one matter for containers sharing the host network?
SeniorDesignOccasionalYou are threat-modelling a managed Kubernetes cluster. Map its attack surface across four axes — infrastructure (nodes/hypervisor), applications (exposed services and pods), kube-api (access and RBAC), and credentials (etcd, secrets). Which axis carries the highest risk and should be hardened first, and why?
You are threat-modelling a managed Kubernetes cluster. Map its attack surface across four axes — infrastructure (nodes/hypervisor), applications (exposed services and pods), kube-api (access and RBAC), and credentials (etcd, secrets). Which axis carries the highest risk and should be hardened first, and why?
Infrastructure — node OS/kernel, SSH, hypervisor. Apps — exposed nodePort/ingress, Dashboard, privileged pods, untrusted images. kube-api — anonymous access, over-broad RBAC. Credentials — open etcd, namespace secrets. Harden kube-api first: it is cluster-wide control.
Common mistakes
- ✗Reducing the cluster attack surface to a single vector (e.g., the dashboard)
- ✗Treating a privileged pod and anonymous etcd as safe
- ✗Ignoring over-broad RBAC rights as a path from a pod to cluster control
Follow-up questions
- →Why do over-broad RBAC rights on exec or secrets escalate to cluster control?
- →Why is anonymous etcd access as dangerous as kube-api access?
SeniorDesignOccasionalYou are designing data protection for a multi-tenant SaaS platform holding regulated customer records in a shared database and a shared object-storage bucket. Constraints — every tenant's data must stay unreadable to another tenant even if an application bug returns the wrong rows; a compromise of one tenant's key must not expose any other tenant; the platform team must be able to run backups and migrations without ever being able to read plaintext; the regulator requires proof of who could decrypt what at any past moment; a tenant offboarding must render their data unrecoverable within a documented window; internal service traffic must be protected as well as external traffic. Describe the encryption, key-separation and access design and the trade-offs you accept.
You are designing data protection for a multi-tenant SaaS platform holding regulated customer records in a shared database and a shared object-storage bucket. Constraints — every tenant's data must stay unreadable to another tenant even if an application bug returns the wrong rows; a compromise of one tenant's key must not expose any other tenant; the platform team must be able to run backups and migrations without ever being able to read plaintext; the regulator requires proof of who could decrypt what at any past moment; a tenant offboarding must render their data unrecoverable within a documented window; internal service traffic must be protected as well as external traffic. Describe the encryption, key-separation and access design and the trade-offs you accept.
Give each tenant its own master key and key policy wrapping per-object data keys, so a wrong row yields ciphertext another tenant cannot unwrap. Platform roles get backup and migration rights but no decrypt grant. Key changes and decrypts land in an immutable audit trail; offboarding deletes the tenant key.
Common mistakes
- ✗Relying on the application's tenant filter instead of cryptographic separation
- ✗Leaving platform roles with a decrypt grant they do not need for backups
- ✗Treating offboarding as a soft delete rather than destroying the tenant key
Follow-up questions
- →What operational cost does a key per tenant add at ten thousand tenants?
- →How do you prove to a regulator who could decrypt a record last year?
