9.3 Kubernetes Orchestration Security, Serverless (FaaS) & CWPP/CNAPP

9.3 Kubernetes Orchestration Security, Serverless (FaaS) & CWPP/CNAPP

Quick Answer: As cloud workloads evolve from standalone virtual machines to Kubernetes container orchestration and Serverless Function-as-a-Service (FaaS), the security boundaries shift from infrastructure management toward application identity, API control planes, event triggers, and contextual runtime defense. Securing Kubernetes requires hardening the control plane (securing the API server, encrypting etcd at rest with envelope encryption, and enforcing least-privilege RBAC), inverting the flat network model to default-deny via Network Policies, and enforcing Pod Security Standards (PSS Restricted). In Serverless, security focuses on per-function micro-IAM roles, sanitizing warm container execution state, and preventing Denial of Wallet (DoW) attacks. Finally, to eliminate alert fatigue and siloed visibility across VMs, containers, and serverless, modern enterprises deploy Cloud-Native Application Protection Platforms (CNAPP)—converging CWPP, CSPM, and CIEM into a unified contextual risk graph that prioritizes exploitable attack paths.

Workload security in modern cloud computing encompasses diverse computational abstractions. Organizations frequently operate a hybrid continuum: legacy monolithic applications residing on virtual machines, microservices orchestrated at scale via Kubernetes clusters, and event-driven data pipelines running entirely on serverless compute.

According to CSA Security Guidance v5 (Domain 8: Cloud Workload Security), managing risk across this heterogeneous landscape requires an understanding of orchestration control planes, the unique attack vectors native to serverless execution environments, and the consolidation of cloud security monitoring tools into unified platforms.

---

Kubernetes Security Architecture: Hardening the Cluster

Kubernetes has emerged as the operating system of the cloud. However, an unhardened Kubernetes cluster presents an expansive attack surface spanning multiple architectural components:

┌────────────────────────────────────────────────────────────────────────┐
│                     KUBERNETES CONTROL PLANE ARCHITECTURE              │
├────────────────────────────────────────────────────────────────────────┤
│                                                                        │
│        ┌──────────────────────────────────────────────────────┐        │
│        │                KUBE-APISERVER                        │        │
│        │ • TLS 1.3 Termination & OIDC Authentication          │        │
│        │ • Anonymous Access Disabled (--anonymous-auth=false) │        │
│        │ • Private Endpoint (Zero Public Ingress)             │        │
│        │ • Audit Logging Enabled (Metadata & RequestResponse) │        │
│        └───────┬───────────────────────────────┬──────────────┘        │
│                │                               │                       │
│       mTLS 2379│                      mTLS 10250│                      │
│                ▼                               ▼                       │
│   ┌─────────────────────────┐     ┌─────────────────────────┐          │
│   │         ETCD            │     │         KUBELET         │          │
│   │ • Key-Value Datastore   │     │ • Node-Level Agent      │          │
│   │ • mTLS Authentication   │     │ • Port 10255 Disabled   │          │
│   │ • Envelope Encryption   │     │ • Webhook AuthZ Enabled │          │
│   │   at Rest via KMS       │     │ • Anonymous Auth Off    │          │
│   └─────────────────────────┘     └────────────┬────────────┘          │
│                                                │                       │
│                                                ▼                       │
│                                   ┌─────────────────────────┐          │
│                                   │ Container Runtime (CRI) │          │
│                                   │ • Pods & Microservices  │          │
│                                   └─────────────────────────┘          │
│                                                                        │
└────────────────────────────────────────────────────────────────────────┘

1. Kube-apiserver Hardening

The kube-apiserver is the central nervous system of Kubernetes. Every administrative command (kubectl), node status update, and internal controller synchronization traverses this REST API.

• Disable Anonymous Authentication: The API server must be configured with --anonymous-auth=false. By default, unauthenticated requests can be mapped to the system:unauthenticated group, which misconfigured RBAC rules might inadvertently grant access to.
• Private Control Plane Endpoints: Cloud-managed Kubernetes services (Amazon EKS, Azure AKS, Google GKE) allow clusters to be provisioned with Private API Server Endpoints. Public internet access to the control plane should be completely disabled; access must be restricted to authorized enterprise VPNs, DirectConnect circuits, or strict CIDR whitelists.
• Comprehensive Audit Logging: Audit logging must be activated with an explicit AuditPolicy. Logs should capture security events at the RequestResponse level for sensitive operations (such as secret reads or RBAC modifications) and stream immediately to an immutable centralized SIEM.

