9. Cloud, Virtualized, Container and API Security

Introduction and Context

Cloud computing has changed the location, ownership, and operational model of information systems. Applications that were once hosted in privately controlled data centres may now run across public clouds, private clouds, multiple providers, edge locations, virtual machines, containers, managed databases, serverless platforms, and external APIs. This flexibility improves scalability and speed, but it also changes the security problem. The organisation no longer protects only a physical network perimeter; it must secure identities, configurations, workloads, software supply chains, data flows, and automated deployment processes.

Cloud-native security is therefore a systems problem. A misconfigured identity policy, exposed storage bucket, vulnerable container image, insecure API, or compromised CI/CD credential may be more damaging than a traditional firewall failure. Security controls must operate continuously and must be expressed in forms that machines can evaluate, such as policy-as-code, infrastructure-as-code checks, admission policies, and automated compliance tests.

This chapter examines security across cloud networks, virtual infrastructure, containers, Kubernetes, service meshes, APIs, and DevSecOps pipelines. It uses the shared-responsibility model as a starting point, but extends it through zero-trust principles, layered workload protection, software supply-chain assurance, and continuous governance.

Learning Objectives

After studying this chapter, students should be able to:

1. Explain the shared-responsibility model and its implications for cloud security.

2. Analyse security risks in virtual machines, containers, Kubernetes clusters, service meshes, and APIs.

3. Design a defensible multi-cloud network and identity architecture.

4. Apply policy-as-code, infrastructure-as-code scanning, and DevSecOps controls.

5. Evaluate cloud-native incidents, governance obligations, and operational trade-offs.

6. Recommend practical controls for confidentiality, integrity, availability, and accountability.

The Cloud Security Responsibility Boundary

The shared-responsibility model divides security obligations between the cloud service provider and the customer. The provider generally protects the physical facilities, hardware, core infrastructure, and foundational services. The customer remains responsible for the security of identities, data, configurations, workloads, applications, and access decisions. The exact boundary depends on the service model.

In infrastructure as a service (IaaS), the customer typically manages operating systems, virtual networks, host-level configuration within the virtual machine, applications, and data. In platform as a service (PaaS), the provider manages more of the operating environment, but the customer still controls identities, application logic, data, and configuration. In software as a service (SaaS), the provider operates most of the platform, yet the customer must still manage users, permissions, data classification, retention, and secure usage.

The model does not mean that responsibility is simply transferred to the provider. A provider may supply secure encryption, logging, and identity features, but the customer must activate and configure them correctly. The most common governance failure is assuming that provider security eliminates customer configuration risk. Security should therefore be documented as a responsibility matrix identifying owners, control objectives, evidence, and escalation paths.

Core Concepts and Terminology

A cloud account, subscription, or project is an administrative boundary containing resources and policies. Regions and availability zones support resilience but may create data-residency and regulatory implications. A virtual private cloud or equivalent logical network provides address spaces, routing, subnets, security groups, network access control lists, gateways, and private service endpoints.

Identity and access management (IAM) controls authentication and authorisation. Least privilege requires that identities receive only the permissions needed for a defined task. Privileges should be granted to roles and short-lived identities rather than embedded in code or shared accounts. Federation allows enterprise identity providers to authenticate users to cloud services, while workload identity allows applications to obtain controlled credentials without storing long-lived secrets.

A security group is generally a stateful virtual firewall associated with an interface or workload. A network access control list is commonly applied at a subnet boundary and may be stateless. These mechanisms are complementary, not interchangeable. Encryption at rest protects stored data, while encryption in transit protects communication channels. Key management includes generation, storage, rotation, access control, separation of duties, and recovery.

Observability combines logs, metrics, traces, configuration records, and security events. Cloud audit logs should record administrative actions, authentication events, policy changes, network flows, and access to sensitive resources. Logs must be protected from alteration and retained according to legal, operational, and investigative requirements.

Securing Cloud Networks and Multi-Cloud Connectivity

Cloud network design should begin with data flows and trust relationships rather than with a list of products. Public-facing services, application tiers, management interfaces, databases, and security tooling should be separated logically. Private subnets, restricted routing, service endpoints, egress controls, and centrally managed inspection can reduce unnecessary exposure.

A common architecture uses a public ingress layer, a private application layer, and a restricted data layer. Administrative access is routed through a controlled bastion, privileged access workstation, or identity-aware proxy rather than exposing management ports to the internet. Security groups should deny unnecessary inbound traffic, and egress should be controlled because compromised workloads often use outbound communication for command and control or data exfiltration.

