10. Cloud-Native Security and Platform Engineering

Introduction and Context

Cloud-native delivery has changed the security problem from protecting a bounded data centre to governing a dynamic system of cloud accounts, managed services, containers, serverless functions, identities, APIs, networks, and software supply chains. Infrastructure may be created and destroyed through code, workloads may move across regions and providers, and business services may depend on capabilities operated partly by an organisation and partly by a cloud provider. Security in this environment cannot be an approval performed at the end of a release. It must be embedded in architecture, platform design, developer workflows, runtime controls, and continuous evidence collection.

Platform engineering provides an organisational and technical response to this complexity. A platform team creates a governed internal platform—often called an internal developer platform—that offers reusable “golden paths” for deploying services securely. The platform does not remove developer responsibility; rather, it makes secure choices easier, more consistent, and observable. DevSecOps supplies the delivery practices, while platform engineering supplies the paved roads, guardrails, automation, and common services through which those practices become repeatable.

This chapter examines cloud-native security across multi-cloud and serverless environments. It focuses on the shared-responsibility model, cloud security posture management, workload protection, policy as code, service-mesh controls, secure landing zones, and platform engineering. The central argument is that security maturity depends less on accumulating tools than on establishing clear ownership, secure defaults, continuous control validation, and proportional responses to risk.

Learning Objectives

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

1. Interpret the shared-responsibility model for infrastructure, platform, container, and serverless services.

2. Design the security architecture of a multi-account or multi-subscription cloud landing zone.

3. Explain how CSPM, CIEM, CWPP, and related controls contribute to cloud workload protection.

4. Apply policy-as-code techniques to infrastructure, Kubernetes, identities, and deployment pipelines.

5. Evaluate service-mesh security controls, including identity, encryption, authorization, and observability.

6. Design secure platform-engineering patterns for containerized, serverless, and multi-cloud workloads.

7. Analyse governance, operational, ethical, and organisational trade-offs in cloud-native security.

From Shared Responsibility to Shared Accountability

The shared-responsibility model states that the cloud provider secures the infrastructure and services it operates, while the customer secures what it configures, deploys, and stores. The exact boundary varies. In infrastructure as a service, the customer commonly manages guest operating systems, network rules, identities, applications, and data. In platform as a service, the provider manages more of the operating stack, but the customer remains responsible for application logic, access control, configuration, and data. In a serverless function service, the provider manages servers and runtime infrastructure, while the customer must secure function code, dependencies, triggers, permissions, secrets, and data flows.

The model is useful but potentially misleading if treated as a transfer of accountability. A provider may secure the underlying service, yet a customer can still expose a storage bucket, grant excessive permissions, or deploy vulnerable code. Consequently, organisations should create a responsibility matrix that maps each control to an accountable role. The matrix should distinguish responsibility for implementing a control, operating it, reviewing evidence, and accepting residual risk.

A mature interpretation includes four layers:

• Provider controls: physical security, core infrastructure, managed service availability, and provider-side isolation.
• Platform controls: account structure, identity federation, network topology, logging, encryption configuration, and approved service patterns.
• Workload controls: application code, images, dependencies, runtime permissions, secrets, API behaviour, and data handling.
• Operational controls: monitoring, incident response, vulnerability remediation, backup testing, access reviews, and exception management.

This layered view prevents a common failure: assuming that a compliant cloud service automatically makes a deployed workload secure.

A Security Architecture for Cloud-Native Platforms

Secure landing zones

A landing zone is a governed foundation into which workloads are deployed. It normally includes a hierarchy of organisations, accounts, projects, or subscriptions; central identity; network connectivity; logging; security monitoring; resource standards; and mechanisms for separating production, non-production, security, and shared services.

A secure landing zone begins with strong account boundaries. Production workloads should not share unrestricted administrative space with experimentation. Separate accounts or subscriptions reduce blast radius, simplify billing and ownership, and support distinct policies. The structure should be understandable to humans and enforceable by automation.