2. etcd Hardening: Encryption at Rest & mTLS

The etcd distributed key-value store holds the entire state of the Kubernetes cluster, including all configuration maps, deployment specifications, and—most critically—Kubernetes Secrets (passwords, tokens, private keys).

• Mutual TLS (mTLS): Communication between the kube-apiserver and etcd nodes must enforce strict mutual TLS authentication using a dedicated, isolated internal Certificate Authority (CA). Network access to etcd ports (TCP 2379 for clients, 2380 for peer communication) must be strictly firewalled.
• Encryption at Rest (Envelope Encryption): By default, Kubernetes secrets stored in etcd are not encrypted; they are merely stored as plaintext, base64-encoded strings. Anyone who gains access to an etcd backup snapshot or reads the underlying storage volume can view all cluster credentials in plaintext.
• Remediation: Administrators must configure an EncryptionConfiguration provider file. The optimal enterprise pattern is deploying an external KMS Plugin (such as AWS KMS, Azure Key Vault, or HashiCorp Vault) to perform Envelope Encryption: a local Data Encryption Key (DEK) encrypts the secrets in etcd, while the DEK itself is encrypted by a Key Encryption Key (KEK) managed in the secure cloud KMS.

3. Kubernetes Role-Based Access Control (RBAC) & ServiceAccounts

Kubernetes RBAC governs whether a subject (user, group, or service account) can perform an API verb (such as get, list, create, delete) on a target resource (such as pods, services, secrets).

• Principle of Least Privilege in RBAC:
  • Avoid wildcard verbs ("verbs": ["*"]) and wildcard resources ("resources": ["*"]).
  • Restrict access to high-risk API verbs: granting an entity permission to create pods allows that entity to craft a pod specification that mounts the host node's root filesystem (/), achieving instant host node compromise.
  • Restrict bind and escalate permissions: these verbs allow a user to assign permissions they do not possess, enabling rapid privilege escalation.
• Hardening ServiceAccounts:
  • Applications running in pods interact with the API server via bound ServiceAccounts.
  • In pods that do not require programmatic access to the Kubernetes API, disable automatic token mounting by declaring automountServiceAccountToken: false in the Pod or ServiceAccount specification.
  • Transition to Bound Service Account Tokens (Projected Volume Tokens): legacy Kubernetes versions generated static, non-expiring JWT tokens stored as secrets. Modern clusters issue cryptographically signed, short-lived tokens with audience-binding (aud) and time-to-live (TTL) expiration, tied strictly to the pod's lifecycle.

4. Kubernetes Network Policies: Default-Deny Microsegmentation

By default, Kubernetes implements an entirely flat, open network model. Any pod within the cluster can communicate directly with any other pod across any namespace without restriction.

To establish zero-trust microsegmentation, organizations must deploy a Container Network Interface (CNI) plugin that supports Network Policies (such as Calico, Cilium, or cloud-native VPC CNI policy engines):

• The Default-Deny Architectural Invariant: Every namespace must be configured with a baseline Default-Deny Ingress and Default-Deny Egress NetworkPolicy. All traffic is blocked by default.
• Explicit Label-Based Whitelisting: Security teams author granular NetworkPolicies that selectively permit traffic based on podSelector and namespaceSelector metadata tags, restricting communication to specific TCP/UDP ports. For example, a frontend pod is permitted egress only to backend API pods on TCP port 8080, and backend API pods are permitted egress only to the database cluster on TCP port 5432.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: default-deny-all
  namespace: production
spec:
  podSelector: {}          # Matches all pods in the namespace
  policyTypes:
  - Ingress
  - Egress                 # Blocks all incoming and outgoing traffic by default

5. Pod Security Standards (PSS) & Pod Security Admission (PSA)

Historically, Kubernetes enforced pod security via PodSecurityPolicies (PSP). PSP was notoriously complex, lacked declarative visibility, and was officially removed in Kubernetes v1.25. It was replaced by Pod Security Standards (PSS) enforced by the built-in Pod Security Admission (PSA) controller.

PSS defines three distinct security profiles applied via namespace labels:

1. Privileged: Completely unrestricted. Intended strictly for system-level infrastructure components (e.g., CNI network plugins, storage CSI drivers, monitoring daemons) that require raw host access.
2. Baseline: Minimally restrictive profile that prevents known privilege escalations with minimal application impact. It blocks host namespaces (hostPID, hostIPC, hostNetwork), host path volumes, host ports, and privileged containers.
3. Restricted: Heavily hardened, cloud-native best-practice profile. It enforces non-root execution (runAsNonRoot: true), requires dropping all capabilities except NET_BIND_SERVICE, enforces read-only root filesystems, and restricts volume types strictly to safe abstractions (configMap, secret, emptyDir).

PSA operates across three independent modes per namespace:

• enforce: Rejects pod creation if the pod violates the specified standard (returns HTTP 403).
• audit: Permits pod creation but logs an audit event to the API server log.
• warn: Permits pod creation but returns a visible warning message to the user executing the kubectl command.

---

Serverless (FaaS) Security Architecture

In Serverless Function-as-a-Service (FaaS) computing (e.g., AWS Lambda, Azure Functions, Google Cloud Functions), the cloud provider completely abstracts and manages the underlying virtual machines, operating system hardening, container runtime, language runtime patching, and physical host security. However, serverless architectures introduce unique threat vectors that require specialized engineering.

┌────────────────────────────────────────────────────────────────────────┐
│                     SERVERLESS (FaaS) SHARED RESPONSIBILITY            │
├────────────────────────────────────────────────────────────────────────┤
│  CLOUD SERVICE PROVIDER RESPONSIBILITY                                 │
│  • Physical infrastructure, data center security, hardware             │
│  • Hypervisor, microVM virtualization (AWS Firecracker / gVisor)       │
│  • Host OS patching, language runtime maintenance (Node.js, Python)   │
│  • Auto-scaling, capacity provisioning, microVM isolation              │
├────────────────────────────────────────────────────────────────────────┤
│  CLOUD CUSTOMER RESPONSIBILITY                                         │
│  • Application code security & third-party software dependencies (SCA) │
│  • Function-level IAM Execution Roles (Least Privilege)                │
│  • Event trigger validation & input sanitization                       │
│  • State sanitization in warm container reuse (/tmp management)        │
│  • Concurrency throttling to prevent Denial of Wallet (DoW)           │
│  • Secrets management (retrieving tokens at runtime from KMS/Vault)    │
└────────────────────────────────────────────────────────────────────────┘

1. Function-Level Least Privilege IAM Roles

A critical anti-pattern in serverless deployments is the "Monolithic Role" anti-pattern, where an enterprise creates a single shared IAM role (e.g., ServerlessApplicationRole) granted broad permissions across S3, DynamoDB, SQS, and KMS, and assigns it to dozens of functions.

Under CSA Guidance v5, enterprises must enforce Micro-IAM Roles:

• Every individual serverless function must possess its own dedicated, fine-grained Execution Role.
• If Function-A merely reads from a specific SQS queue and writes to a specific DynamoDB table, its role must permit only sqs:ReceiveMessage, sqs:DeleteMessage, and dynamodb:PutItem restricted strictly to those exact Amazon Resource Names (ARNs). It must have zero access to S3, KMS, or neighboring databases.

2. Cold Starts vs. Warm Container Execution & State Leakage

To minimize invocation latency, cloud providers utilize Container Reuse (Warm Starts):

• Cold Start: When a function is invoked for the first time (or scales out), the provider initializes a new microVM execution environment (e.g., using AWS Firecracker), downloads the function code, and boots the runtime.
• Warm Execution: When subsequent invocations occur within a short window (typically 5 to 15 minutes), the provider routes the new event into the same warm execution environment to avoid boot latency.

The Security Risk of Warm Execution

During warm execution, global variables, in-memory objects, and local scratch disk storage (/tmp) persist across invocations.

• State Leakage Vector: If Function Invocation 1 downloads a sensitive document belonging to Customer X, decrypts a customer API key, or writes temporary PII to /tmp/data.json, and the developer fails to explicitly sanitize that state upon invocation completion, a subsequent Invocation 2 processing a request for Customer Y executing inside that same warm container can read Customer X's residual data from memory or /tmp.
• Engineering Rule: Application code must treat the execution environment as stateless: explicitly sanitize local storage, scrub in-memory buffers, and never cache sensitive tenant data in global variables.

