Skip to main content

Cloud & Infrastructure Security

Cloud and infrastructure security is the discipline of designing, deploying, and operating the foundational systems that run modern software—securely, at scale, and in the face of constant change. It is not about clicking checkboxes in a cloud provider’s console. It is about engineering architectures that protect data, manage identities, contain breaches, and maintain resilience across distributed, ephemeral, and multi-account environments.

This section of SecurityDevPro provides the architectural patterns, operational practices, and security controls that every engineer working with cloud infrastructure needs to internalize. Whether you define virtual networks, manage Kubernetes clusters, provision cloud resources with Terraform, or operate secrets management platforms, the content here will equip you to build secure by default.

What Is Cloud & Infrastructure Security?​

Cloud security addresses the protection of workloads, data, identities, and infrastructure running on cloud platforms—public, private, or hybrid. Infrastructure security extends this focus to the underlying compute, network, and storage layers, whether they are cloud-managed services, on-premises data centers, or edge locations.

In traditional on-premises environments, security was often enforced at the physical perimeter: firewalls, VLANs, and locked server rooms. Cloud-native environments invert this model. The perimeter dissolves. Compute instances are short-lived. IP addresses are dynamic. Services communicate over the public internet or through software-defined networks. Identity becomes the primary security boundary.

A modern infrastructure security approach must address:

  • Public cloud (AWS, Azure, GCP, and others)
  • Private and hybrid cloud architectures
  • Multi-cloud strategies with consistent security controls
  • Containers and Kubernetes as the dominant runtime platform
  • Serverless functions and managed services with unique trust boundaries
  • Edge computing nodes that extend the attack surface beyond centralized data centers

Cloud security is not a standalone product; it is a property that emerges from architecture, automation, and operational discipline.

Why Cloud Security Matters​

Cloud-native systems are powerful but introduce unique security challenges:

  • Distributed systems: A single application might span dozens of services, each exposing APIs and managing its own data. The attack surface grows proportionally.
  • Identity sprawl: Human users, service accounts, CI/CD pipelines, and third-party integrations all require credentials. Managing and rotating them at scale is a non-trivial engineering problem.
  • Misconfiguration: Cloud platforms offer hundreds of services with complex configuration options. A single misconfigured S3 bucket, IAM role, or security group can expose critical data.
  • Shared responsibility: Cloud providers secure the underlying infrastructure, but customers remain responsible for securing their workloads, data, and access policies. Misunderstanding this boundary leads to dangerous gaps.
  • Secrets exposure: Hardcoded API keys, database passwords, and TLS certificates in source code, logs, or environment variables are a leading cause of cloud security incidents.
  • Rapid change: Infrastructure is created and destroyed by Terraform, CI/CD pipelines, and autoscaling events. Security must keep pace with this velocity.

Cloud security is not a separate function. It is an essential dimension of reliability engineering. An insecure system is unreliable by definition: it cannot maintain confidentiality, integrity, or availability in the face of threats.

The Shared Responsibility Model​

The shared responsibility model is the foundational mental model for cloud security. It delineates what the cloud provider secures and what you, the customer, must secure.

Cloud providers are responsible for "security of the cloud"— the physical facilities, hypervisors, network fabric, and foundational services that run the cloud itself. They protect the infrastructure that you consume as an API.

Customers are responsible for "security in the cloud"— everything they place into or build on top of the cloud. This includes:

  • Compute: The operating system, application runtime, and deployed code (for IaaS and containers). For serverless, it includes function code and configuration.
  • Storage: Access policies, encryption configuration, and lifecycle management on buckets, databases, and volumes.
  • Networking: Virtual network architecture, firewall rules, and traffic inspection configurations.
  • Identity: IAM policies, roles, and credential management.
  • Kubernetes: The cluster’s control plane configurations, pod security policies, network policies, and workload identities (in managed Kubernetes services, the control plane is typically a provider responsibility).

The exact boundary shifts depending on the service model—IaaS shares less, SaaS shares more—but the principle holds: you always own your data, your identities, and your configurations. Understanding this model is the first step toward building secure cloud systems. Dive deeper with our Shared Responsibility Model guide.

Core Knowledge Areas​

The Cloud & Infrastructure Security domain covers several interdependent disciplines. Each is explored in dedicated articles throughout this section.

Identity and Access Management (IAM)​

IAM is the cornerstone of cloud security. It governs who (or what) can perform which actions on which resources under what conditions. In a perimeter-less world, IAM defines the only boundaries that matter.

Key concepts include:

  • Identity: A principal—a human user, a service account, or a workload—that makes requests.
  • Authentication: Verifying the identity of that principal, often through federated identity providers, OIDC, or cloud-native mechanisms.
  • Authorization: Determining whether an authenticated principal may perform the requested action, typically expressed through IAM policies.
  • Least Privilege: Granting only the permissions required to accomplish a specific task. This limits blast radius.
  • Role-based access control and ABAC: Structuring policies around job functions or resource attributes rather than individual identities.
  • Federation: Extending trust from an external identity system (corporate SSO) to cloud providers.
  • Temporary credentials: Using short-lived tokens instead of long-lived access keys to reduce risk of credential theft.

