Workload, Application, API and Container Security

Introduction

Cloud security is not achieved by protecting only the physical data centre or the cloud provider’s network. Modern workloads are assembled from virtual machines, managed services, application code, APIs, containers, Kubernetes resources and serverless functions. Each layer has different failure modes and different security responsibilities.

A cloud provider normally secures the infrastructure it operates, while the customer remains responsible for configuring services, protecting identities and data, securing workloads, and maintaining application security. The exact boundary depends on the service model. In infrastructure as a service (IaaS), the customer commonly manages the guest operating system, applications and security configuration. In platform as a service (PaaS), the provider manages more of the operating environment, but the customer still secures code, identities, data and configurations. In serverless computing, the provider manages servers and much of the runtime, but the customer remains responsible for function code, permissions, dependencies, event validation and data protection.

This chapter develops practical foundations for protecting cloud workloads and interfaces. It covers virtual-machine hardening, application security, API protection, container security, Kubernetes controls and serverless security. It also explains isolation, runtime monitoring, supply-chain risks, governance and the limits of shared responsibility.

Learning Objectives

By the end of this chapter, you should be able to:

1. Explain the shared-responsibility boundary for IaaS, PaaS, containers and serverless services.
2. Apply basic hardening principles to virtual machines and cloud-native applications.
3. Describe how secure API design, authentication, authorization and validation reduce risk.
4. Identify security risks in container images, registries, orchestration platforms and runtime environments.
5. Explain Kubernetes security controls, including namespaces, service accounts, network policies and admission controls.
6. Distinguish isolation, least privilege, defence in depth and secure-by-design practices.
7. Recommend practical controls for a cloud workload and evaluate their limitations.

1. Workload Security and Responsibility Boundaries

A workload is the set of computing resources, software, identities, data and network connections required to deliver a business function. For example, an online store may include a web front end, application services, a database, object storage, queues, monitoring agents and deployment pipelines.

Security responsibility is distributed across several layers:

The boundary is not a transfer of accountability. A managed database may remove the need to patch a database server, but it does not automatically prevent excessive privileges, insecure queries, exposed credentials or inappropriate data retention.

A useful security model is defence in depth. Controls should operate at multiple layers so that failure of one control does not expose the entire workload. For example, an application may use identity authentication, authorization checks, input validation, network restrictions, encrypted transport, logging and runtime detection. These controls are complementary rather than interchangeable.

Isolation

Isolation limits the effect of a compromise. Common forms include:

• Process isolation: separating processes through operating-system permissions and namespaces.
• Virtual-machine isolation: using a hypervisor to separate guest operating systems.
• Container isolation: restricting processes through namespaces, control groups and security policies.
• Network isolation: separating workloads with virtual networks, subnets, routing rules or network policies.
• Identity isolation: assigning distinct users, roles and service accounts.
• Data isolation: separating tenants, records, encryption keys or storage locations.

Isolation is not absolute. A container shares the host kernel, and a virtual machine depends on the hypervisor. Misconfigured network routes, excessive permissions or vulnerable management interfaces can undermine otherwise strong technical isolation.

2. Virtual-Machine Security

Virtual machines remain important for legacy applications, specialised operating systems and workloads requiring strong operating-system separation. Their security begins before deployment.

Secure build and hardening

A hardened virtual machine should be created from an approved, minimal image. Hardening commonly includes:

• removing unnecessary packages, services and users;
• changing or disabling default credentials;
• enforcing strong authentication and, where possible, multi-factor authentication for administration;
• disabling direct privileged login and using controlled elevation mechanisms;
• applying security updates through a tested patch process;
• configuring host-based firewalls with a default-deny approach where practical;
• restricting management ports to approved administrative networks;
• enabling time synchronisation, logging and integrity monitoring;
• encrypting attached disks and protecting encryption keys;
• preventing sensitive information from being written to images or startup scripts.