Identity is the principal control plane. Federated workforce identity, phishing-resistant authentication for privileged users, short-lived credentials, role-based access, and workload identities are preferable to permanent access keys. Break-glass accounts should be rare, protected, monitored, and tested. Access should be granted to roles rather than individuals wherever practical, and privileged actions should generate high-quality audit records.

The network design should provide controlled ingress and egress, private access to managed services where available, segmentation for sensitive workloads, and central inspection where justified. Network controls are not a substitute for application authorization. They should be combined with identity-based and service-level controls, especially in distributed systems.

Centralised logging should include control-plane events, identity activity, network flows where relevant, workload logs, and security findings. Logs require integrity protection, time synchronisation, defined retention, restricted access, and operational use. Collecting logs without detection rules, ownership, or response procedures creates storage rather than security.

Policy as code

Policy as code expresses security, compliance, and operational requirements in machine-evaluable form. Examples include prohibiting public storage, requiring encryption, restricting deployment regions, enforcing approved image registries, denying privileged containers, and requiring resource tags. Policies may operate at different points:

1. Design time: architecture templates and reference modules embody approved patterns.

2. Pull-request time: infrastructure plans and Kubernetes manifests are scanned before merge.

3. Admission time: a cluster or platform rejects resources that violate mandatory rules.

4. Runtime time: cloud configuration and workload behaviour are continuously evaluated.

A sound policy programme distinguishes preventive, detective, and corrective policies. Preventive rules block unsafe actions; detective rules identify drift or exceptions; corrective automation repairs low-risk deviations. Not every rule should block deployment. A non-critical tagging omission may create a ticket, whereas public exposure of regulated data may require immediate denial.

Policies must be versioned, tested, reviewed, and mapped to owners. Poorly designed policies create false positives, encourage bypasses, and obstruct legitimate engineering. Policy exceptions therefore need an expiry date, business justification, compensating controls, and an accountable approver. A policy that cannot be explained to the engineers affected by it is unlikely to produce durable security.

Cloud security posture management and related capabilities

Cloud security posture management (CSPM) continuously evaluates cloud resources against configuration baselines, organisational policies, and sometimes regulatory control frameworks. It can identify public exposure, disabled logging, weak encryption settings, excessive network access, vulnerable services, and drift from approved templates. CSPM is primarily concerned with the security posture of cloud environments rather than only individual software vulnerabilities.

Several adjacent capabilities are often combined in a cloud-native security programme:

• Cloud workload protection platforms (CWPP): protect virtual machines, containers, hosts, and sometimes serverless workloads through vulnerability assessment, runtime detection, and workload controls.
• Cloud infrastructure entitlement management (CIEM): analyses identities, permissions, usage, and excessive privileges.
• Cloud detection and response: correlates cloud audit events, identity activity, network signals, and workload telemetry for investigation.
• Data security posture management: discovers sensitive data, evaluates exposure, and supports data access governance.
• Kubernetes security posture management: assesses cluster configurations, workloads, admission controls, and Kubernetes permissions.

These categories overlap in products, but the underlying questions differ: Is the environment configured securely? Can this identity perform more than necessary? Is the workload vulnerable or behaving abnormally? Is sensitive data exposed? Effective programmes integrate findings with asset ownership, risk scoring, remediation workflows, and evidence of closure. A long list of alerts without prioritisation is not a security strategy.

Protecting Workloads and Software Supply Chains

Workload protection begins before deployment. Source repositories require branch protection, review requirements, secret scanning, dependency management, and strong identity controls. Build systems should use isolated workers, minimal permissions, protected variables, and traceable provenance. Dependencies should be inventoried through a software bill of materials, scanned for known vulnerabilities, and evaluated for maintenance and trustworthiness. Vulnerability severity alone is insufficient; exploitability, exposure, business criticality, and availability of mitigations should influence prioritisation.

