Cloud, Container and DevSecOps Penetration Testing

Introduction

Cloud computing, containers and DevSecOps have changed how organisations design, deploy and operate information systems. Applications may now use managed identity services, object storage, serverless functions, ephemeral containers, Kubernetes clusters and automated delivery pipelines. These technologies improve scalability and speed, but they also distribute responsibility across customers, cloud providers, software vendors and development teams.

Penetration testing in these environments is therefore more than scanning public IP addresses. A competent tester must understand identity permissions, cloud network controls, storage policies, container images, orchestration, infrastructure as code (IaC), software dependencies and continuous integration/continuous delivery (CI/CD). Testing must also be authorised, tenant-safe and consistent with provider rules.

The central principle of this chapter is that technical capability does not create legal permission. A tester may possess the ability to enumerate a cloud account or exploit a container escape, but testing is legitimate only when the target, methods, dates, accounts and data-handling procedures are explicitly authorised.

Learning Objectives

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

1. Explain shared responsibility and its effect on cloud penetration testing.
2. Assess cloud identities, storage, networks and serverless services safely.
3. Identify vulnerabilities in container images, runtimes and Kubernetes deployments.
4. Evaluate IaC and CI/CD pipelines as attack surfaces.
5. Design a tenant-safe, provider-compliant penetration test.
6. Recommend DevSecOps controls that integrate security into development and operations.

1. The Cloud Penetration-Testing Context

1.1 Shared responsibility

In a traditional data centre, one organisation may control facilities, hardware, networks, operating systems and applications. In cloud computing, responsibility is divided. The provider usually secures the underlying facilities, physical infrastructure, host platform and core managed service. The customer remains responsible for items such as identities, data classification, configuration, application code and, depending on the service model, operating systems and network rules.

The exact division differs among providers and services. A penetration-test report should therefore identify the specific service, not rely on a generic assumption.

A useful assessment question is: “Which party can change this control?” If the answer is the provider, the tester should normally verify the control through documentation, configuration evidence or an approved provider assessment rather than attempting an intrusive attack against provider infrastructure.

1.2 Cloud authorisation and rules of engagement

Before testing, obtain written authorisation from the asset owner and confirm the cloud provider’s current acceptable-use and penetration-testing policy. The authorisation should specify:

• cloud account, subscription, project or tenant identifiers;
• domains, APIs, workloads and IP ranges in scope;
• testing dates and permitted source addresses;
• permitted techniques, such as authenticated assessment, web testing or controlled exploitation;
• prohibited actions, such as denial-of-service, destructive testing, cryptocurrency mining and testing other tenants;
• emergency contacts and stop conditions;
• data access, retention and deletion requirements.

Provider policies can change. Some providers permit certain tests without advance approval, while others require notification or prohibit specific services. The tester must verify current requirements rather than generalise from experience with another provider.

1.3 Threat modelling for cloud systems

Threat modelling helps determine what should be tested. Relevant trust boundaries include:

• developer workstation to source repository;
• source repository to CI runner;
• CI runner to cloud account;
• public user to API gateway;
• workload to metadata or identity services;
• one container or namespace to another;
• customer-controlled resources to provider-managed infrastructure.

Threats include credential theft, excessive privileges, exposed storage, insecure interfaces, supply-chain compromise, secret leakage, vulnerable images, insecure network paths and weak separation between development and production.

2. Assessing Cloud Identities and Access

Identity is often the primary security boundary in cloud environments. A stolen access key may be more valuable than a vulnerable web server because it can provide access to many services.

2.1 Identity architecture

Assess the following components:

• human users and groups;
• service accounts, roles and workload identities;
• federation and single sign-on;
• multi-factor authentication (MFA);
• temporary credentials and token lifetime;
• access keys and secrets;
• privilege-elevation paths;
• administrative and break-glass accounts;
• logging of authentication and authorisation events.

Testing should begin with approved, non-production test identities whenever possible. The objective is to determine whether a principal can perform actions beyond its business requirement, not to collect unnecessary data.

2.2 Least privilege and privilege escalation

Least privilege means that an identity receives only the permissions required for its defined tasks. Assessment should examine both direct permissions and indirect paths. For example, a developer may not be allowed to administer a database directly but may be permitted to modify a CI job that runs with an administrative role. That indirect relationship is a privilege-escalation route.

A practical review asks:

1. What can the identity do directly?
2. Can it assume, impersonate or attach another role?
3. Can it modify a policy, function, image or pipeline used by a more privileged identity?
4. Can it access credentials or tokens belonging to another workload?
5. Are permissions restricted by resource, action, network, time or condition?

Findings should distinguish effective privilege from merely unused privilege. A permission that is technically granted but impossible to reach may have a different risk profile from a permission that is immediately exploitable.

2.3 Safe identity testing

Do not alter production policies merely to demonstrate a weakness. Use read-only inspection, provider policy simulators, test roles and controlled canary resources. If exploitation is necessary, perform the minimum action needed to prove impact, such as creating a harmless test object rather than deleting or encrypting real data.

3. Storage, Network and Serverless Assessment

3.1 Object and file storage

Cloud storage failures frequently result from incorrect access policies rather than software defects. Assess:

• public-read and public-write exposure;
• anonymous listing;
• cross-account or cross-tenant access;
• encryption at rest and key permissions;
• versioning and deletion protection;
• logging and monitoring;
• lifecycle rules and backup retention;
• sensitive information in object names, metadata or content;
• upload validation and malware-handling processes.

A safe test uses a uniquely named, non-sensitive canary file. The tester should verify whether the file can be read, modified or listed from an unauthorised context and then remove it according to the agreed procedure. Downloading an entire exposed bucket is rarely necessary and may breach privacy obligations.

3.2 Cloud networks

Cloud networks are logical constructions involving virtual networks, subnets, route tables, security groups, network access controls, firewalls, gateways and private endpoints. An assessment should map intended flows and compare them with effective flows.

Important questions include:

• Are administrative interfaces reachable from the public internet?
• Are security groups overly broad, especially for remote administration?
• Can a public workload reach databases or internal management services?
• Are production and development networks separated?
• Are egress paths controlled and logged?
• Are private endpoints protected by identity and network policy?
• Do IPv6 and alternative protocols receive equivalent controls?

Cloud network testing should avoid high-volume traffic. Connectivity can usually be demonstrated with minimal protocol requests, approved test services and configuration evidence.

3.3 Serverless functions and managed APIs

Serverless systems introduce event triggers, function roles, API gateways, queues and managed data stores. Testers should examine:

• authentication and authorisation at the API gateway and function;
• input validation and injection risks;
• function execution roles;
• event-source permissions;
• secret storage and environment variables;
• dependency versions;
• timeout, memory and concurrency controls;
• logging of sensitive data;
• unsafe deserialisation or file processing;
• cross-function invocation rights.

A function may be small, but its execution role can be broad. The security impact depends on the role and reachable services, not only on the function’s source code.

4. Container Security

4.1 Container images

An image is a package of application code, libraries, configuration and operating-system components. Image assessment should include:

• known vulnerabilities in base images and dependencies;
• unsupported or obsolete packages;
• embedded passwords, tokens and private keys;
• unnecessary utilities and shells;
• unsafe file permissions;
• use of a non-root user;
• image provenance and signing;
• pinned or mutable tags;
• build instructions and source repositories.

Vulnerability scanners produce useful evidence but not a complete risk judgement. A reported vulnerable library may be unreachable, while an unreported configuration weakness may be directly exploitable. Findings should be validated against the image’s use, exposure and compensating controls.

4.2 Runtime and isolation

Containers provide process isolation, but they are not identical to virtual machines. Risks include privileged mode, host filesystem mounts, access to host devices, excessive Linux capabilities, insecure namespaces, exposed container sockets and weak runtime configuration.

A safe assessment checks configuration and, where authorised, demonstrates impact using a controlled workload. Attempts to escape to a host or interfere with neighbouring workloads should not be performed casually, especially on shared infrastructure. The tester must establish whether the environment is dedicated, provider-managed or shared and follow provider restrictions.

4.3 Secrets and supply chain

Secrets can enter images through build arguments, environment variables, copied configuration files or source-control history. They should instead be retrieved at runtime from an approved secret-management service, with short-lived access and rotation. Base images and dependencies should come from trusted sources, be pinned by digest where practical, and be rebuilt regularly.

5. Kubernetes Penetration Testing

Kubernetes adds an orchestration control plane to containers. Its security model includes the API server, identity and role-based access control (RBAC), admission controls, scheduler, nodes, pods, services, ingress and network policies.

5.1 Scope and safety

Confirm whether the cluster is managed by the provider and whether control-plane testing is permitted. In many engagements, the customer can test workloads and configuration but cannot test provider control-plane infrastructure. Use a dedicated namespace and test service where possible.

