Cloud Runtime Security: Defenders, collections and block-versus-alert
Domain 2 tests cloud runtime security: the Defender sensor estate, runtime policy design, and how runtime signals differ from posture findings. Expect design questions on which Defender type fits a workload, how collections scope policy, and when a policy should alert rather than block.
Defender types and placement
- Container Defender: runs as a DaemonSet in Kubernetes, one pod per node; also runs as a container on Docker hosts.
- Host Defender: agent on Linux hosts for file integrity monitoring, anti-malware and host process policy.
- Serverless Defender: function layer or extension for AWS Lambda and comparable services; detects and alerts, it does not block.
- App-Embedded Defender: sidecar or embedded deployment for workloads you cannot instrument at node level. Defenders communicate outbound to the Compute console on port 8083 or through a proxy; sizing scales with node count, image scan volume and log throughput.
Policy model
Policies are scoped by collections - rules matching image name, namespace, labels, hostname or cloud account. Runtime policy families include process execution, file system monitoring, network (Cloud Native Network Segmentation), container runtime, malware and WAAS / Cloud Native Application Firewall with OWASP-style rule sets. Each policy runs in monitor (alert) or active (block) mode, and blocking policies should be baselined first.
Worked example
A miner binary executes inside a payment pod. The process policy for the payments collection was learned in monitor mode for two weeks. You now switch it to active with an explicit allowlist of the three binaries the application needs. The exec is blocked, an incident is raised with the container image, parent process and node, and the image hash is queued for registry scanning so the next pull is caught earlier.
Traps
Flipping to active before learning the baseline - the most common cause of self-inflicted production outage in this domain. Believing Serverless Defender can block. Forgetting that collections define policy scope, so a host policy placed in a container collection does nothing. Ignoring Defender resource requests and limits on dense nodes.