IAM is the foundation upon which all other cloud security controls are built. Getting it right is non-negotiable. Start with IAM Fundamentals.

Network Security​

Network security in the cloud is about defining and enforcing communication boundaries. While traditional firewalls still have a role, cloud-native networking relies on software-defined constructs.

Engineers must understand:

  • Virtual Private Cloud (VPC) / Virtual Network (VNet) architectures: Isolating resources into logical network domains.
  • Segmentation: Dividing networks into subnets, separating public-facing, private, and data tiers.
  • Security Groups and Network ACLs: Stateful and stateless firewalls applied at the instance and subnet levels.
  • Zero Trust networking: Moving away from implicit trust based on network location; every communication requires authentication and authorization, often enforced via mutual TLS or service mesh policies.
  • Traffic inspection and egress controls: Understanding what data leaves your environment and through which paths.

Designing secure networks is about reducing the attack surface and limiting lateral movement. For a deeper architectural discussion, see Network Security Basics.

Data Protection​

Protecting data—both at rest and in transit—is a fundamental requirement. Key practices include:

  • Encryption at rest: Using cloud-managed keys (KMS) or customer-managed keys (CMK) to encrypt block volumes, object storage, databases, and backups.
  • Encryption in transit: Enforcing TLS for all communications, managing certificates, and deploying mutual TLS where appropriate.
  • Key Management: Centralizing key creation, rotation, and revocation using cloud KMS services or dedicated HSMs. Understanding envelope encryption and separation of duties for key administrators.
  • Secrets Management: Storing and distributing database credentials, API keys, and certificates through dedicated vault solutions, not environment variables or configuration files.
  • Backup and Disaster Recovery: Ensuring that backups themselves are encrypted, immutable, and stored in separate security domains to protect against ransomware and destructive attacks.

Data protection is not only about compliance; it is about maintaining trust.

Container Security​

Containers package applications with their dependencies and run as isolated processes. Their security spans the entire lifecycle:

  • Image security: Scanning base images and application layers for known vulnerabilities before deployment. Using minimal, distroless base images to reduce attack surface.
  • Registry security: Controlling access to container registries, signing images, and verifying signatures at deployment time.
  • Runtime security: Running containers with least-privilege capabilities, read-only root filesystems, and seccomp/AppArmor profiles. Detecting anomalous process behavior.
  • Isolation: Understanding that containers share a host kernel and implementing appropriate workload isolation—whether through pod security contexts, gVisor, Firecracker, or dedicated VM-based nodes.

Immutable infrastructure, where containers are replaced rather than patched, simplifies security management when paired with rigorous CI/CD practices. See Container Security for a complete walkthrough.

Kubernetes Security​

Kubernetes adds a powerful orchestration layer—and a significant attack surface. Securing a cluster requires attention at multiple levels:

  • Cluster security: Protecting the control plane, restricting access to the Kubernetes API, and enabling audit logging.
  • RBAC: Defining fine-grained roles and bindings for human users and service accounts within the cluster.
  • Network Policies: Implementing a "default deny" posture, then explicitly allowing required pod-to-pod and pod-to-external communication.
  • Admission Controllers: Validating and mutating requests before they are persisted, enabling policy enforcement for pod security standards, image provenance, and configuration constraints.
  • Pod Security: Enforcing pod-level security contexts, restricting privilege escalation, dropping all Linux capabilities, and using seccomp profiles.
  • Secrets management: Never storing plaintext secrets in Kubernetes Secrets without external encryption or integration with a dedicated secrets manager.
  • Workload Identity: Mapping Kubernetes service accounts to cloud IAM roles so pods obtain short-lived, scoped credentials automatically.

Our Kubernetes Security article covers these topics in an architecture-first manner.

Infrastructure as Code (IaC) Security​

Infrastructure as Code—Terraform, CloudFormation, Pulumi, Bicep—enables repeatable, version-controlled infrastructure. But it also creates a path for insecure configurations to be deployed at scale if left unchecked.

IaC security involves:

  • Static analysis of IaC templates: Scanning for misconfigurations (open S3 buckets, overly permissive IAM policies, security groups open to 0.0.0.0/0) before deployment.
  • Policy as Code: Defining organizational policies as executable rules (e.g., Open Policy Agent, HashiCorp Sentinel) that gate infrastructure changes.
  • Drift detection: Continuously monitoring that running infrastructure matches the intended declared state and that manual changes haven’t introduced vulnerabilities.
  • Secrets handling: Ensuring no hardcoded secrets in IaC files and integrating with secret injection mechanisms.

Shift-left security applies to infrastructure as much as to application code. Read more in Infrastructure as Code Security.

Secrets Management​

Secrets—API keys, database passwords, TLS certificates, tokens—are the keys to your kingdom. Effective secrets management is non-negotiable.