5.2 Kubernetes assessment areas

A particularly important escalation path is the ability to create a pod with a service account or host mount that grants access to sensitive resources. Demonstration should use a harmless test pod and should stop before reading unrelated secrets or affecting other workloads.

5.3 Kubernetes evidence

Collect manifests, effective RBAC relationships, network-policy results, image references, audit events and relevant configuration. Redact tokens, certificates and personal information. Evidence should show the condition, affected resource, realistic impact and remediation rather than merely listing scanner output.

6. Infrastructure as Code and CI/CD

6.1 Infrastructure as code

IaC expresses infrastructure in declarative files. It creates repeatability, but an insecure definition can reproduce a weakness across many environments. Review:

• public exposure and overly broad firewall rules;
• unencrypted storage and weak key policies;
• hard-coded credentials;
• insecure defaults and unrestricted variables;
• missing logging, backup or monitoring;
• state-file protection;
• module provenance and version pinning;
• separation of plans, approvals and deployment credentials.

IaC scanning should occur before deployment, but a secure template does not guarantee a secure environment. Drift, manually changed settings, provider defaults and external dependencies must also be assessed.

6.2 CI/CD pipeline security

A pipeline is a privileged automated identity and a software supply-chain component. Testers should examine:

• repository branch and merge protections;
• authentication of runners and agents;
• secret exposure in logs and artefacts;
• pull-request and fork behaviour;
• dependency and action pinning;
• permissions granted to workflow tokens;
• separation of build, test and release environments;
• approval gates for production;
• artefact signing and provenance;
• protection against dependency confusion and typosquatting;
• retention and access to build artefacts.

A common weakness occurs when untrusted pull-request code executes with production secrets. A safe proof may show that a test workflow can access a canary secret, without exposing real credentials.

6.3 DevSecOps integration

DevSecOps does not mean moving all security work to developers. It means integrating proportionate security activities throughout the lifecycle. Examples include developer education, secure design review, secret scanning, software composition analysis, IaC scanning, image scanning, dynamic testing, policy-as-code, runtime monitoring and incident response exercises.

Controls should be risk-based. Blocking every medium-severity scanner result can encourage bypasses, while ignoring critical findings creates unacceptable exposure. Teams should define severity thresholds, exceptions, ownership, expiry dates and evidence requirements.

7. A Professional Testing Method

A cloud and DevSecOps engagement can follow this sequence:

1. Plan and authorise. Define assets, accounts, services, identities, dates, prohibited actions and communication paths.
2. Discover. Build an inventory of cloud resources, repositories, images, clusters, pipelines and data flows.
3. Model trust boundaries. Identify privileged identities, external interfaces, deployment paths and tenant boundaries.
4. Review configuration. Use approved read-only tools, policy analysis and IaC review.
5. Validate vulnerabilities. Reproduce important findings with minimal-impact tests and canary data.
6. Assess impact. Determine confidentiality, integrity, availability, regulatory and operational consequences.
7. Report. Document evidence, affected assets, attack path, likelihood, impact, remediation and retest criteria.
8. Remediate and retest. Confirm that fixes are effective and that no insecure alternative path remains.

Risk should not be based solely on a scanner score. A useful qualitative model considers exploitability, privilege required, exposure, affected data, detectability and business impact. Scores may support consistency, but professional judgement and asset context remain essential.

8. Illustrative Case: Retailer Migration to Cloud Kubernetes

Background

This fictional retailer migrated its online ordering platform to a managed Kubernetes service. Developers used a public source repository, an automated pipeline and object storage for customer-uploaded documents. The engagement was authorised for the retailer’s account and test namespace; provider control-plane attacks and denial-of-service were prohibited.

Problem

Initial review identified a deployment service account with permissions to create pods and read Kubernetes secrets. A container image ran as root and included an outdated command-line utility. The CI pipeline executed code from external pull requests and stored a cloud token in a build variable visible to a debugging step. An object-storage policy allowed public listing of a test bucket that had been copied from a production template.

Analysis

The individual findings formed a connected attack path. Code submitted through a pull request could potentially access the pipeline token. The token could invoke cloud services. Within the cluster, a service account could create a pod with excessive privileges and read secrets. The storage policy could expose uploaded documents if the bucket were used operationally. No destructive exploitation was needed to establish the risk.

Approach and solution

