Runtime and cloud security
What you will be able to do
- Apply the cloud shared responsibility model to identify which security controls a customer must implement for IaaS, PaaS, and SaaS deployments.
- Use CIS Benchmarks Level 1 to harden a cloud compute instance.
- Describe how container image scanning and Kubernetes RBAC reduce the attack surface of a containerised workload.
- Explain how Falco uses eBPF to detect runtime threats without kernel module installation.
With an understanding of the previous section in place, the discussion can now turn to 19.1 the shared responsibility model, which builds directly on these foundations.
Real-world breach · 29 July 2019
A misconfigured firewall and a metadata request. 100 million records stolen.
On 29 July 2019, Paige Thompson, a former AWS engineer, exploited a misconfigured Web Application Firewall (WAF) at Capital One. The WAF was configured without adequate restrictions on outbound calls. Thompson used Server-Side Request Forgery (SSRF) to trick the WAF into making a request to the EC2 instance metadata service at 169.254.169.254. That internal endpoint returned temporary IAM credentials attached to the instance.
With those credentials, Thompson discovered the associated IAM role carried overly permissive S3 access. She downloaded approximately 106 million customer records, including names, addresses, credit scores, and Social Security numbers. Thompson was arrested the same day after posting about the data on GitHub. She pleaded guilty in 2022.
AWS infrastructure was not compromised. The WAF misconfiguration, IAM permission scope, and S3 bucket access controls were entirely Capital One’s responsibility under the shared responsibility model. The US Office of the Comptroller of the Currency (OCC) fined Capital One $80 million. A class action settlement reached $190 million.
Capital One was using AWS , a cloud provider with extensive security certifications. How did the breach happen?
Capital One’s cloud provider was not at fault. Under the shared responsibility model, the WAF configuration, IAM policies, and S3 bucket permissions were entirely Capital One’s responsibility. Understanding where provider responsibility ends and customer responsibility begins is the first requirement of cloud security.
19.1 The shared responsibility model
Cloud providers secure the cloud itself: physical data centres, network fabric, hypervisors, and managed services. Customers are responsible for everything they run inside the cloud , operating systems, application code, identity and access management, data classification, and configuration of every service they consume. The boundary shifts depending on the service model in use.
The distinction is not theoretical. The Capital One breach illustrates it precisely. AWS managed the underlying infrastructure without fault. The customer-owned WAF, IAM role, and S3 permissions were all misconfigured, and those were entirely within Capital One’s side of the boundary.
With an understanding of 19.1 the shared responsibility model in place, the discussion can now turn to 19.2 cloud security posture management (cspm), which builds directly on these foundations.
“Customers are responsible for the security of their workloads, applications, and data , including proper configuration of the services they use.”
AWS Shared Responsibility Model
“Cloud security posture management tools help organizations continuously monitor cloud infrastructure for misconfigurations and policy violations. Organizations should implement automated CSPM monitoring aligned to CIS Benchmarks or equivalent standards to maintain ongoing visibility into their cloud security posture.”
NIST SP 800-144: Guidelines on Security and Privacy in Public Cloud Computing, Section 4.1 (2011, reaffirmed 2023)
Common misconception
“The cloud provider handles our security.”
Providers secure physical infrastructure, hypervisors, and managed services. Identity, data, application configuration, and network controls remain the customer’s responsibility across all service models.
19.2 Cloud Security Posture Management (CSPM)
CSPM tools continuously scan a cloud environment and compare its configuration against security benchmarks. The most widely used benchmarks are the CIS (Center for Internet Security) Benchmarks. Level 1 contains scored, practical hardening steps that apply to most organisations without significantly affecting functionality. Level 2 is more restrictive and may introduce operational trade-offs.
Common misconfiguration findings include S3 buckets set to public access by default, EC2 security groups permitting inbound SSH from any IP address (0.0.0.0/0 on port 22), and root account usage without multi-factor authentication. These three findings appear in the majority of CSPM audits and represent the most frequently exploited cloud attack vectors. CSPM tooling examples include AWS Security Hub, Microsoft Defender for Cloud, and Google Security Command Center.
With an understanding of 19.2 cloud security posture management (cspm) in place, the discussion can now turn to 19.3 container image security, which builds directly on these foundations.
19.3 Container image security
A container image is an ordered set of filesystem layers. Each layer may introduce vulnerabilities: the base OS image may include packages with known CVEs, installed language dependencies may be outdated, application code may embed secrets, and prior build steps may leave sensitive files in intermediate layers. Attackers target all four surfaces.
Trivy (by Aqua Security) is a widely adopted open-source scanner that checks OS packages and language dependencies against the CVE database. The practical baseline for container image security is: use minimal base images (distroless or Alpine), never configure the container to run as root, pin image digests rather than mutable tags, and run a CVE scanner in CI before every push to the registry.
With an understanding of 19.3 container image security in place, the discussion can now turn to 19.4 kubernetes rbac and network policies, which builds directly on these foundations.
Common misconception
“Container isolation means a compromise cannot spread beyond the container.”
Containers share the host kernel. A container escape vulnerability , such as CVE-2019-5736, which affected the runc container runtime , can give an attacker full host-level access.
19.4 Kubernetes RBAC and Network Policies
Kubernetes Role-Based Access Control (RBAC) uses three objects: a Role (which defines permitted API verbs and resources), a RoleBinding (which attaches the Role to a subject), and a Subject (a User, Group, or ServiceAccount). The principle of least privilege applies directly: each ServiceAccount should be bound to a Role that allows only the specific API verbs the workload requires. Wildcard permissions (verbs: [“*”]) on any ServiceAccount are a high-severity misconfiguration.
Kubernetes Network Policies work on a default-deny model: create a policy that denies all ingress and egress, then add explicit allow rules for only the required traffic paths. For example, a payment-service pod should allow egress only to the database-service on port 5432. Without a Network Policy, all pods in a namespace can communicate freely with each other and with the internet.
With an understanding of 19.4 kubernetes rbac and network policies in place, the discussion can now turn to 19.5 runtime threat detection with falco, which builds directly on these foundations.
19.5 Runtime threat detection with Falco
Falco, a CNCF graduated project originally developed by Sysdig, provides runtime security for containerised workloads. It intercepts Linux system calls using eBPF (extended Berkeley Packet Filter) probes. eBPF runs verified bytecode in a kernel sandbox, providing deep system call visibility without the stability risk of a traditional loadable kernel module.
Falco rules describe permitted behaviour. When a system call violates a rule, Falco generates an alert. Common rule examples include: a process spawned inside a container that was not in the expected process list, a write to /etc/passwd from within a container, or a network connection to an unexpected external IP address. Alert output can be sent to stdout, a SIEM, or a Slack channel via the Falco output plugin framework.
Under the AWS shared responsibility model, who is responsible for patching the guest operating system on an EC2 instance?
Which component does Falco use to intercept system calls without installing a kernel module?
Capital One's 2019 breach began with which technique?
Key takeaways
- Under the shared responsibility model, the cloud provider secures the infrastructure; the customer secures their workloads, configurations, identity, and data.
- CSPM tools check cloud configuration against benchmarks like CIS Level 1 continuously , misconfigured S3 buckets and open security groups are the most common findings.
- Container image security means using minimal base images, pinning digests, never running as root, and scanning in CI before every push.
- Kubernetes RBAC follows least privilege: each ServiceAccount should have only the API verbs it needs , wildcards are a high-severity misconfiguration.
- Falco uses eBPF to intercept system calls at runtime, detecting container escapes, unexpected network connections, and file write anomalies without a kernel module.
You can now secure cloud and container environments. But your applications depend on third-party code - libraries, packages, and vendor services. How do you manage the risk that someone else's code introduces into your system? Module 20 covers supply chain security.
Standards and sources cited in this module
AWS Shared Responsibility Model
Customer and provider responsibilities
The definitive statement of which security controls fall to the customer vs the provider for AWS IaaS, PaaS, and managed services.
Level 1 and Level 2 hardening profiles
The consensus-based configuration standards referenced in CSPM tooling.
NIST SP 800-190: Application Container Security Guide
Section 4: Threat and countermeasures
NIST guidance on container image, registry, orchestration, and runtime security.
Rules and eBPF driver
Describes how Falco uses eBPF to detect runtime threats with example rules.
OCC Press Release: Capital One Settlement, August 2020
Findings on misconfigured WAF and IAM
The regulatory finding that confirms the SSRF attack vector and the $80M fine.