A golden image should be versioned, tested and rebuilt regularly rather than modified indefinitely. Immutable or replacement-based deployment reduces configuration drift: when a new image is approved, instances are replaced instead of receiving unpredictable manual changes.

Administrative access

Administrative access should use short-lived, auditable mechanisms. Secure patterns include a managed session service, a bastion host with strong controls, or a private management network. Publicly exposing SSH or remote desktop services increases attack surface and should be avoided unless there is a compelling, controlled reason.

Access should be based on named identities rather than shared accounts. Commands, sessions and privilege changes should be logged. Emergency access should be separately governed, time-limited and reviewed after use.

Patch and vulnerability management

Patch management is a risk-based process rather than a simple calendar activity. Teams should identify affected assets, determine exploitability and business criticality, test updates, deploy them within defined service objectives, and verify completion. Vulnerability scanners are useful but imperfect: they may produce false positives, miss application flaws or fail to identify compensating controls.

A basic prioritisation model considers exposure, exploit availability, asset importance, data sensitivity and the existence of mitigations. A critical vulnerability on an isolated test machine may require less immediate action than a high-severity vulnerability on an internet-facing payment service.

3. Application Security in the Cloud

Cloud applications are often distributed, continuously deployed and dependent on third-party services. Security must therefore be integrated into the software development life cycle rather than added after deployment.

Secure design principles

Important principles include:

• Least privilege: each component receives only the permissions it needs.
• Secure defaults: a new deployment should not expose data or administrative functions by default.
• Fail securely: errors should deny unsafe operations without revealing secrets or internal details.
• Complete mediation: authorization should be checked at every relevant request, not only at the user interface.
• Separation of duties: development, approval, deployment and production administration should not be concentrated in one uncontrolled identity.
• Minimise trust: components should authenticate and authorize one another rather than assuming that an internal network is trustworthy.

Identity and authorization

Authentication establishes who or what is making a request. Authorization determines what that identity may do. These are different decisions. A valid token proves little if its holder can access every customer record.

Authorization should consider the resource, action, tenant or owner, context and risk. Role-based access control assigns permissions to roles, while attribute-based access control evaluates attributes such as department, resource classification, environment and time. In either model, decisions should be enforced on the server side.

Service-to-service access should use workload identities or short-lived credentials rather than embedded passwords. Permissions should be scoped to specific resources and actions. Unused roles, tokens and integration accounts should be removed.

Input, output and error handling

All external input should be treated as untrusted, including data received from supposedly internal services. Validation should check type, length, format, range and business rules. Parameterized queries reduce injection risk; output encoding reduces cross-site scripting risk; request-size limits reduce resource-exhaustion attacks.

Errors should provide useful information to operators without exposing stack traces, credentials, database details or internal network structure to users. Logs should record security-relevant events but should not contain passwords, access tokens or unnecessary personal data.

Configuration and secrets

Configuration errors are a major source of cloud incidents. Examples include public storage, permissive security groups, unrestricted administrative endpoints and disabled logging. Configuration should be managed as code, reviewed, tested and continuously assessed against approved baselines.

Secrets should be stored in a dedicated secrets-management service or an equivalent protected mechanism. They should not be placed in source code, container images, public build logs or unencrypted environment files. Rotation must be technically possible and operationally tested.

4. API Security

An API is a contract through which software requests data or actions. Its security includes the interface, the implementation, the identity model, the data returned and the surrounding operational controls.

Main API threats

Common threats include:

• broken object-level authorization, where a user changes an identifier and obtains another user’s record;
• broken function-level authorization, where an ordinary user invokes an administrative operation;
• excessive data exposure, where responses contain more data than the client needs;
• mass assignment, where clients modify protected fields by submitting unexpected properties;
• replay or stolen-token attacks;
• injection and malformed input;
• denial of service through excessive requests or expensive operations;
• insecure third-party integrations and webhooks;
• undocumented or obsolete API versions.

API control pattern