The testers used a canary token with no production permissions, a harmless test pod and a non-sensitive storage object. They demonstrated the pipeline exposure, confirmed the effective RBAC permissions and verified anonymous listing of the test bucket. The retailer then:

• removed secrets from pull-request workflows;
• replaced long-lived tokens with short-lived federated credentials;
• restricted the service account using RBAC;
• enforced non-root containers and blocked privileged settings through admission policy;
• rebuilt the image from a supported base;
• changed the storage policy to private access with explicit application roles;
• added IaC, secret, image and dependency checks to the pipeline;
• enabled monitoring and alerts for unusual role use.

Outcome

Retesting confirmed that the canary token was unavailable to untrusted workflows, the service account could no longer create privileged workloads, and anonymous storage access was denied. The case demonstrates that cloud risk often arises from relationships among identity, pipeline and workload configuration rather than from one isolated defect.

Learning points

1. Effective permissions matter more than role names.
2. CI/CD is part of the production attack surface.
3. Minimal-impact canaries can prove serious weaknesses safely.
4. Preventive policy, monitoring and retesting must operate together.

9. Limitations, Ethics and Governance

Cloud testing has important limitations. Provider-managed components may be inaccessible for direct testing. Ephemeral infrastructure can disappear before evidence is collected. Scanner results may be incomplete or inaccurate. A configuration review may miss runtime behaviour, while a dynamic test may miss dormant privilege paths. Testing also risks exposing personal data, regulated records or credentials.

Ethical practice requires necessity, proportionality, confidentiality and accountability. Testers should minimise collection, redact evidence, encrypt reports, restrict access and securely delete data according to the agreement. They must not pivot into unrelated tenants, test public resources merely because they are reachable, or use captured credentials beyond the authorised objective.

Governance should align technical findings with applicable laws, contracts and standards. Organisations may use recognised security frameworks, provider security guidance, secure software-development practices and data-protection requirements. The exact legal obligations depend on jurisdiction, sector and data type; technical staff should obtain appropriate legal and compliance advice rather than treating a framework as legal permission.

10. Contemporary Developments and Best Practices

Modern environments increasingly use identity federation, confidential computing, software bills of materials, signed artefacts, workload attestation, policy-as-code and automated remediation. Artificial intelligence is also appearing in code generation, alert triage and vulnerability analysis. AI-generated code and configurations must be reviewed because they may reproduce insecure permissions, vulnerable dependencies or exposed secrets. AI tools should not receive confidential source code or credentials unless approved by organisational policy.

Recommended practices include:

• maintain an accurate asset and identity inventory;
• use least privilege and short-lived credentials;
• separate development, test and production accounts;
• protect state files, logs, artefacts and backups;
• enforce secure container and Kubernetes policies;
• scan source, dependencies, IaC and images throughout the lifecycle;
• sign and verify build artefacts;
• monitor control-plane, identity and data-access events;
• rehearse incident response for compromised credentials;
• test continuously but within explicit authorisation;
• treat exceptions as time-limited, owned risks;
• retest remediation and measure recurring causes.

Chapter Summary

Cloud, container and DevSecOps penetration testing requires an understanding of distributed responsibility and modern deployment paths. Identity permissions, storage policies, cloud networks and serverless roles can create serious exposure even when no traditional server is vulnerable. Containers and Kubernetes require assessment of image provenance, runtime isolation, RBAC, secrets, network policies and admission controls. IaC and CI/CD must be tested because insecure definitions and privileged pipelines can reproduce weaknesses at scale.

Effective testing is authorised, provider-compliant, tenant-safe and evidence-based. Testers should prefer read-only analysis, canary resources and minimal-impact validation. Findings should explain attack paths and business consequences, then be followed by remediation and retesting. DevSecOps integrates security into design, coding, building, deployment and operations while preserving accountability and risk-based judgement.

Key Terms

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

Cloud identity: A human, service or workload principal that can authenticate and receive permissions.

Least privilege: Granting only the access required for an authorised task.

Workload identity: A cloud identity assigned to an application, service or runtime workload.

Object storage: A service that stores data as objects in logically organised containers.

Security group: A logical control that permits or denies network traffic to cloud resources.

Serverless function: Provider-managed code executed in response to events or requests.

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

Container escape: Unauthorised movement from a container into its host or another isolation boundary.

Kubernetes: A platform for orchestrating containerised workloads.

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

Namespace: A logical Kubernetes boundary used to organise and isolate resources.

Infrastructure as code: Declarative or programmatic definitions used to provision infrastructure.