Multi-cloud connectivity introduces additional complexity. Organisations may connect providers through encrypted site-to-site tunnels, dedicated private links, software-defined wide-area networking, or cloud exchange services. The design must address routing convergence, overlapping address ranges, latency, failure recovery, encryption, identity federation, and consistent policy enforcement. A connection that is private does not automatically become trusted; traffic should still be authenticated, authorised, monitored, and segmented.

Zero trust provides a useful architectural principle. It rejects implicit trust based solely on network location and requires continuous verification of identity, device or workload posture, requested resource, and context. In cloud environments, this often means identity-aware access, mutual TLS, fine-grained authorisation, and explicit service policies rather than broad internal network access.

Virtual Machines and Hypervisor Security

Virtualisation allows multiple guest operating systems to share physical resources through a hypervisor. It improves utilisation and isolation, but introduces risks involving hypervisor vulnerabilities, management-plane compromise, insecure images, snapshot exposure, and excessive privileges.

A secure virtual-machine lifecycle includes approved image creation, vulnerability scanning, cryptographic signing or provenance verification, secure configuration, patching, runtime monitoring, backup protection, and controlled retirement. Golden images should be minimal and reproducible. Unused services, default accounts, compilers, and management agents should be removed where feasible.

Snapshots and machine images often contain sensitive data, credentials, and memory remnants. They require access control, encryption, retention limits, and secure deletion. Administrative interfaces should be isolated from ordinary workloads and protected by strong authentication and detailed audit logging. Virtual machine escape is uncommon but high impact; timely hypervisor patching, workload isolation, and provider security updates remain essential.

Containers: Images, Runtimes and Supply Chains

Containers package an application and its dependencies while sharing the host operating-system kernel. They are not equivalent to virtual machines: the shared kernel means that a runtime or kernel compromise may affect multiple containers. Containers are also frequently short-lived, making traditional host-centred security insufficient.

Container security begins during image construction. Images should use trusted minimal base images, pinned dependency versions, multi-stage builds, non-root users, read-only filesystems where practical, and removal of secrets from build layers. Image scanners can identify known vulnerabilities, but scanning alone cannot establish that an image is trustworthy. Organisations should also verify provenance, generate software bills of materials (SBOMs), sign images, and restrict deployment to approved registries.

At runtime, the container should receive only necessary Linux capabilities, system calls, filesystem access, network permissions, and resources. Privileged containers, host-network access, host filesystem mounts, and unrestricted metadata-service access deserve special scrutiny. Resource limits reduce denial-of-service risk, while runtime detection can identify unexpected processes, privilege changes, or network connections.

The software supply chain extends from source code and dependencies to build runners, registries, deployment controllers, and production workloads. A compromised dependency or build credential can therefore bypass perimeter controls. Provenance, reproducible builds, protected branches, dependency pinning, secret isolation, and separation between development and production credentials reduce this risk.

Kubernetes Security and Service Meshes

Kubernetes provides a control plane for scheduling and managing containers. Its security model includes the API server, authentication, authorisation, admission control, etcd, nodes, pods, services, and network policies. The control plane is especially sensitive because an attacker who gains administrative Kubernetes permissions may control many workloads.

Kubernetes API access should use strong identity federation, short-lived credentials, role-based access control (RBAC), and narrowly scoped service accounts. Cluster-admin privileges should be exceptional. Secrets stored in the cluster require encryption and strict access policies; external secret managers may reduce exposure. The etcd datastore must be protected because it can contain configuration and secret material.

Admission controllers and policy engines can enforce rules before workloads run. Examples include rejecting privileged containers, requiring signed images, preventing host-path mounts, enforcing resource limits, and requiring approved security contexts. Network policies should implement default-deny segmentation and explicitly permit necessary pod-to-pod communication. Namespace boundaries are useful but should not be treated as complete isolation.

A service mesh inserts proxies or sidecars, or uses an equivalent data-plane mechanism, to provide service-to-service encryption, identity, traffic policy, observability, retries, and controlled routing. Mutual TLS can authenticate workloads, but it does not by itself authorise business actions. Mesh policies must be paired with application-level authorisation and careful protection of the mesh control plane. Additional proxies also introduce operational complexity, latency, certificate-management requirements, and new failure modes.

API Security as an Application and Identity Problem

APIs expose business capabilities, not merely network ports. Their security must therefore protect identity, object ownership, business rules, data minimisation, and availability. Common weaknesses include broken object-level authorisation, excessive data exposure, weak authentication, unrestricted resource consumption, insecure defaults, and inadequate monitoring.