A secure API should use a documented contract, strong transport encryption, explicit authentication and server-side authorization. Requests should be validated against an allow-list schema. Responses should be limited to necessary fields. Rate limits and quotas should reflect business needs and prevent abuse without blocking legitimate use.

API gateways can centralise routing, authentication integration, throttling, request-size limits, logging and threat detection. They do not replace authorization inside the application. A gateway may know that a token is valid, while only the application knows whether the user may access a particular invoice.

Tokens should have appropriate audience, issuer, expiry and scope checks. Long-lived tokens increase exposure if stolen. Refresh-token handling, revocation procedures and key rotation require explicit design.

Webhooks require authentication and integrity protection. Receivers should verify signatures, timestamps and event identifiers, and should process events idempotently where possible. Idempotency means that repeating the same legitimate request does not create an unintended duplicate effect.

5. Container Security

Containers package an application and its dependencies into a portable image. They usually share the host kernel, making them lighter than virtual machines but potentially more dependent on host and runtime security.

Image and supply-chain security

A container image should be built from a trusted, minimal base image. The build process should:

1. obtain source code and dependencies from approved repositories;
2. pin or otherwise control dependency versions;
3. scan source, dependencies and the resulting image;
4. remove build tools, package caches and unnecessary files from the runtime image;
5. run the service as a non-root user;
6. generate provenance and, where supported, sign the image;
7. store the image in a protected private registry;
8. verify the image before deployment.

Scanning identifies known vulnerabilities, but a clean scan does not prove that an image is safe. Vulnerability databases may be incomplete, vulnerabilities may be unreachable in the deployed configuration, and malicious code may be intentionally inserted. Build provenance, code review, dependency governance and runtime controls remain necessary.

Runtime controls

Container runtimes should restrict capabilities, use read-only filesystems where practical, prevent privilege escalation and apply resource limits. Sensitive host paths should not be mounted into containers without strong justification. The container should not run with host networking or host privileges unless the operational need is documented and risk accepted.

Resource limits help contain denial-of-service effects. They are not a substitute for application-level controls: a process may still consume all permitted resources or generate expensive downstream requests.

6. Kubernetes Security

Kubernetes orchestrates containers through an API server and a collection of control-plane and worker components. Its flexibility creates a substantial security configuration surface.

Control-plane and cluster access

The Kubernetes API server is a high-value target. Access should use strong identity, narrowly scoped roles and auditable requests. Role-Based Access Control (RBAC) should follow least privilege. Cluster-wide permissions should be exceptional; workloads normally need namespace-scoped permissions.

Service accounts represent workloads. They should be distinct for different applications, and automatic mounting of tokens should be disabled when a workload does not need Kubernetes API access. A compromise of one service account should not provide control of the cluster.

Namespaces provide administrative and organisational separation, but they are not equivalent to hard security boundaries in every threat model. Sensitive workloads may require separate clusters, nodes, accounts, networks or stronger isolation technologies.

Network and admission controls

Network policies can restrict which pods may communicate. A practical approach is to begin with explicit allowed flows and progressively move toward default-deny ingress and egress, while preserving required DNS, monitoring and service traffic.

Admission controls can reject unsafe workloads before they run. Policies may require approved registries, non-root execution, resource limits, signed images, disallowed capabilities and valid security contexts. Policy enforcement should be tested carefully because an incorrectly designed policy can interrupt production services.

Secrets stored as Kubernetes objects require additional protection. Access should be restricted, encryption at rest should be enabled where supported, and external secrets systems may be preferable for highly sensitive credentials. Secrets should not be placed in images or committed to manifests.

Kubernetes observability and response

Security monitoring should include API audit logs, workload events, image changes, authentication activity, network behaviour and host-level signals. Detection should be connected to response procedures: isolate a workload, revoke credentials, preserve evidence, rebuild from a trusted image and investigate lateral movement.

7. Serverless Workload Security