CI/CD: Automated processes for integrating, testing, delivering and deploying software.

Secret: Confidential authentication material such as a password, token or private key.

Policy as code: Machine-enforced security or governance rules expressed in code.

Canary resource: A harmless test resource used to demonstrate access or behaviour safely.

Tenant safety: Preventing testing activity from affecting other customers or environments.

Review Questions

Short Answer Questions

1. What is meant by shared responsibility in cloud security?
2. Why can a CI/CD pipeline represent a high-value attack surface?
3. Identify two risks associated with running containers as root.
4. What is the purpose of a canary resource during penetration testing?
5. Name three areas that should be reviewed in a Kubernetes assessment.

Long Answer Questions

1. Explain how a tester should plan and authorise a cloud penetration test.
2. Discuss the relationship between least privilege, workload identity and privilege escalation.
3. Compare security considerations for object storage, serverless functions and cloud networks.
4. Explain how IaC and policy-as-code can reduce recurring cloud misconfiguration.
5. Describe a professional method for testing a Kubernetes cluster while protecting tenant safety.

Analytical / Application Questions

1. A build pipeline runs code from external pull requests and has access to a production deployment token. Analyse the attack path and propose layered controls.
2. A Kubernetes service account can create pods and read secrets, while network policies are absent. Explain how you would validate the risk safely and prioritise remediation.
3. An object-storage bucket is publicly listable but contains only test files today. Evaluate the risk, evidence required, governance concerns and immediate response.

Multiple Choice Questions with Answers

Question 1

Which statement best describes shared responsibility in cloud security?

A. The provider is always responsible for all customer data and identities.

B. The customer is always responsible for the physical data centre.

C. Security duties are divided according to the service and provider agreement.

D. Responsibility ends when a workload is deployed.

Correct Answer: C. Security duties are divided according to the service and provider agreement.

Question 2

What is the safest way to demonstrate unintended object-storage access?

A. Download every object in the storage account.

B. Use a uniquely named, non-sensitive canary object.

C. Delete an existing object and restore it later.

D. Publish the bucket URL publicly.

Correct Answer: B. Use a uniquely named, non-sensitive canary object.

Question 3

Which Kubernetes permission is especially sensitive because it may enable workload-based escalation?

A. Viewing a namespace label

B. Creating pods with excessive privileges

C. Reading a public service description

D. Viewing a deployment timestamp

Correct Answer: B. Creating pods with excessive privileges

Question 4

Which practice best protects a CI/CD pipeline from long-lived credential compromise?

A. Place credentials in source comments

B. Use short-lived federated credentials

C. Print credentials in debugging logs

D. Share one administrator token across projects

Correct Answer: B. Use short-lived federated credentials

Question 5

Why is running a container as root a security concern?

A. It always encrypts the host filesystem.

B. It may increase the impact of a container compromise.

C. It prevents all network communication.

D. It guarantees that the image is authentic.

Correct Answer: B. It may increase the impact of a container compromise.

Question 6

Which item is an example of indirect privilege escalation?

A. Reading an approved public webpage

B. Changing a personal display name

C. Modifying a pipeline that deploys with an administrative role

D. Viewing a test namespace label

Correct Answer: C. Modifying a pipeline that deploys with an administrative role

Question 7

What should a penetration tester do before testing a cloud provider environment?

A. Assume all provider services permit unrestricted testing.

B. Obtain written authorisation and verify current provider rules.

C. Begin with denial-of-service testing.

D. Test unrelated tenants to compare controls.

Correct Answer: B. Obtain written authorisation and verify current provider rules.

Question 8

Which control helps prevent unsafe Kubernetes workloads before deployment?

A. Admission policy

B. A larger container image

C. An unpinned image tag

D. A shared administrator account

Correct Answer: A. Admission policy

Question 9

What is a major limitation of relying only on vulnerability scanners?

A. Scanners can never inspect versions.

B. Scanner results may not reflect exploitability or business context.

C. Scanners always delete vulnerable files.

D. Scanners replace authorisation requirements.

Correct Answer: B. Scanner results may not reflect exploitability or business context.

Question 10

What is the principal security benefit of separating development and production cloud accounts?

A. It guarantees that no vulnerabilities exist.

B. It reduces the chance that development access directly affects production.

C. It removes the need for identity controls.

D. It prevents all software supply-chain attacks.

Correct Answer: B. It reduces the chance that development access directly affects production.