3. Event Trigger Validation & Denial of Wallet (DoW)

In serverless architectures, functions are driven entirely by Event Sources (HTTP requests via API Gateway, object uploads in S3, messages in Kafka/SQS, database change streams in DynamoDB Streams).

• Event Payload Injection: Perimeter web application firewalls (WAFs) only inspect HTTP traffic traversing the API gateway. If a function is triggered by an internal message queue (SQS) or an object upload notification (S3), traditional perimeter WAFs are entirely bypassed. Attackers can inject malicious SQL, command injection, or deserialization payloads inside event metadata (such as an S3 object key name). Functions must execute strict schema validation and input sanitization at the function boundary.
• Denial of Wallet (DoW) & Recursive Invocation Floods: Serverless billing is calculated dynamically per millisecond of compute execution and invocation volume. If an attacker floods a public serverless endpoint with requests—or if an application defect triggers a recursive invocation loop (e.g., an S3 object creation triggers a Lambda function that writes a modified object back into the same S3 bucket, creating an infinite recursive storm)—the enterprise faces catastrophic financial charges (Denial of Wallet) and account-wide concurrency exhaustion. Mitigation: Configure reserved concurrency limits, automated billing alarms, execution timeouts, dead-letter queues (DLQs), and provider recursion-detection mechanisms.

---

Workload Security Evolution: From Host Tools to CNAPP

As enterprise architectures expanded across physical data centers, IaaS virtual machines, Kubernetes clusters, and serverless functions, security teams deployed isolated point solutions. This fragmentation created massive operational friction, blind spots, and alert fatigue, driving the consolidation into Cloud-Native Application Protection Platforms (CNAPP).

┌────────────────────────────────────────────────────────────────────────┐
│                     THE EVOLUTION TO CONVERGED CNAPP                   │
├────────────────────────────────────────────────────────────────────────┤
│                                                                        │
│   ┌───────────────────────────┐         ┌──────────────────────────┐   │
│   │           CSPM            │         │          CWPP            │   │
│   │ Cloud Security Posture    │         │ Cloud Workload Protection│   │
│   │ Management                │         │ Platform                 │   │
│   │ • Scans Control Plane APIs│         │ • Inside Workload Agent  │   │
│   │ • Misconfigurations (S3) │         │ • Runtime Defense (eBPF) │   │
│   │ • CIS Benchmark Auditing  │         │ • Vulnerability Scans    │   │
│   └─────────────┬─────────────┘         └────────────┬─────────────┘   │
│                 │                                    │                 │
│                 │        ┌──────────────────┐        │                 │
│                 └───────►│      CNAPP       │◄───────┘                 │
│                          │ CONVERGED ENGINE │                          │
│                 ┌───────►│                  │◄───────┐                 │
│                 │        └──────────────────┘        │                 │
│                 │                                    │                 │
│   ┌─────────────┴─────────────┐         ┌────────────┴─────────────┐   │
│   │           CIEM            │         │      KSPM / SHIFT-LEFT   │   │
│   │ Cloud Infrastructure      │         │ Kubernetes Posture &     │   │
│   │ Entitlement Management    │         │ IaC Supply Chain         │   │
│   │ • IAM Graph Analysis      │         │ • Pod Security Standards │   │
│   │ • Over-privileged Roles   │         │ • Terraform / Helm Scans │   │
│   │ • Toxic Permission Combos │         │ • SBOM Attestation       │   │
│   └───────────────────────────┘         └──────────────────────────┘   │
│                                                                        │
└────────────────────────────────────────────────────────────────────────┘

1. Cloud Workload Protection Platforms (CWPP)

Defined by Gartner and referenced throughout CSA guidance, a Cloud Workload Protection Platform (CWPP) is a workload-centric security capability that provides comprehensive protection across physical machines, IaaS VMs, containers, and serverless architectures.

• Core Capabilities: System integrity monitoring, host-based vulnerability management, memory protection, runtime behavioral monitoring (via eBPF/Falco), host microsegmentation, and anti-malware.
• Limitation: CWPP operates inside the workload. It lacks context regarding cloud control plane misconfigurations, cloud network routing tables, and external IAM role assignments.

2. Cloud Security Posture Management (CSPM)