Serverless functions reduce infrastructure administration but do not eliminate application risk. The function executes in response to an event such as an HTTP request, queue message, object upload or scheduled trigger.

Security priorities include:

• restricting the function execution role;
• validating event structure and source;
• limiting function time, memory and concurrency appropriately;
• controlling outbound network access;
• protecting environment variables and secrets;
• securing dependencies and deployment packages;
• preventing injection through event data;
• controlling invocation permissions;
• monitoring unusual invocation rates, errors and data access.

Event-driven systems create trust relationships that may be overlooked. For example, allowing an object-storage event to invoke a function does not prove that the event contains safe content. The function should validate the event, verify expected bucket or account identifiers, and treat object content as untrusted input.

Concurrency controls can reduce cost and resource exhaustion, but overly restrictive limits may cause legitimate queue backlogs. Serverless security therefore requires coordination among identity, application, event, data and operational controls.

8. Runtime Protection and Detection

Preventive controls cannot guarantee that a workload will not be compromised. Runtime protection detects and limits activity after deployment. Useful signals include unexpected child processes, privilege changes, unusual network destinations, anomalous API calls, secret access, modifications to protected files and sudden changes in request patterns.

A security operations process should define:

1. what events are collected;
2. how events are normalised and correlated;
3. which conditions generate alerts;
4. who investigates and within what time;
5. how workloads are contained;
6. how recovery and lessons learned are performed.

Detection must balance coverage and noise. An alert that is always ignored has little protective value. Baselines should reflect legitimate workload behaviour, while high-risk actions such as privilege escalation and public exposure should receive particular attention.

9. Applied Case: Illustrative Online Learning Platform

Background

An illustrative online learning company operates a web application on a public cloud. Its architecture includes a managed Kubernetes cluster, an API gateway, serverless functions for document processing, object storage for assignments and a managed relational database.

Problem

A security review identifies four weaknesses: a container runs as root, the API allows users to retrieve records by changing an identifier, a Kubernetes service account has cluster-wide read permissions, and an object-upload function trusts event data without validation. Logging is inconsistent, and an image contains an old vulnerable library.

Analysis

The weaknesses are related. The image vulnerability could provide initial access. Root execution could increase the impact of a container compromise. Excessive service-account permissions could permit discovery of cluster resources. The API flaw could expose student records even without infrastructure compromise. The upload function could process malicious content or an event from an unexpected source.

Approach and solution

The company takes the following actions:

• rebuilds the image from a minimal approved base and updates the vulnerable library;
• runs the application as a non-root user, drops unnecessary Linux capabilities and applies a read-only root filesystem;
• signs the image and configures admission policy to allow only approved images;
• replaces the cluster-wide service account with a namespace-scoped role containing only required actions;
• changes the API to enforce object ownership and field-level response filtering;
• adds schema validation, request limits, rate limits and audit logging;
• verifies the source and structure of storage events before processing uploads;
• stores secrets in a managed secrets service and rotates affected credentials;
• enables Kubernetes audit logs, API gateway logs and centralised alerting;
• tests incident procedures through a controlled exercise.

Outcome

The controls reduce the probability of exploitation and limit blast radius if one component is compromised. They do not make the system risk-free. Dependency vulnerabilities can reappear, authorization logic must remain correct as features change, and monitoring requires continuing tuning.

Learning points

The case demonstrates that workload security is a system property. Image scanning alone would not have fixed the authorization flaw; API authentication alone would not have corrected excessive Kubernetes permissions. Effective protection combines secure design, least privilege, isolation, supply-chain controls, runtime monitoring and tested response.

10. Governance, Ethics and Contemporary Developments

Security decisions affect privacy, access to education, employment, health and financial opportunity. Teams should collect and retain only necessary data, restrict access to legitimate purposes and document how automated decisions use personal information. Monitoring should be proportionate, transparent to authorised stakeholders and governed by applicable law and organisational policy.