Container images should be built from minimal, maintained bases, scanned during build and admission, signed, and retrieved from controlled registries. Image signing supports verification of origin and integrity, but it does not prove that the image is free of vulnerabilities. Runtime controls should prohibit unnecessary privileges, restrict host access, use read-only filesystems where feasible, and apply resource limits. Kubernetes requires particular attention to service accounts, role bindings, network policies, admission controls, secrets handling, and separation of control-plane and workload responsibilities.

Serverless systems remove server administration but introduce different risks. Functions should have narrowly scoped execution roles, validated event sources, controlled outbound access, protected environment variables, dependency scanning, and structured logging. Event-driven designs require attention to replay, duplicate delivery, message poisoning, schema validation, and confused-deputy problems. A function that can read an entire database because it processes one queue is a design failure, even when the provider securely operates the runtime.

Secrets should not be embedded in source code, images, templates, or unprotected pipeline variables. A managed secret store, workload identity, rotation procedure, and access audit are preferable. Encryption is necessary but not sufficient: key ownership, separation of duties, backup, recovery, and access monitoring also matter.

Service Meshes and East–West Security

A service mesh provides a communication layer for services, commonly through sidecar or ambient data-plane components managed by a control plane. It can provide mutual TLS, service identity, traffic authorisation, retries, routing, telemetry, and policy enforcement without requiring every application team to implement these mechanisms independently.

Mutual TLS encrypts service-to-service traffic and authenticates workloads using identities issued by a mesh or integrated identity system. Encryption alone does not determine whether a request is legitimate. Authorization policies should specify which workload identities may call which services, on which paths, and using which methods. Policies should be default-deny where operationally feasible and tested against service dependencies before enforcement.

The mesh introduces its own attack surface. The control plane must be hardened, certificates must be rotated, data-plane components must be patched, and administrative interfaces must be restricted. Observability must avoid exposing tokens, personal data, or sensitive payloads. A mesh should not be adopted merely because it is fashionable; for a small system, platform-level network controls and application authorization may provide adequate protection with less complexity.

Platform Engineering as a Security Capability

Platform engineering turns recurring operational and security requirements into reusable products. A platform may offer a service catalogue, deployment templates, secure infrastructure modules, managed clusters, identity integration, secrets access, observability, and automated compliance evidence. Its users are internal development teams, and its success should be judged by secure delivery outcomes rather than by the number of platform components.

A golden path is an opinionated, documented route for a common task—for example, creating a web service with an approved repository, pipeline, image process, workload identity, logging, alerting, and deployment policy. Teams may depart from the path when necessary, but the platform should make the secure route the easiest route. Reusable modules must have versioning, support ownership, lifecycle management, and migration plans; otherwise they become hidden legacy systems.

Platform teams face an important governance balance. Excessive centralisation creates bottlenecks and prevents domain expertise from influencing design. Excessive autonomy produces inconsistent controls and duplicated effort. A product-oriented platform establishes non-negotiable guardrails for high-impact risks while allowing teams freedom within safe boundaries. Platform service-level objectives should include availability, recovery, security control coverage, remediation time, and developer experience.

Multi-Cloud and Serverless Decision-Making

Multi-cloud may be adopted for regulatory separation, acquisition integration, resilience, service capability, negotiation, or geographic reach. It also multiplies identity models, policy languages, logging formats, networking patterns, and operational skills. Portability should therefore be treated as a business option with a cost, not as an automatic benefit. Abstracting every provider-specific feature may reduce the ability to use managed security and reliability capabilities effectively.

A practical multi-cloud architecture defines common outcomes rather than forcing identical implementations. Common outcomes may include central identity federation, minimum logging, encryption requirements, vulnerability remediation targets, incident escalation, data classification, and approved regions. Provider-specific controls can then satisfy those outcomes. A control catalogue should document equivalence and gaps across providers.

Serverless adoption similarly requires architectural judgement. It can reduce patching responsibilities and scale efficiently, but it increases dependence on provider events, permissions, API gateways, queues, and observability. Teams should model data flows and trust boundaries, test failure and replay behaviour, and establish a clear inventory of functions and triggers. Function count is not a security metric; quality of identity, data protection, deployment control, and monitoring is more important.

