CCSP Cloud Application Architecture: WAF, Sandboxing and Kubernetes

Cloud application architecture, in CCSP terms, is the set of components that sit around and between an application's code and protect it at run time: supplemental security components in the request path, cryptography applied at the right layer, sandboxes that contain untrusted code, and the virtualization and orchestration platforms (containers, Docker, Kubernetes, microservices) the application runs on. Sub-domain 4.6 names four official skills:

• Supplemental security components: web application firewall (WAF), database activity monitoring (DAM), XML firewalls, API gateways and load balancers.
• Cryptography: where encryption starts and ends inside the application stack, and what each choice hides from whom.
• Sandboxing: isolated execution of code or files you cannot trust.
• Application virtualization and orchestration: encapsulated applications, microservices, containers, Docker and Kubernetes.

Almost every question on this topic is a placement question: several real controls could help, and the right one is the one that operates at the layer where the stated risk lives, is run by the party the scenario trusts, and enforces rather than merely observes. Neighbouring material is covered elsewhere: object-level authorization and API design belong to verified secure software (4.5), service identity and secrets management to IAM design (4.7), image scanning and signing to the secure SDLC and assurance topics, and container kernel sharing and hypervisor isolation to cloud infrastructure (Domain 3).

A web application firewall is a layer 7 control that inspects the content of HTTP requests and responses (paths, parameters, headers, cookies and bodies) and blocks those that match attack patterns such as SQL injection, cross-site scripting, path traversal and protocol abuse. That is what separates it from the components it is often confused with:

Virtual patching. When a known flaw cannot be fixed in code quickly, a WAF rule that inspects the vulnerable parameter and blocks the exploit pattern stops attacks in the meantime. It is a compensating control, not a fix: the code still has to be corrected, and the rule should be retired only after the fix ships. An alert-only tool (IDS, database monitoring) shows the attack continuing; it does not stop it.

Tuning before blocking. Managed rule sets are written for generic traffic and will misfire on a specific application's legitimate requests. The safe rollout is to run the rules in detection-only (log or count) mode against real production traffic, review what they match, add exclusions or adjust rules for false positives, and only then switch to blocking. What makes this safe is that the tuning evidence comes from the traffic the rules will actually face, with the full rule set in place.

The limit. A WAF judges whether a request is well formed and free of attack patterns. It does not know that invoice 1043 belongs to a different customer from the signed-in caller, so broken object-level authorization (changing an ID in the URL) passes straight through. No WAF rule can fix it; only an authorization check in the service that owns the data does (see 4.5).

Database activity monitoring (DAM) captures the SQL statements users, applications and administrators execute, in real time and independently of the database's own audit trail, and alerts on policy violations such as a privileged user reading bulk customer data. Its value is separation of duties: native auditing is configured and stored by the same administrators it is meant to watch, so an administrator who misuses access can also edit or disable the record. A DAM run by the security team, writing to a store the database administrators have no rights over, is a control they cannot switch off.

Encryption does not answer the insider question. Transparent database encryption and storage encryption protect against stolen disks and backups, but the database decrypts data for anyone authorized to query it, including its administrators. Role restrictions inside the database are also administered by those same administrators.

DAM comes in two deployment styles, and the exam tests their blind spots:

When the gap is local or encrypted access, the fix is host agents, not more network mirroring. In IaaS you can deploy either style; in a managed database (PaaS) you usually cannot install agents, so you rely on the provider's activity streams or audit features exported to a store the customer's security team controls.

An XML firewall (often an XML gateway) is a layer 7 component that parses and inspects XML messages before they reach the services, enforcing rules a generic network firewall or load balancer cannot. Its typical functions are:

• Schema validation: rejecting messages that do not conform to the published XSD (unexpected elements, wrong types, oversized fields).
• Resource-exhaustion limits: capping entity expansion, nesting depth and document size, which defeats "billion laughs" style entity-expansion attacks.
• XML external entity (XXE) defence: refusing documents that carry a DTD or entity declarations, so a message cannot make the parser fetch a local file or an internal URL and return its contents.
• Message-level security: verifying WS-Security signatures and handling XML encryption, so integrity and origin are proved for the message itself rather than only for the transport hop.

Two near-twins matter. First, XXE is carried in the document's DTD, which the parser processes on its own; validating the body against an XSD does not by itself stop a parser from resolving external entities, so the control that blocks the class of attack is one that rejects DTDs and entity declarations (and, in the application, a parser configured with them disabled). Second, authentication at an API gateway proves who sent the message, not that its content is safe: a properly authenticated partner can still send a malicious document. The XML firewall inspects content; the gateway decides who may call.