Core principles:

  • Centralize: Use a secrets manager (HashiCorp Vault, cloud-native secret services) as the single source of truth.
  • Rotate: Implement automatic rotation for all credentials. Short-lived credentials are preferred.
  • Inject, don’t embed: Retrieve secrets at runtime via sidecars, init containers, or provider integrations; never hardcode them in source code, configuration files, or CI/CD variables.
  • Audit: Log every access to secrets and alert on unusual patterns.

Our Secrets Management guide provides architectural patterns and trade-offs.

Cloud Security Architecture Principles​

These principles guide secure cloud architecture decisions:

  • Defense in Depth: Layer controls so that a failure at one layer does not result in full compromise. Combine network segmentation, IAM, encryption, and monitoring.
  • Zero Trust: Never trust a request based solely on its network origin. Verify every request as if it originated from an open network.
  • Least Privilege: Grant only the permissions necessary for a specific task, and review them continuously.
  • Secure by Default: Architect systems so that the initial state is safe—closed ports, private storage, zero-trust networking.
  • Immutable Infrastructure: Replace resources instead of patching them in place. This prevents configuration drift and reduces the window for persistent threats.
  • Segmentation: Break systems into isolated security zones (accounts, VPCs, clusters) to contain breaches.
  • Resilience: Design for failure. Security must hold under load, during attacks, and when components fail. Continuously test recovery procedures.

Architects apply these principles when drawing trust boundaries, defining account structures, designing IAM roles, and setting up network topologies.

Common Cloud Security Risks​

While threats evolve, a few categories account for the majority of real-world incidents. Understanding them conceptually helps prioritize defenses:

  • IAM Misconfiguration: Overly permissive roles, inactive credentials, and privilege escalation paths.
  • Public Storage Exposure: Misconfigured buckets, databases, or file shares that inadvertently expose data to the internet.
  • Excessive Permissions: Service accounts granted admin rights instead of scoped roles.
  • Weak Network Controls: Unrestricted ingress or egress rules that remove network isolation.
  • Insecure Containers: Images with known vulnerabilities, privileged containers, and inadequate runtime protections.
  • Vulnerable Dependencies: Outdated libraries and operating system packages within machine images and containers.
  • Secrets Leakage: Credentials in source code, logs, CI/CD output, or environment variables.
  • Misconfigured Kubernetes: Overly permissive RBAC, default network policies, exposed dashboards, and insecure pod settings.
  • Supply Chain Risks: Compromised base images, third-party modules, or CI/CD pipeline components.

Detailed mitigation strategies for each are covered throughout this section’s articles.

A structured progression through cloud security:

  1. Shared Responsibility Model – Understand where your responsibilities begin. Start here
  2. IAM Fundamentals – Master identity and access policies. Learn more
  3. Network Security – Design secure cloud networks. Explore
  4. Encryption and Key Management – Protect data at rest and in transit.
  5. Secrets Management – Centralize and automate credential handling. Read
  6. Container Security – Secure the entire container lifecycle. Dive in
  7. Kubernetes Security – Lock down clusters and workloads. Secure your clusters
  8. Infrastructure as Code Security – Prevent misconfigurations before deployment. Shift left
  9. Cloud Security Architecture – Integrate all controls into a coherent design.

Each step builds on the previous one, forming a complete picture of cloud-native defense in depth.

Relationship to Other Sections​

Cloud security is interconnected with every other domain in this handbook:

  • Security Foundations – The principles of the CIA triad, Zero Trust, and threat modeling directly inform cloud architecture decisions.
  • Application Security – The applications you deploy onto cloud infrastructure inherit the security posture of that infrastructure. Secure code on an insecure platform remains insecure.
  • DevSecOps – Automation pipelines are the primary interface for provisioning and modifying cloud resources. Securing those pipelines and embedding IaC scanning, secret detection, and policy gates is critical.
  • AI & Agent Security – AI workloads run on cloud infrastructure. Protecting models, training data, and inference endpoints requires the same IAM, network, and secret management disciplines, along with AI-specific controls.

Explore the core guides in this section:

Key Takeaways​

Cloud and infrastructure security is more than a configuration checklist. It is an engineering discipline grounded in architecture, identity, automation, and operational rigor.

  • Embrace the shared responsibility model. Know what you must secure and what your provider handles.
  • Treat IAM as the primary security boundary. Get identity right, and you dramatically reduce the surface for lateral movement.
  • Automate everything. IaC, policy as code, secret rotation, and image scanning are not optional extras—they are how security keeps pace with cloud velocity.
  • Design for defense in depth. Combine network controls, encryption, least privilege, and continuous monitoring so that a single misstep does not lead to catastrophe.
  • Apply Zero Trust principles. Never assume a network location is safe; verify every access.

The articles in this section translate these principles into actionable engineering guidance. Start with the Shared Responsibility Model, then work through the learning path. Your infrastructure is the foundation of everything you build—make it secure by design.