Illustrative Case Study: A Regulated Retail Platform

Background

A fictional online retailer, Northstar Retail, operated customer-facing services in two public clouds after an acquisition. Teams deployed containers to Kubernetes in one cloud and serverless order-processing functions in the other. Security findings were increasing, but ownership was unclear. Public storage exposures, long-lived access keys, inconsistent logging, and excessive function permissions were discovered during an internal review.

Problem and analysis

The shared-responsibility analysis showed that providers were securing underlying infrastructure, while Northstar had failed to govern account configuration, identities, workload permissions, and data flows. The company also had no common inventory. CSPM findings could not be assigned reliably because resources lacked ownership metadata. Different teams used separate image registries and manually configured pipelines. The service mesh encrypted some traffic, but authorization was inconsistent.

Strategy and solution

Northstar established a landing-zone programme with separate production, development, security, and shared-service accounts. Workforce access was federated, privileged roles required stronger authentication, and workloads received short-lived identities. Central audit logs were protected in a dedicated security account. A platform team published secure templates for containers and functions, including mandatory ownership metadata, approved registries, secret-store integration, baseline logging, and least-privilege role generation.

Policy as code was introduced in stages. Pull-request checks detected unsafe infrastructure plans; admission controls blocked privileged containers and unapproved images; runtime posture monitoring identified drift. High-risk public exposure was prevented, while lower-risk policy violations created time-bound remediation tasks. The service mesh adopted workload identity, mutual TLS, and explicit service authorization for sensitive APIs. Function events were validated, permissions were narrowed, and queue replay was tested.

Outcome

The organisation did not eliminate every finding, but it improved ownership, reduced standing privilege, and made secure deployment patterns repeatable. Exceptions became visible and temporary rather than informal and permanent. Incident investigations benefited from central logs and consistent workload identity. The platform team also measured adoption, failed policy checks, remediation age, and developer-reported friction, using the results to refine golden paths.

Learning points

The case demonstrates that cloud security is an operating model as much as a toolset. A landing zone without workload controls is incomplete; policy without ownership is ineffective; and platform automation without exception governance can institutionalise unsafe defaults. Security improvements became sustainable only when architecture, identity, delivery, runtime protection, and organisational accountability were designed together.

Challenges, Governance, and Professional Judgement

Cloud-native security has several persistent limitations. Automated posture tools may misunderstand business context and generate false positives. Runtime protection can impose performance or compatibility costs. Service meshes add operational complexity and may create a false sense that encrypted traffic is authorised traffic. Serverless abstractions reduce infrastructure work but can make dependencies and event paths difficult to visualise. Multi-cloud control equivalence is rarely perfect.

Governance should therefore be risk-based. Regulations may require data residency, auditability, retention, breach notification, access review, or sector-specific controls. Organisations must identify the legal entity responsible for data, understand provider contractual commitments, and verify that technical controls produce usable evidence. Privacy principles such as purpose limitation, minimisation, restricted access, and retention should inform platform defaults.

Ethical practice includes avoiding surveillance beyond legitimate security purposes, protecting employee and customer data in logs, explaining automated blocking decisions, and ensuring that security controls do not unfairly exclude teams with limited resources. Engineers should disclose material limitations, avoid claiming that a compliance certificate guarantees workload security, and maintain professional competence as cloud services evolve.

Common mistakes include treating the provider as responsible for customer configuration, granting broad administrative roles for convenience, creating security policies without remediation ownership, centralising all platform decisions, ignoring non-human identities, and measuring success by tool deployment rather than risk reduction. Another frequent error is allowing exceptions to become permanent architecture. Each exception should have an owner, compensating controls, review date, and retirement condition.

Emerging Directions and Best Practices