An API gateway is the single entry point for client calls to a set of back-end APIs, where common policy is enforced once: authentication of the caller (API keys, OAuth 2.0 access tokens, mutual TLS), coarse authorization, throttling and quotas, request validation, routing and version management, and consistent logging. When dozens of services each implement their own token checks and throttling, they drift apart and fall out of date; routing external calls through a gateway that applies one policy set fixes the inconsistency architecturally. The fix is architectural because the problem is architectural: policy implemented separately by each team will always diverge.

Quotas follow the credential. Gateways associate each consumer's API key or client identity with a usage plan (rate limit, burst and monthly quota), so limits follow the partner wherever it calls from. Controls keyed to source IP address, such as WAF rate rules or load balancer connection limits, cannot tell apart partners behind a shared corporate egress address and cannot express a monthly plan.

What a gateway is not. It is the front door, not the only lock. Fine-grained authorization ("may this user see this record?") stays in the service, and services must not assume that a request arriving from inside the network has already passed the gateway (see the microservices section).

A load balancer distributes client sessions across a pool of back-end servers, performs health checks, hides back-end addresses and absorbs some volumetric abuse; its security impact comes mostly from where TLS ends. There are three patterns:

When a policy requires encryption on every network hop and a WAF must still read request content, the design is terminate, inspect, re-encrypt: TLS from client to balancer, a new TLS session to the WAF, and another from the WAF to each server. Any hop left in clear text breaks the rule however well isolated it is, and pass-through would leave the WAF nothing to read.

Client certificates. In mutual TLS, the client proves possession of its private key to whichever endpoint completes the handshake. If the balancer terminates, the balancer validates the certificate and can only pass a copy onward in a header, which the server must trust the balancer to have checked. If the servers themselves must verify each device with no trusted intermediary, the balancer must pass TLS through at layer 4.

Where encryption is applied decides who can still read the data. Each layer hides data from a different adversary:

So when the requirement is that neither the provider nor the company's own DBAs can read a field through the database, the field must be encrypted in the application with keys the database cannot use, before it is stored. Holding the key in a customer-owned HSM does not change who can read decrypted query results if the database itself performs the decryption.

Searching encrypted fields. Strong field encryption uses a random IV (nonce) per value, so the same plaintext never produces the same ciphertext and you cannot look up a record by encrypting the search term again. The standard pattern is a blind index: store, beside the ciphertext, a keyed hash (HMAC) of the normalised value, computed with a separate secret key, and search on that. Without the key an attacker cannot run a dictionary attack against the index; an unsalted plain hash (SHA-256 of an email address) can be reversed by hashing candidate values. Deterministic encryption is another option, but it reveals which records share a value. Keeping a plaintext copy anywhere defeats the purpose.

Key ownership, rotation and HSM choices are covered under data security and IAM (Domain 2 and 4.7); for 4.6 the decision is the layer.

Sandboxing is executing code or opening files in an isolated, restricted environment, with limited access to the file system, network, system calls and other processes, so that their behaviour can be observed or contained without risk to production systems. It differs from controls that judge code without running it (static analysis, code signing, which proves origin and integrity, not safety) and from allowlisting (which decides what may run at all, not how safely).

Two uses appear in cloud architecture:

• Detonation for analysis. Email and file-security services open attachments in a sandbox and watch for malicious behaviour before delivery. Its limit is evasion: malware can detect virtualised hardware or analysis tooling, or simply wait longer than the analysis window, and stay dormant. A clean verdict means nothing malicious was observed, not that the file is safe, so sandboxing is one layer alongside endpoint protection.
• Containment of risky components. When an application must use code with a history of exploitable flaws, such as a third-party parser of complex document formats, running it in a separate sandboxed process with no network access, minimal system calls and only the input it needs limits what an exploit can reach, including flaws nobody knows yet. Signature-based WAF rules and file-type checks only stop exploits someone has already recognised, and a low-privilege account inside the main process still shares that process's memory and data.

Sandboxes are themselves software and can have escape vulnerabilities, so they are kept patched and layered with other controls. Provider-level isolation of tenant runtimes is a Domain 3 topic.

Application virtualization encapsulates an application together with its runtime, libraries and settings into a package that runs isolated from the host operating system and from other applications, without being installed into the OS. It lets a company keep a legacy application that needs an outdated runtime without putting that runtime on every device. It differs from a virtual machine (no guest operating system or hypervisor per application) and from a container (packaged for servers and orchestrators rather than end-user devices, though the idea is similar). Its limit: the package still executes on the host OS, so malware with control of that OS can reach the application's memory and data. It isolates the application from other software, not from a compromised host.