Regulatory obligations vary by jurisdiction and sector, but common expectations include protection of personal data, appropriate access control, breach response, auditability, retention management and supplier oversight. Compliance does not equal security. A control may satisfy a checklist while failing to address the actual threat model.

Contemporary practice increasingly includes software bills of materials, signed artifacts, build provenance, policy as code, confidential computing, workload identity federation and automated cloud security posture management. Artificial intelligence can help classify alerts, identify configuration anomalies and assist code review, but generated recommendations require human validation. AI systems may also introduce prompt injection, data leakage, insecure generated code and unclear accountability. They should be treated as software components requiring the same identity, data and supply-chain controls as other systems.

Best-Practice Checklist

Before production deployment, a team should be able to answer yes to most of the following questions:

• Is the workload owner identified and is the responsibility boundary documented?
• Is the image or virtual-machine baseline approved, minimal and patched?
• Are identities unique, short-lived where possible and least privileged?
• Are secrets outside source code, images and logs?
• Are APIs authenticated, authorized, validated, rate-limited and documented?
• Are network paths explicit and unnecessary public endpoints removed?
• Are containers non-root, capability-restricted and resource-limited?
• Are Kubernetes permissions namespace-scoped unless a wider scope is justified?
• Are images scanned, traceable and verified before deployment?
• Are logs sufficient for detection, investigation and regulatory needs?
• Are backup, recovery and incident-response procedures tested?
• Are privacy, retention, supplier and legal requirements addressed?

Chapter Summary

Cloud workload security protects more than servers. It addresses virtual machines, application code, APIs, container images, orchestration platforms, serverless functions, identities, data and operational processes. Shared responsibility defines who operates each layer, but the customer remains accountable for secure configuration and use of cloud services.

Virtual-machine security depends on hardened images, patching, restricted administration, encryption, logging and reduced configuration drift. Application security requires secure design, server-side authorization, input validation, protected secrets and controlled deployment. API security depends on explicit object and function authorization, schema validation, limited responses, transport protection, rate controls and careful token handling.

Containers introduce image, dependency, registry and runtime risks. Kubernetes requires protection of the API server, least-privilege RBAC, service-account control, network policies, admission policies, secret protection and audit monitoring. Serverless services reduce infrastructure management but still require secure code, event validation, restricted execution roles, dependency governance and runtime monitoring.

The central professional lesson is that no individual control is sufficient. Effective security combines defence in depth, isolation, least privilege, supply-chain assurance, continuous monitoring and tested response. Governance and ethical data handling ensure that technical protection serves legitimate organisational and social purposes.

Key Terms

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

Workload: The resources, software, identities, data and connections delivering a business function.

Hardening: Reducing a system’s attack surface through secure configuration and removal of unnecessary features.

Configuration drift: Gradual divergence of a deployed system from its approved baseline.

Least privilege: Granting only the permissions required for an identity or process to perform its task.

Isolation: Separating components so that compromise or failure has limited scope.

Golden image: An approved, tested baseline image used to create virtual machines or workloads.

API: An interface through which software requests data or actions.

Authentication: Establishing the identity of a user, service or device.

Authorization: Determining which actions an authenticated identity may perform.

Object-level authorization: Checking whether an identity may access a particular resource instance.

Rate limiting: Restricting request frequency or volume to protect availability and reduce abuse.

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

Container registry: A repository that stores and distributes container images.

Kubernetes: A platform for orchestrating containerised workloads.

RBAC: Role-Based Access Control, in which permissions are assigned through roles.

Namespace: A Kubernetes logical boundary for organising and scoping resources.

Admission control: Policy enforcement that evaluates Kubernetes requests before acceptance.

Serverless function: Event-driven code executed on provider-managed infrastructure.

Runtime protection: Controls that detect or restrict behaviour while a workload is executing.

Review Questions

Short Answer Questions

1. What does shared responsibility mean in cloud security?
2. Why should administrative access to virtual machines use named identities?
3. Distinguish authentication from authorization.
4. Why is running a container as root risky?
5. What is the purpose of a Kubernetes namespace?