API security should begin with an explicit contract using standards such as OpenAPI where appropriate. Authentication may use mutual TLS, OAuth 2.0, OpenID Connect, signed tokens, or other approved mechanisms. Authentication proves who or what is calling; authorisation determines whether the caller may perform the requested operation on the specific object. This distinction is critical. A valid token should not automatically grant access to every record.

API gateways can provide routing, rate limiting, schema validation, threat detection, authentication integration, and centralised logging. They are not substitutes for secure application logic. Input validation must be context-sensitive, output should be limited to necessary fields, and errors should avoid revealing internal details. Idempotency controls are important for financial or state-changing operations. Rate limits and quotas should reflect business sensitivity and user identity rather than relying only on IP addresses.

API keys should not be treated as complete user authentication when stronger identity is required. Tokens need appropriate expiry, audience validation, issuer validation, secure storage, and revocation or rotation procedures. Webhooks require signature verification, replay protection, source validation, and controlled retry behaviour. APIs handling personal, financial, or health information require stronger privacy, logging, retention, and consent controls.

DevSecOps and Policy-as-Code

DevSecOps integrates security into planning, coding, building, deploying, and operating rather than placing all testing at the end. A mature pipeline may include secret detection, software composition analysis, static application security testing, infrastructure-as-code scanning, container scanning, dynamic testing, license checks, SBOM generation, signing, and deployment verification.

Infrastructure-as-code makes cloud configuration reviewable and repeatable, but it can also reproduce insecure designs rapidly. Policy-as-code expresses requirements in machine-evaluable form, such as “storage containing regulated data must be encrypted,” “public administration ports are prohibited,” or “production images must be signed.” Policies should be version-controlled, tested, documented, and linked to risk exceptions with owners and expiry dates.

Pipeline security requires protected source repositories, branch controls, isolated build agents, minimal CI/CD permissions, secret managers, dependency integrity checks, and tamper-evident logs. Deployment credentials should be short-lived and environment-specific. Progressive delivery, automated rollback, and runtime health checks reduce the impact of faulty or malicious releases.

Automation must not create an illusion of security. A scanner may report a vulnerability without understanding exploitability, or may miss a business-logic flaw. Human review remains necessary for architectural decisions, exceptions, threat modelling, and high-risk changes. Effective DevSecOps combines automation with accountable engineering and security ownership.

Illustrative Case Study: A Multi-Cloud Retail Platform

Background

A fictional retailer, Northstar Market, operates an online store in one public cloud and its analytics platform in a second provider. Customer, payment, inventory, and marketing systems communicate through APIs. Containerised applications run on Kubernetes, while a legacy order service remains on virtual machines.

Situation and Problem

An external assessment identifies three weaknesses: a Kubernetes service account has excessive permissions, a storage repository is publicly readable, and an API permits authenticated users to retrieve another customer’s order by changing an order identifier. The company also lacks a consistent process for approving cloud network changes.

Analysis

The weaknesses arise from different layers but share governance causes. The storage exposure is a configuration and data-protection failure. The service-account issue is an identity and workload-authorisation failure. The order vulnerability is broken object-level authorisation in application logic. Multi-cloud connectivity has encouraged broad network trust, while pipeline checks focus on package vulnerabilities rather than permissions and business rules.

Strategy and Solution

Northstar first classifies data and establishes a responsibility matrix. It removes public access, encrypts the repository with centrally managed keys, and adds continuous configuration monitoring. Kubernetes RBAC is redesigned around namespace-specific service accounts, default-deny network policies, signed images, and admission rules rejecting privileged workloads. The API is changed to authorise every order against the authenticated customer identity; tests are added for horizontal privilege escalation.

The company adopts identity federation for human access and workload identity for applications. Cloud network routes are documented as code, and policy checks block public storage, unrestricted administrative ports, and unapproved regions. CI/CD credentials are replaced with short-lived identities. Central logging records cloud administration, Kubernetes API activity, API access decisions, and key events. A threat-model review is required for high-risk interfaces.

Outcome

The retailer reduces unnecessary permissions and exposure while improving evidence for audits. Development teams initially report slower deployment because policies reject previously tolerated configurations. After reusable secure templates and clearer exception procedures are introduced, deployment speed improves without restoring broad privileges.

Learning Points

The case demonstrates that cloud security is not solved by a single product. Network controls, IAM, application authorisation, supply-chain assurance, policy automation, and governance must work together. It also shows why authenticated access is not equivalent to authorised access and why policy exceptions require ownership and expiry.

Challenges, Limitations and Common Mistakes