CSPM tools analyze the cloud provider's management plane (control plane APIs). They discover unencrypted storage buckets, public security groups, missing MFA on administrative accounts, and non-compliance with regulatory frameworks (PCI DSS, ISO 27001, CIS).

• Limitation: CSPM operates purely outside the workload via APIs. It cannot inspect processes running inside a container, detect a web shell executing in memory, or observe active network connections.

3. Cloud Infrastructure Entitlement Management (CIEM)

CIEM platforms specialize in managing identity governance and access permissions across complex multi-cloud IAM hierarchies. CIEM analyzes effective permissions, detects over-privileged identities, uncovers unused permissions, and identifies privilege escalation pathways.

• Limitation: CIEM analyzes static identity relationships; it cannot detect active software vulnerabilities on the compute instances that assume those identities.

4. Cloud-Native Application Protection Platforms (CNAPP)

A Cloud-Native Application Protection Platform (CNAPP) converges CWPP, CSPM, CIEM, Kubernetes Security Posture Management (KSPM), and Shift-Left IaC Security into a single unified security platform.

The Power of Attack Path Analysis (Contextual Correlation)

The defining breakthrough of CNAPP is replacing isolated, disconnected alerts with Contextual Attack Path Analysis using an enterprise Risk Graph:

┌────────────────────────────────────────────────────────────────────────┐
│                     CNAPP CONTEXTUAL RISK CORRELATION                  │
├────────────────────────────────────────────────────────────────────────┤
│                                                                        │
│   [ISOLATED POINT TOOL PERSPECTIVE - HIGH ALERT FATIGUE]               │
│   • CWPP Alert: Found CVE-2024-XXXX (CVSS 9.8) on 500 instances!       │
│   • CSPM Alert: Security Group has Port 80 open to the Internet!       │
│   • CIEM Alert: VM Instance Profile possesses Admin IAM Privileges!    │
│   *Result: Security team receives 1,000 disconnected alerts; panics.*  │
├────────────────────────────────────────────────────────────────────────┤
│   [CNAPP CONTEXTUAL GRAPH PERSPECTIVE - ATTACK PATH RESOLUTION]        │
│                                                                        │
│   Instance A:                                                          │
│   • Has CVE-2024-XXXX (CWPP)                                           │
│   • BUT sits in private subnet with no internet route (CSPM)           │
│   • AND has read-only S3 role (CIEM)                                   │
│   ──► CNAPP Verdict: Low Exploitability / Priority 3                   │
│                                                                        │
│   Instance B:                                                          │
│   • Has CVE-2024-XXXX (CWPP)                                           │
│   • AND is directly exposed to Internet via ALB Port 443 (CSPM)        │
│   • AND instance IAM role can execute iam:PassRole & ec2:* (CIEM)      │
│   ──► CNAPP Verdict: CRITICAL ATTACK PATH DETECTED / PRIORITY 1        │
│       (Active RCE directly yields complete cloud account takeover!)     │
│                                                                        │
└────────────────────────────────────────────────────────────────────────┘

By correlating workload runtime state, network reachability, software vulnerabilities, and cloud identity entitlements, CNAPP filters out benign background noise and directs engineering remediation efforts to actual, exploitable toxic risk combinations.

---

Comparison: Workload Security Solutions Taxonomy

---

Common Pitfalls & Real-World Anti-Patterns

1. Base64 Encoding Conflation: Believing that Kubernetes Secrets are encrypted by default. Base64 is an encoding format for binary data serialization, not an encryption mechanism. Without enabling EncryptionConfiguration with a KMS provider, secrets are exposed in plaintext in etcd.
2. Flat Kubernetes Networks: Neglecting to deploy Network Policies, leaving clusters vulnerable to rapid lateral movement where compromising a low-security public frontend pod grants immediate network access to backend payment databases.
3. Monolithic Serverless Execution Roles: Reusing a single IAM role across dozens of Lambda functions to simplify development. If one function is compromised via an event injection flaw, the attacker gains full administrative access to all backend resources.
4. Relying Exclusively on Isolated Point Scanners: Deploying a standalone CWPP scanner and an independent CSPM tool. Security teams drown in thousands of uncorrelated alerts, failing to identify toxic combinations where an unpatched vulnerability co-exists with public network exposure and excessive IAM entitlements.