Long Answer Questions

1. Explain a defence-in-depth strategy for a cloud-hosted application.
2. Describe the principal stages in a secure container-image supply chain.
3. Explain how an API gateway contributes to security and why it cannot replace application authorization.
4. Discuss the major security responsibilities of a serverless application owner.
5. Compare virtual-machine isolation with container isolation, including their practical limitations.

Analytical / Application Questions

1. A company discovers that an API user can change an invoice identifier and retrieve another customer’s invoice. Identify the vulnerability and propose layered corrective controls.
2. A Kubernetes workload requires access to one object-storage bucket but has permissions to administer the entire cloud account. Analyse the risks and design a least-privilege replacement.
3. Design a security plan for a public web service composed of containers, APIs, a managed database and a serverless image-processing function. Explain how your controls address prevention, isolation, detection and recovery.

Multiple Choice Questions with Answers

Question 1

Which statement best describes shared responsibility in cloud security?

A. The provider is always responsible for application code and customer data.

B. The customer is responsible for every physical security control.

C. Security duties vary by service model, while the customer remains responsible for secure use and configuration of its services.

D. No party is responsible for vulnerabilities in managed services.

Correct Answer: C. Security duties vary by service model, while the customer remains responsible for secure use and configuration of its services.

Question 2

Which control most directly reduces the risk of a compromised application accessing unrelated cloud resources?

A. Least-privilege workload identity

B. Increasing network bandwidth

C. Using a larger virtual machine

D. Disabling application logs

Correct Answer: A. Least-privilege workload identity

Question 3

A user changes an object identifier in an API request and receives another user’s record. What is the primary flaw?

A. Broken object-level authorization

B. Insufficient disk encryption

C. Container image bloat

D. DNS cache poisoning

Correct Answer: A. Broken object-level authorization

Question 4

Why should a production container normally run as a non-root user?

A. It guarantees that the image has no vulnerabilities.

B. It limits the privileges available if the application is compromised.

C. It eliminates the need for network policies.

D. It prevents all denial-of-service attacks.

Correct Answer: B. It limits the privileges available if the application is compromised.

Question 5

Which Kubernetes control evaluates a workload request before the object is accepted by the cluster?

A. Admission control

B. Object storage replication

C. Database indexing

D. Client-side rendering

Correct Answer: A. Admission control

Question 6

Which practice best protects secrets used by a cloud application?

A. Embedding them in source code for easy deployment

B. Placing them in a public container image

C. Storing them in a protected secrets-management service with controlled access and rotation

D. Writing them to application logs

Correct Answer: C. Storing them in a protected secrets-management service with controlled access and rotation

Question 7

What is the main security purpose of an API rate limit?

A. To guarantee correct authorization decisions

B. To restrict request volume and help reduce abuse or resource exhaustion

C. To encrypt database records

D. To replace input validation

Correct Answer: B. To restrict request volume and help reduce abuse or resource exhaustion

Question 8

Which statement about container image scanning is most accurate?

A. A clean scan proves that the image is completely safe.

B. Scanning can identify known issues but does not replace provenance, review and runtime controls.

C. Scanning is unnecessary when an image is small.

D. Scanning automatically fixes all vulnerabilities.

Correct Answer: B. Scanning can identify known issues but does not replace provenance, review and runtime controls.

Question 9

A serverless function receives an object-storage event. What should it do first from a security perspective?

A. Trust every field because the event came from the cloud provider.

B. Disable all logging.

C. Validate the event source, structure and relevant input before processing it.

D. Grant itself administrator permissions.

Correct Answer: C. Validate the event source, structure and relevant input before processing it.

Question 10

Which measure most directly limits Kubernetes lateral movement between workloads?

A. Network policies restricting permitted pod communication

B. Increasing container image size

C. Using longer application names

D. Disabling resource limits

Correct Answer: A. Network policies restricting permitted pod communication