Cloud environments create scale, complexity, and rapid change. Asset inventories may become inaccurate as teams create temporary resources. Provider interfaces differ, making consistent multi-cloud policy difficult. Managed services reduce operational burden but may obscure underlying dependencies and create concentration risk. Centralised security can improve consistency but may become a bottleneck or fail to understand local application context.

Frequent mistakes include using permanent administrator credentials, exposing management interfaces, trusting internal networks, storing secrets in images or repositories, granting cluster-admin privileges for convenience, ignoring egress, relying only on vulnerability scores, failing to test recovery, and treating compliance reports as evidence of actual security. Excessive monitoring can also create privacy risks and operational noise.

Controls must be proportionate. Aggressive blocking can encourage teams to bypass security, whereas permissive policies increase exposure. Mature programmes define risk-based service tiers, standard secure patterns, monitored exceptions, and measurable recovery objectives.

Governance, Ethics and Professional Responsibilities

Cloud security decisions affect privacy, employment, safety, and access to essential services. Data location, cross-border transfers, retention, lawful access, and subcontractor arrangements must be assessed against applicable legal and contractual obligations. Logging should be sufficient for accountability without collecting unnecessary personal information.

Security professionals must communicate residual risk honestly. A passed scan does not prove that an API is authorised correctly, and provider certification does not prove that a customer configuration is secure. Access to production data should be justified, logged, reviewed, and limited. Responsible disclosure, protection of test data, separation of duties, and non-retaliation for reporting vulnerabilities support ethical practice.

Current Developments and Emerging Directions

Cloud security is increasingly adopting confidential computing, hardware-backed key protection, workload identity, software supply-chain attestations, and eBPF-based runtime visibility. Security data lakes and analytics platforms correlate identity, configuration, network, and workload events. Machine learning may assist anomaly detection and alert prioritisation, but models can produce false positives, inherit biased training data, or be manipulated by adversarial behaviour.

Platform engineering is producing reusable internal platforms with secure defaults, while continuous authorisation evaluates context beyond initial login. Software bills of materials and provenance requirements are becoming more important as organisations seek evidence about dependencies and build processes. Serverless and edge computing introduce additional event, identity, observability, and jurisdictional considerations. These developments do not remove foundational obligations: least privilege, secure design, verification, resilience, and accountable governance.

Best-Practice Design Principles

A practical cloud-native security programme should:

• establish a responsibility matrix and classify data;
• use federated human identity and short-lived workload credentials;
• segment networks and services with explicit default-deny policies;
• secure images, dependencies, build systems, and deployment identities;
• enforce cloud and Kubernetes requirements through tested policy-as-code;
• validate object-level API authorisation and business logic;
• centralise, protect, and review security telemetry;
• test backups, incident response, rollback, and disaster recovery;
• monitor drift and continuously remove unused privileges;
• document risk exceptions with accountable owners and expiry dates.

Chapter Summary

Cloud-native security extends beyond the provider’s infrastructure. The customer must secure identities, data, configurations, applications, workloads, and operational processes within the shared-responsibility boundary. Secure cloud networks use segmentation, controlled routing, private access, egress governance, and zero-trust verification. Virtual machines require hardened images, protected management planes, and secure snapshots. Containers and Kubernetes require trusted images, least privilege, admission controls, RBAC, network policies, secret protection, and runtime monitoring. Service meshes can provide workload identity and mutual TLS but do not replace application authorisation.

API security depends on authentication, object-level authorisation, data minimisation, validation, rate control, and secure business logic. DevSecOps embeds testing and policy-as-code throughout the software lifecycle, while supply-chain controls establish provenance and protect build systems. Effective security combines automation with human judgement, governance, incident readiness, privacy protection, and continuous improvement.

Key Terms

Shared responsibility model: Allocation of security duties between a cloud provider and its customer.

IAM: Controls governing identities, authentication, permissions, and authorisation.

Workload identity: A mechanism allowing an application or service to obtain controlled identity credentials.

Zero trust: A security approach requiring explicit, continuous verification rather than implicit network trust.

Security group: A virtual, commonly stateful firewall controlling traffic to a workload interface.

Virtual machine: A software-defined computer running a guest operating system on virtualised hardware.

Container: An isolated application process sharing the host operating-system kernel.

Container image: A packaged filesystem and metadata used to create a container.

SBOM: A machine-readable inventory of software components and dependencies.

Kubernetes: A platform for orchestrating and managing containerised workloads.

RBAC: Role-based access control that assigns permissions through defined roles.

Admission control: Policy enforcement that evaluates workloads before they enter a cluster.

Service mesh: An infrastructure layer providing service communication security and observability.