Cloud-native security is increasingly influenced by identity-centric architecture, confidential computing, workload attestation, software supply-chain provenance, and automated evidence generation. Artificial intelligence is being used to group findings, detect anomalous identity behaviour, summarise incidents, and assist policy authoring. Such systems require human oversight because generated explanations can be incomplete, and automated remediation can amplify an incorrect assumption.

Best practice is to:

• define responsibilities for every cloud and workload control;
• establish secure landing zones before uncontrolled workload expansion;
• prefer federated, short-lived, least-privilege identities;
• treat infrastructure, policy, and platform templates as versioned software;
• connect findings to owners, business criticality, and remediation deadlines;
• protect containers and functions through identity, provenance, dependency, and runtime controls;
• use service-mesh controls where their complexity is justified;
• design logging for detection, investigation, privacy, and evidence;
• make secure golden paths easier than bespoke deployment;
• test recovery, policy exceptions, access revocation, and incident response;
• review provider-specific assumptions and multi-cloud control gaps regularly.

Chapter Summary

Cloud-native security operates across provider infrastructure, cloud platforms, workloads, and organisational processes. The shared-responsibility model defines technical boundaries, but customers retain accountability for configuration, identity, code, data, and operations. Secure landing zones provide governed account structures, central identity, network foundations, logging, and policy enforcement. CSPM, CIEM, CWPP, data security, and detection capabilities address different aspects of posture, entitlement, workload, data, and runtime risk.

Policy as code enables preventive, detective, and corrective controls throughout the software lifecycle, provided policies are tested, owned, and supported by disciplined exception management. Containers and serverless functions require supply-chain security, least privilege, secret protection, event validation, and runtime monitoring. Service meshes can provide workload identity, mutual TLS, authorization, and telemetry, but they also introduce complexity and must not replace application-level security.

Platform engineering makes secure delivery repeatable through golden paths, reusable modules, and self-service capabilities with guardrails. In multi-cloud and serverless environments, the most effective strategy is to standardise security outcomes while accepting justified provider-specific implementations. Mature security programmes combine automation with human judgement, governance, privacy protection, measurable ownership, and continuous improvement.

Key Terms

Shared responsibility model: A model dividing security duties between a cloud provider and its customer.

Landing zone: A governed cloud foundation containing account, identity, network, logging, and policy controls.

Cloud security posture management (CSPM): Continuous assessment of cloud resources against security and compliance requirements.

Cloud workload protection platform (CWPP): Controls that protect hosts, containers, and other workloads from vulnerabilities and runtime threats.

Cloud infrastructure entitlement management (CIEM): Analysis and governance of cloud identities, permissions, and excessive privileges.

Policy as code: Machine-readable security or governance rules that are versioned and automatically evaluated.

Golden path: An approved, reusable route for completing a development or deployment task securely.

Internal developer platform: A product-like set of tools and services enabling teams to build and operate software.

Workload identity: An identity assigned to an application, function, or service rather than a human user.

Service mesh: An infrastructure layer controlling and observing service-to-service communication.

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

East–west traffic: Communication between services inside a distributed environment.

Software bill of materials: An inventory of components and dependencies contained in software.

Admission control: A mechanism that validates or rejects resources before they enter a platform or cluster.

Security drift: Divergence between an actual environment and its approved configuration.

Break-glass account: A highly protected emergency account used when normal administrative access is unavailable.

Serverless computing: A model in which the provider manages servers while customers deploy functions or managed application components.

Exception management: The controlled process for approving, monitoring, expiring, and retiring policy deviations.

Review Questions

Short Answer Questions

1. How does the shared-responsibility model differ between infrastructure as a service and serverless functions?

2. What purposes are served by a secure cloud landing zone?

3. Distinguish CSPM from CIEM.

4. Why is encryption alone insufficient for service-to-service security?

5. What is the role of a golden path in platform engineering?

Long Answer Questions

1. Explain how identity, network design, logging, and policy as code combine to secure a multi-account cloud environment.

2. Discuss the security lifecycle of a container workload from source repository to runtime.

