This chapter covers cloud-native security architecture, a critical domain for the SY0-701 exam under Objective 3.6 (Security Architecture). You will learn the shared responsibility model, microservices security, API security, and the unique challenges of containerized and serverless environments. Understanding these concepts is essential for designing secure cloud deployments and answering scenario-based questions on the exam.
Jump to a section
Imagine a modern apartment building where each tenant (customer) occupies a separate unit (virtual machine or container). The building manager (cloud provider) is responsible for the structural integrity of the building—foundation, walls, roof, elevators, and fire suppression systems (physical security, hypervisor, network backbone). Tenants are responsible for securing their own units—locking doors, setting alarms, not leaving windows open (OS patching, firewall rules, identity management). However, the building also has shared spaces: hallways, laundry rooms, and the lobby (shared databases, APIs, and storage). A tenant cannot simply claim that the building manager should lock their individual unit door—that is the tenant's job. Conversely, if a fire starts in one unit due to faulty wiring (a vulnerability in the hypervisor), the building manager must contain it to prevent spread to other units. This is the shared responsibility model. In cloud-native architecture, the building manager also provides optional security services—like a security guard at the entrance (cloud firewall), package screening (DLP), and keycard access (IAM). The tenant can choose to use these or implement their own. The key insight: the tenant always retains responsibility for what is inside their unit, even if the building manager provides locks. A common mistake is assuming the building manager secures everything, leaving the unit door unlocked.
What is Cloud-Native Security Architecture?
Cloud-native security architecture refers to the design principles and practices used to secure applications and infrastructure built specifically for cloud environments. Unlike traditional 'lift-and-shift' migrations, cloud-native applications leverage microservices, containers, orchestration (e.g., Kubernetes), and serverless computing. The security model must account for ephemeral resources, dynamic scaling, and a high degree of automation. The core threat is that traditional perimeter-based security (firewalls, VPNs) is insufficient because there is no fixed perimeter—traffic flows between microservices, APIs, and external clients over the internet.
The Shared Responsibility Model (SRM)
The SRM defines which security controls are managed by the cloud provider and which by the customer. For IaaS (e.g., AWS EC2), the provider secures the physical host, hypervisor, and network; the customer secures the OS, applications, and data. For PaaS (e.g., AWS RDS), the provider secures the OS and runtime; the customer secures data and access. For SaaS (e.g., Office 365), the provider secures most layers except user access and data classification. Exam tip: The SY0-701 will test your ability to identify which party is responsible for a given control in different service models. A common wrong answer is assuming the provider secures everything in IaaS.
Microservices Security
Microservices communicate over APIs, often using HTTP/REST or gRPC. Each service should have its own identity and use mutual TLS (mTLS) for authentication. Service meshes like Istio provide a dedicated infrastructure layer for managing service-to-service communication, including encryption, authentication, and authorization. Without a service mesh, developers must implement these controls in each service, leading to inconsistencies. Attackers often exploit misconfigured service meshes or lack of mTLS to perform man-in-the-middle attacks between services.
API Security
APIs are the primary attack vector in cloud-native architectures. Key controls include: - Authentication: Use OAuth 2.0 with OpenID Connect for user authentication; API keys for service-to-service. - Rate limiting: Prevent brute force and DDoS attacks. - Input validation: Protect against injection attacks (SQL, NoSQL, command injection). - API gateways: Centralize security policies like authentication, logging, and throttling. Example: AWS API Gateway, Kong. - OWASP API Security Top 10: Know the top risks, especially broken object level authorization (BOLA) and mass assignment.
Containers (e.g., Docker) share the host kernel, so a container escape can compromise the host and other containers. Security measures include: - Image scanning: Use tools like Trivy or Clair to scan for vulnerabilities in base images. - Least privilege: Run containers as non-root users; use read-only filesystems. - Secrets management: Never hardcode secrets; use vaults like HashiCorp Vault or cloud-native secrets managers. - Runtime security: Use tools like Falco to detect anomalous behavior (e.g., a container spawning a shell). - Network policies: In Kubernetes, use NetworkPolicies to restrict traffic between pods.
Kubernetes Security
Kubernetes (K8s) is the de facto container orchestrator. Security concerns include: - RBAC: Define roles and bindings to limit who can access the API server. - Pod Security Standards (PSS): Apply policies like 'restricted' to enforce security contexts. - Admission controllers: Use tools like OPA/Gatekeeper to enforce policies (e.g., disallow privileged containers). - etcd encryption: Encrypt secrets at rest in etcd. - Audit logging: Enable audit logs for the API server. - Common misconfigurations: Exposing the Kubernetes dashboard to the internet, using default namespaces, running containers as root.
Serverless Security
Serverless (e.g., AWS Lambda) shifts responsibility to the provider for runtime, but the customer must secure function code, dependencies, and permissions. Key risks: - Event injection: Attacker triggers a function with malicious input (e.g., a crafted S3 event). - Over-privileged IAM roles: Functions should have minimal permissions (e.g., only read specific S3 bucket). - Insecure dependencies: Use dependency scanning tools. - Function timeout and memory: Attackers can cause resource exhaustion through infinite loops.
Infrastructure as Code (IaC) Security
IaC tools (Terraform, CloudFormation) define cloud resources declaratively. Security best practices: - Static analysis: Use tools like Checkov or tfsec to scan templates for misconfigurations (e.g., S3 bucket open to public). - Version control: Store IaC in Git and review changes via pull requests. - Secrets in code: Never commit secrets; use dynamic references to secrets managers.
Zero Trust in Cloud-Native
Zero Trust assumes no implicit trust based on network location. Every request must be authenticated and authorized. In cloud-native, this is implemented via: - Micro-perimeters: Each microservice is a micro-perimeter with its own firewall rules. - Identity-aware proxies: Use tools like BeyondCorp or Cloudflare Access. - Continuous verification: Use behavioral analytics to detect anomalies.
Real Command/Tool Examples
Scan a Docker image for vulnerabilities:
trivy image nginx:latestView Kubernetes pod security context:
kubectl get pod my-pod -o yaml | grep securityContextApply OPA policy in Kubernetes:
kubectl apply -f constraint.yamlCheck AWS Lambda permissions:
aws lambda get-policy --function-name my-functionStandards and References
NIST SP 800-190: Application Container Security Guide.
CIS Benchmarks: For Kubernetes, Docker, and cloud providers.
OWASP: API Security Top 10 and Serverless Top 10.
CSA: Cloud Controls Matrix (CCM).
Common Attack Examples
CVE-2019-5736: Container escape via runC (Docker).
CVE-2020-8554: Kubernetes man-in-the-middle via external IPs.
Serverless event injection: An attacker uploads a malicious file to S3 triggering a Lambda that executes unintended code.
Defensive Strategies
Implement a service mesh (e.g., Istio) for mTLS and authorization.
Use network policies to restrict east-west traffic.
Enable audit logging in Kubernetes and cloud providers.
Regularly scan images and IaC templates.
Apply least privilege to IAM roles and service accounts.
Design Cloud-Native Architecture
Start by defining the architecture: identify microservices, APIs, containers, and serverless functions. Map data flows and trust boundaries. For each component, determine the shared responsibility: which security controls are provider-managed vs customer-managed. Document the expected threat model (e.g., DDoS, API abuse, container escape). This step sets the foundation for all subsequent security decisions. Tools like threat modeling frameworks (STRIDE) or cloud-specific tools (AWS Well-Architected Tool) can help. A common mistake is skipping threat modeling, leading to missing controls like API rate limiting or network segmentation.
Implement Identity and Access Management
Configure IAM for human users and service identities. Use cloud IAM roles (e.g., AWS IAM roles) with least privilege. For microservices, implement service accounts with Kubernetes RBAC or cloud IAM roles for services (e.g., AWS IAM roles for service accounts). Enable federation with identity providers (IdP) using SAML 2.0 or OIDC. For APIs, use OAuth 2.0 with scopes. Log all authentication events in a centralized SIEM. A common mistake is using long-lived API keys instead of short-lived tokens or failing to rotate secrets regularly.
Secure the Container Pipeline
Integrate security into the CI/CD pipeline. Scan container images for vulnerabilities before deployment using tools like Trivy or Snyk. Enforce policies that block images with critical vulnerabilities. Sign images using Docker Content Trust or cosign to ensure integrity. Use admission controllers in Kubernetes to validate pod security contexts (e.g., disallow privileged containers). Store IaC templates in a version-controlled repository and scan them with static analysis tools. A common mistake is scanning only at build time and not continuously, missing new vulnerabilities discovered after deployment.
Configure Network Security Controls
Implement network segmentation using virtual private clouds (VPCs), subnets, and security groups. For Kubernetes, define NetworkPolicies to restrict pod-to-pod traffic. Use API gateways to centralize authentication, rate limiting, and logging. Enable mTLS between microservices via a service mesh. For serverless, restrict function triggers to only authorized sources (e.g., specific S3 buckets). A common mistake is allowing all outbound traffic from containers or functions, which can be exploited for data exfiltration.
Monitor and Respond to Threats
Deploy runtime security tools like Falco for containers and GuardDuty for cloud environments. Enable audit logging for all cloud services and Kubernetes API server. Centralize logs in a SIEM (e.g., Splunk, ELK) and set up alerts for suspicious activities (e.g., repeated API failures, container shell access). Implement incident response playbooks specific to cloud-native environments, such as isolating a compromised container or revoking IAM credentials. A common mistake is not having a response plan for container escape or serverless function abuse, leading to delayed containment.
Scenario 1: Kubernetes RBAC Misconfiguration
A SOC analyst notices repeated 403 errors in the Kubernetes audit log from a service account named 'monitoring-sa'. The service account is trying to list secrets in the 'production' namespace but is denied. Upon investigation, the analyst finds that the service account was granted 'cluster-admin' role due to a misconfiguration in a Helm chart. The attacker, who gained initial access via a vulnerable web application pod, used the service account token mounted inside the pod to escalate privileges. The correct response: revoke the cluster-admin binding, rotate the service account token, and scan the cluster for other misconfigurations using tools like kube-bench. Common mistake: assuming RBAC is correctly configured because the cluster was deployed using a 'secure' default chart, without auditing actual bindings.
Scenario 2: Serverless Function Exploitation
An engineer notices unexpected AWS Lambda invocations from an unknown AWS account. The Lambda function processes user-uploaded images and stores them in S3. The attacker discovered that the function does not validate the file type and uses a vulnerable library (ImageMagick) with a known RCE (CVE-2016-3714). The attacker uploaded a malicious image that executes arbitrary code, allowing them to read the function's environment variables, which contained database credentials. The correct response: immediately disable the function, rotate the database credentials, patch the library, add input validation (file type check), and restrict the function's IAM role to least privilege. Common mistake: relying solely on cloud provider's runtime protection without securing the function code itself.
Scenario 3: Container Image Backdoor
A security engineer scans a container image used in production and finds a high-severity vulnerability in the base image (Alpine Linux) that allows privilege escalation. The image was built six months ago and never rescanned. The attacker exploited this vulnerability to escape the container and access the host. The correct response: rebuild the image with an updated base image, implement a policy to rescan images weekly, and use an admission controller to block deployments using images older than 30 days. Common mistake: assuming that once an image is scanned at build time, it remains secure indefinitely.
Exactly What SY0-701 Tests
Objective 3.6 covers 'Cloud and virtualization security controls' and 'Security implications of cloud-native architectures'. You will be tested on:
The shared responsibility model: know which party is responsible for each control in IaaS, PaaS, SaaS.
Container security: image scanning, runtime protection, orchestration security (Kubernetes).
Serverless security: event injection, IAM roles, function code security.
API security: OAuth, rate limiting, input validation.
Infrastructure as Code (IaC) security: scanning templates, preventing misconfigurations.
Zero trust in cloud: micro-perimeters, identity-aware proxies.
Common Wrong Answers
'The cloud provider is responsible for all security in IaaS.' – Wrong because the customer secures the OS and applications.
'Containers are as secure as VMs because they are isolated.' – Wrong because containers share the host kernel; a container escape can compromise the host.
'Serverless functions are automatically secure because the provider manages the runtime.' – Wrong because the customer must secure code, dependencies, and permissions.
'API gateways are only for load balancing.' – Wrong because they also handle authentication, rate limiting, and logging.
Specific Terms and Values
mTLS: Mutual TLS for service-to-service authentication.
RBAC: Role-Based Access Control in Kubernetes.
PSS: Pod Security Standards (privileged, baseline, restricted).
OPA: Open Policy Agent for admission control.
CIS Benchmarks: For Kubernetes and Docker.
OWASP API Security Top 10: Especially API1 (BOLA) and API6 (Mass Assignment).
Trivy, Falco, Checkov: Specific tools mentioned in the exam.
Common Trick Questions
'Which of the following is a customer responsibility in PaaS?' – Answer: data and access management. Not: runtime patching.
'What is the primary risk of using containers?' – Answer: container escape. Not: resource consumption.
'Which tool can be used to enforce policies on Kubernetes pods?' – Answer: OPA/Gatekeeper. Not: a firewall.
Decision Rule for Eliminating Wrong Answers
On scenario questions, first identify the service model (IaaS, PaaS, SaaS). Then determine if the control is about the underlying infrastructure or the application. If the scenario involves a vulnerability in the OS, it is the customer's responsibility in IaaS but the provider's in PaaS. For container questions, always consider the shared kernel risk. For serverless, think about event injection and over-privileged IAM roles. Eliminate answers that shift responsibility to the provider when the customer should own it.
Shared responsibility model: provider secures the cloud, customer secures what is in the cloud.
In IaaS, customer secures OS, apps, and data; in PaaS, customer secures data and access; in SaaS, customer secures data classification and user access.
Containers share host kernel; use image scanning, runtime monitoring, and least privilege.
Kubernetes security: RBAC, PSS, admission controllers, network policies, etcd encryption.
Serverless security: secure function code, restrict IAM roles, validate inputs, scan dependencies.
API security: OAuth 2.0, rate limiting, input validation, API gateways.
Infrastructure as Code: scan templates with Checkov or tfsec to prevent misconfigurations.
Zero trust in cloud: micro-perimeters, identity-aware proxies, continuous verification.
These come up on the exam all the time. Here's how to tell them apart.
Virtual Machines (VMs)
Each VM has its own OS kernel (strong isolation).
Slower to start (minutes).
Larger resource footprint (GBs).
Hypervisor enforces isolation.
VM escape is rare but severe.
Containers
Containers share host kernel (weaker isolation).
Fast to start (seconds).
Smaller footprint (MBs).
Container escape is a primary risk.
Use runtime security tools like Falco.
Mistake
The cloud provider secures everything in IaaS.
Correct
In IaaS, the customer is responsible for OS, applications, and data; the provider secures the physical host, hypervisor, and network.
Mistake
Containers provide the same isolation as virtual machines.
Correct
Containers share the host kernel, so a kernel exploit can escape the container and compromise the host. VMs have stronger isolation via hypervisor.
Mistake
Serverless functions are inherently secure because the provider manages the runtime.
Correct
The customer must secure function code, dependencies, and IAM permissions. Vulnerable libraries or over-privileged roles can be exploited.
Mistake
API gateways only handle traffic routing.
Correct
API gateways also provide authentication, rate limiting, logging, and request validation, making them a critical security control.
Mistake
Infrastructure as Code (IaC) eliminates misconfigurations.
Correct
IaC can still contain misconfigurations (e.g., open S3 buckets) if not scanned. Static analysis tools like Checkov are needed.
The shared responsibility model defines which security controls are managed by the cloud provider and which by the customer. For IaaS, the provider secures physical infrastructure, hypervisor, and network; the customer secures OS, applications, and data. For PaaS, the provider secures runtime and middleware; the customer secures data and access. For SaaS, the provider secures most layers except user access and data classification. Exam tip: memorize the breakdown for each service model.
Containers share the host OS kernel, so a kernel exploit can lead to container escape and host compromise. VMs have separate kernels via a hypervisor, providing stronger isolation. However, containers are more resource-efficient. Security for containers includes image scanning, running as non-root, and using runtime monitoring tools like Falco.
The biggest risks are event injection (attacker triggers a function with malicious input) and over-privileged IAM roles (function can access more resources than needed). Also, vulnerable dependencies in function code can be exploited. Mitigations include input validation, least privilege IAM, and dependency scanning.
A service mesh (e.g., Istio) is a dedicated infrastructure layer for managing service-to-service communication. It provides mutual TLS (mTLS) for encryption and authentication, fine-grained access control, and observability. This offloads security logic from application code and ensures consistent policy enforcement across microservices.
Admission controllers intercept requests to the Kubernetes API server after authentication and authorization. They can validate or mutate resources (e.g., pods) before they are created. Tools like OPA/Gatekeeper enforce policies such as disallowing privileged containers or requiring specific labels. This prevents misconfigurations from being deployed.
Use an API gateway to centralize authentication (OAuth 2.0/OpenID Connect), rate limiting, and logging. Implement input validation to prevent injection attacks. Use short-lived tokens and rotate API keys regularly. Follow the OWASP API Security Top 10, especially to prevent broken object level authorization (BOLA).
Security groups are stateful and apply at the instance level (e.g., EC2). They allow you to specify inbound and outbound rules. Network ACLs are stateless and apply at the subnet level. They allow or deny traffic based on rules. Security groups are evaluated first, then network ACLs. In cloud-native, security groups are commonly used for microsegmentation.
You've just covered Cloud-Native Security Architecture — now see how well it sticks with free SY0-701 practice questions. Full explanations included, no account needed.
Done with this chapter?