Mutual TLS: A protocol arrangement in which both communicating parties authenticate certificates.

API gateway: A controlled entry point providing API routing, security, and traffic-management functions.

Policy-as-code: Security or governance rules expressed in machine-evaluable, version-controlled form.

DevSecOps: Integration of security activities throughout software development and operations.

Infrastructure-as-code: Declarative or programmatic management of infrastructure configuration.

Software supply chain: The people, processes, tools, dependencies, and systems producing software.

Egress control: Restriction and monitoring of outbound network communication.

Review Questions

Short Answer Questions

1. What does the shared-responsibility model require a cloud customer to manage?

2. Why are containers not equivalent to virtual machines from a security perspective?

3. What is the difference between authentication and object-level authorisation in an API?

4. State two purposes of Kubernetes admission control.

5. What is policy-as-code?

Long Answer Questions

1. Explain how a multi-cloud network can be designed using segmentation, identity-aware access, encryption, and egress control.

2. Discuss the security lifecycle of a container image from development through production deployment.

3. Analyse the major security components of a Kubernetes cluster.

4. Explain how DevSecOps and software supply-chain controls reduce cloud application risk.

5. Compare the security responsibilities associated with IaaS, PaaS, and SaaS.

Analytical / Application Questions

1. An API accepts valid OAuth tokens but allows a customer to view another customer’s invoice by changing an identifier. Identify the weakness and propose layered controls.

2. A Kubernetes workload needs to access one object-storage bucket, but its service account has cluster-admin privileges. Design a least-privilege remediation plan.

3. A company connects two cloud providers through a private link and assumes all connected traffic is trusted. Critically evaluate this assumption and recommend a safer architecture.

22. Multiple Choice Questions with Answers

Question 1

A cloud customer running an IaaS virtual machine is primarily responsible for which activity?

A. Securing the provider’s physical data centre

B. Patching and hardening the guest operating system

C. Replacing the provider’s hypervisor

D. Controlling the provider’s facility access system

Correct Answer: B. Patching and hardening the guest operating system

Question 2

Which control most directly limits a compromised workload’s outbound command-and-control communication?

A. Egress filtering

B. Increasing image size

C. Disabling API documentation

D. Adding more availability zones

Correct Answer: A. Egress filtering

Question 3

Why should a container image be signed and accompanied by provenance information?

A. To guarantee that it contains no vulnerabilities

B. To prove its origin and support deployment trust decisions

C. To eliminate the need for runtime controls

D. To make the container function as a virtual machine

Correct Answer: B. To prove its origin and support deployment trust decisions

Question 4

Which Kubernetes control can reject a privileged container before it is deployed?

A. Admission policy

B. A customer-facing API gateway

C. A database index

D. A DNS record

Correct Answer: A. Admission policy

Question 5

Mutual TLS in a service mesh primarily provides which capability?

A. Business approval of every transaction

B. Workload authentication and encrypted service communication

C. Automatic removal of vulnerable dependencies

D. Physical isolation of cloud regions

Correct Answer: B. Workload authentication and encrypted service communication

Question 6

An API verifies that a user is authenticated but does not check whether the requested order belongs to that user. This is an example of:

A. Broken object-level authorisation

B. Hypervisor escape

C. Image provenance failure

D. Insufficient network redundancy

Correct Answer: A. Broken object-level authorisation

Question 7

Which practice best protects CI/CD deployment credentials?

A. Embedding permanent administrator keys in source code

B. Sharing one credential across all environments

C. Using short-lived, environment-specific identities

D. Printing credentials in build logs

Correct Answer: C. Using short-lived, environment-specific identities

Question 8

What is a principal benefit of policy-as-code?

A. It replaces all security judgement with automation

B. It makes security requirements consistently testable and enforceable

C. It prevents the need for cloud inventories

D. It guarantees that applications contain no logic flaws

Correct Answer: B. It makes security requirements consistently testable and enforceable

Question 9

A private connection between two cloud providers should still use explicit authorisation because:

A. Private connectivity automatically disables encryption

B. Network privacy does not establish that every workload or request is trustworthy

C. Cloud providers cannot route private traffic

D. Authorisation is only required for public websites

Correct Answer: B. Network privacy does not establish that every workload or request is trustworthy

Question 10

Which combination best addresses a sensitive Kubernetes workload?

A. Cluster-admin permissions, public API access, and unrestricted host mounts

B. Least-privilege RBAC, signed images, admission controls, and network policies

C. A larger container image and shared credentials

D. Disabling audit logs to improve performance

Correct Answer: B. Least-privilege RBAC, signed images, admission controls, and network policies