3. Evaluate the security benefits and operational costs of adopting a service mesh.

4. Explain how serverless architecture changes, rather than eliminates, security responsibilities.

5. Analyse the organisational relationship between DevSecOps and platform engineering.

Analytical / Application Questions

1. A team deploys a function with permission to read all production data because it processes one queue. Analyse the risks and propose a redesigned identity and data-access model.

2. A CSPM tool reports thousands of findings, but developers rarely remediate them. Design a prioritisation and ownership process using the principles in this chapter.

3. An organisation wants identical security controls across two cloud providers. Determine which outcomes should be standardised and which implementations may remain provider-specific, giving reasons.

22. Multiple Choice Questions with Answers

Question 1

A customer deploys a serverless function with excessive database permissions. Which statement best describes the responsibility?

A. The cloud provider is responsible because it operates the function runtime.

B. The customer is responsible for the function’s identity and data access permissions.

C. The service mesh is responsible for correcting the permission.

D. The responsibility belongs exclusively to the database vendor.

Correct Answer: B. The customer is responsible for the function’s identity and data access permissions.

Question 2

Which landing-zone control most directly reduces the risk of unmanaged privileged access?

A. Federated identity with short-lived, least-privilege roles

B. A larger shared network

C. Disabling central audit logs

D. Using permanent access keys for automation

Correct Answer: A. Federated identity with short-lived, least-privilege roles

Question 3

What is the primary purpose of CSPM?

A. Writing application business logic

B. Managing employee performance

C. Continuously assessing cloud configuration and security posture

D. Replacing all incident-response procedures

Correct Answer: C. Continuously assessing cloud configuration and security posture

Question 4

Which policy is most appropriately enforced preventively at cluster admission?

A. A quarterly review of security culture

B. A prohibition on privileged containers

C. A post-incident lessons-learned report

D. A business continuity survey

Correct Answer: B. A prohibition on privileged containers

Question 5

What does mutual TLS provide in a service mesh?

A. Automatic approval of every application request

B. Authentication and encryption between communicating workloads

C. Removal of the need for application authorization

D. Guaranteed elimination of vulnerable dependencies

Correct Answer: B. Authentication and encryption between communicating workloads

Question 6

Why should a software bill of materials be combined with vulnerability and exposure analysis?

A. Component inventory alone does not establish exploitability or business impact.

B. It prevents all future vulnerabilities.

C. It replaces the need for source control.

D. It guarantees that signed images are secure.

Correct Answer: A. Component inventory alone does not establish exploitability or business impact.

Question 7

Which is the strongest example of a platform-engineering golden path?

A. A general instruction to deploy securely

B. A reusable service template with identity, secrets, logging, scanning, and deployment controls

C. A spreadsheet listing all developers

D. A policy that prohibits all provider-specific services

Correct Answer: B. A reusable service template with identity, secrets, logging, scanning, and deployment controls

Question 8

A policy exception remains active for three years without review. Which governance weakness is most evident?

A. The exception lacks time-bound ownership and retirement criteria.

B. The cloud provider has excessive physical security.

C. The service mesh uses mutual TLS.

D. The workload has too many logs.

Correct Answer: A. The exception lacks time-bound ownership and retirement criteria.

Question 9

What is a major multi-cloud security challenge?

A. Cloud providers always use identical identity and logging models.

B. Security outcomes may require different provider-specific implementations and evidence.

C. Multi-cloud removes the need for governance.

D. Workloads cannot use managed services in multi-cloud designs.

Correct Answer: B. Security outcomes may require different provider-specific implementations and evidence.

Question 10

Which statement best reflects mature cloud-native security?

A. Deploying more tools is sufficient even without ownership.

B. Compliance certification automatically secures every workload.

C. Secure defaults, continuous evidence, clear accountability, and risk-based automation work together.

D. Network encryption eliminates the need for authorization.

Correct Answer: C. Secure defaults, continuous evidence, clear accountability, and risk-based automation work together.