Microservices split an application into small, independently deployed services that communicate over the network. Security-wise, the main change is that calls that used to be function calls inside one process become network API calls between services (east-west traffic), and each of those now needs authentication, authorization and encryption. The external perimeter does not necessarily grow if a gateway fronts the services; the internal attack surface does.

The classic mistake is trusting the internal network: the gateway authenticates users, and the services accept anything that arrives from inside the cluster. An attacker who compromises one low-value service can then call a sensitive one directly. The root-cause fix is zero trust between services: each service verifies the calling service's identity (for example with mutual TLS or workload identity, covered in 4.7) and validates the end user's signed token on every request. Strengthening the edge does not help, because the attacker is already past it.

A container packages an application and its dependencies into an image and runs it as an isolated process on a shared host kernel. Two design principles carry most of the security weight at the application-architecture level.

Runtime privilege. The container daemon's control socket (for Docker, the Unix socket the daemon listens on) accepts commands to start containers with any settings, including privileged mode and host mounts. Anyone who can talk to it can therefore start a container that mounts the host's root file system: socket access is root on the host, whatever user the client runs as inside its own container. Mounting the socket into a CI agent is a common way this happens; safer patterns use rootless or daemonless image builders. A privileged container is likewise close to root on the host, because it receives all Linux capabilities and access to host devices. When a workload needs one specific capability, the least-privilege fix is to drop privileged mode, drop all capabilities and add back only the one required. Other hardening settings are worth having, but none of them removes what privileged mode grants.

Immutable images. Containers are treated as disposable and immutable: you never patch a running container. To fix a vulnerable library, rebuild the image with the fixed version, push it under a new unique tag (or reference it by its content digest) and roll it out through the orchestrator, which replaces the replicas. Any change made inside a running container dies with it, because the image every new replica starts from is unchanged. Reusing a mutable tag for a new build is a trap: nodes that cached the old image keep running it, the deployment record shows the same tag everywhere, and nobody can tell which code is live. A new tag or digest gives an auditable, consistent rollout and a clean rollback path.

Kubernetes is the orchestrator that schedules containers as pods across a cluster, and four of its defaults are the ones most often wrong in a cloud architecture.

API access from pods. By default each pod gets a service account token mounted inside it, which authenticates to the Kubernetes API server. If that account has broad rights (such as listing Secrets cluster-wide), an attacker who exploits the pod inherits them. For workloads that never call the API, disable token auto-mounting (automountServiceAccountToken: false) and grant service accounts only the RBAC permissions they need. The risk is what the token is allowed to do, so the fix is fewer rights or no token, not a different way of handling the same rights.

Secrets at rest. Kubernetes Secrets are base64-encoded, which is an encoding, not encryption. In upstream Kubernetes they are stored unencrypted in etcd unless the cluster operator (or the managed Kubernetes provider, several of which now enable it by default) configures encryption at rest, so anyone with a copy of etcd data or its backups can read them. Encryption at rest is configured with an encryption configuration on the API server. Local providers (such as AES-GCM or AES-CBC) keep the key in that configuration file on each control-plane node, so a copy of the node's disk carries both the encrypted data and the key. The KMS provider uses envelope encryption: data keys are wrapped by a key-encryption key held in an external key management service, so the disk alone does not expose the Secrets. Disk encryption with a key on the same node has the same co-location flaw.

Network policy. Pod networking is open by default: any pod can reach any other pod in any namespace. Namespaces organise and scope permissions but are not network boundaries. A NetworkPolicy that selects pods restricts their ingress and egress; once a pod is selected for a direction, only traffic the policies allow is permitted. A policy that omits policyTypes applies to ingress, and to egress only if it contains egress rules. Two traps: policies are enforced by the cluster's network plugin, and the API server accepts and lists them even when the plugin does not implement them, in which case nothing changes; and egress policies are also the cluster control for keeping pods away from the cloud instance metadata endpoint (169.254.169.254), for example an egress rule allowing 0.0.0.0/0 except that address. RBAC governs API calls, not network connections, so it cannot block that request.

Pod admission. PodSecurityPolicy was removed in Kubernetes v1.25. Its replacement, the built-in Pod Security Admission controller, applies the Pod Security Standards per namespace through labels:

Each level can be applied in three modes: enforce (reject violating pods), audit (record violations in the audit log) and warn (return a warning to the user). The safe rollout on existing namespaces is warn and audit first to find violating workloads, then enforce. Exempting a namespace that runs trusted node agents is usually done by leaving it at the privileged level; the admission configuration can also list static exemptions by namespace, user or runtime class. Network policy and RBAC cannot refuse a pod because of its security settings; that is the admission controller's job.