The Shared Responsibility Model: Where Cloud Provider Security Ends

Cloud providers do not secure your workloads. This is not a criticism: it is the fundamental design of the shared responsibility model, and misunderstanding it is one of the most common root causes of cloud security incidents. AWS, Azure, and Google Cloud secure the infrastructure they operate: physical data centers, hypervisors, global network fabric, and the managed services they expose. Everything you deploy on top of that infrastructure: your Kubernetes clusters, your virtual machines, your serverless functions, your IAM configurations, your S3 bucket policies: is your responsibility.

In practice, this line is blurry, and cloud providers have progressively moved it in their customers' favor. Managed Kubernetes services like EKS and AKS now handle control plane security. Managed databases encrypt at rest by default. Cloud-native firewalls and security groups provide network segmentation out of the box. But the application layer, the data layer, and the configuration layer remain entirely with the customer. A misconfigured security group that exposes port 22 to the internet, an S3 bucket with public read access, an IAM role with AdministratorAccess attached to a Lambda function: none of these are problems the cloud provider can fix for you.

The Norwegian regulatory context adds another dimension to this responsibility. GDPR requires that personal data processed in cloud environments meets specific standards around access control, breach notification, and data residency. Azure's Norway East and Norway West regions were specifically established to meet Norwegian sovereignty requirements, but data residency alone does not constitute compliance. The configuration and security of workloads running in those regions remains entirely within the customer's responsibility perimeter.

The Cloud-Native Attack Surface: What Attackers Actually Target

Cloud-native architectures have dramatically expanded the attack surface compared to traditional data centers. The attack vectors are well-documented in incident reports and threat intelligence feeds, and they fall into several consistent categories.

Exposed APIs and Management Interfaces

Cloud environments are API-driven. Kubernetes exposes the API server. Kubernetes clusters often have dashboards deployed with public ingress. Cloud management APIs are accessible from anywhere on the internet given valid credentials. Attackers systematically scan for exposed management interfaces: the Shodan database contains millions of exposed Kubernetes API servers, Elasticsearch instances, and cloud management consoles. Once an attacker reaches a management API, they often operate with legitimate tooling, making detection significantly harder than traditional malware-based attacks.

Misconfigured Object Storage

S3 bucket misconfigurations have caused some of the largest data breaches in recent history. The underlying pattern is consistent: a developer creates a bucket, sets it to public for a legitimate reason (static website hosting, for example), and either forgets to restrict it later or applies the wrong policy. Cloud Security Posture Management tools scan continuously for these conditions, but organizations that do not run CSPM tools discover these misconfigurations only after a breach or a third-party disclosure.

The risk extends beyond direct public access. Bucket policies that allow cross-account access, overly broad presigned URL generation, and server-side encryption gaps all represent exploitable conditions in a mature threat actor's playbook.

Over-Privileged IAM

Identity and Access Management is the most powerful and most commonly misconfigured security control in cloud environments. The principle of least privilege is well-understood in theory and consistently violated in practice. Development teams under delivery pressure attach broad managed policies because they work. Service accounts accumulate permissions over time. Terraform modules ship with permissive IAM defaults because they are easier to demonstrate. The result is an environment where a compromised workload: a pod, a Lambda function, a VM: can access resources far beyond its legitimate scope.

IAM-based lateral movement is now the dominant technique in sophisticated cloud breaches. Attackers who compromise a workload immediately query the instance metadata service for attached role credentials, then enumerate accessible resources using those credentials. In environments with over-privileged IAM, this enumeration often yields access to secrets stores, databases, backup buckets, and administrative functions.

Supply Chain in Container Images

Container images are software supply chain artifacts. A Docker image built on top of a public base image inherits every vulnerability in that base image. Public container registries host images with known critical vulnerabilities: some downloaded millions of times after the vulnerability was disclosed. Attackers have also deliberately introduced malicious packages into popular open-source registries, targeting teams that consume upstream dependencies without verification.

The container image supply chain encompasses the base OS layer, system packages, language runtime packages (npm, pip, Maven), and application code. Each layer introduces risk. Organizations that do not implement image scanning, provenance verification, and runtime protection are operating with a significant blind spot.

Container Security: From Build to Runtime

Image Scanning

Container image scanning should occur at multiple points in the supply chain. Scanning during the CI/CD pipeline, before an image is pushed to a registry, catches vulnerabilities early when remediation is cheapest. Registry scanning provides a continuous view of the vulnerability posture of all images stored in the registry, including images built before a new CVE was published. Admission control can block deployment of images that do not meet defined vulnerability thresholds.

Effective image scanning goes beyond CVE matching. Configuration scanning identifies Dockerfile best practice violations: running as root, exposing unnecessary ports, including secrets in image layers, using latest tags that prevent reproducible builds. SBOM (Software Bill of Materials) generation provides an inventory of all components in an image, enabling rapid impact assessment when new vulnerabilities are disclosed.

Runtime Protection

Runtime protection tools: implemented by solutions like Falco, Sysdig Secure, and similar platforms: provide behavioral monitoring for running containers. They operate by defining expected behavior profiles and alerting on deviations: a web server container that spawns a shell process, a database container that attempts to read /etc/passwd, a function container that initiates outbound connections to unexpected endpoints. These behaviors are often invisible to traditional signature-based detection but highly reliable indicators of compromise or malicious execution.

The technical implementation typically involves a kernel-level component (eBPF probes or kernel modules) that intercepts system calls and routes them through a policy engine. This approach provides visibility at the lowest level of the stack, where it cannot be evaded by userspace techniques.

Admission Controllers

Kubernetes admission controllers intercept API server requests before resources are persisted to etcd. Validating admission webhooks can reject non-compliant resources: pods that request privileged execution, deployments that do not specify resource limits, ingresses that do not require TLS. Mutating admission webhooks can inject security controls automatically: sidecar containers, security contexts, image pull policy enforcement.

Policy engines like OPA/Gatekeeper and Kyverno implement admission control as code, with policies defined in Rego or YAML respectively and stored in version control. This brings security policy into the DevOps lifecycle, enabling review, testing, and auditing of security rules alongside application configuration.

Pod Security Standards

Kubernetes Pod Security Standards replaced the deprecated Pod Security Policies with a simpler, three-level model: Privileged (no restrictions), Baseline (prevents known privilege escalation vectors), and Restricted (heavily constrained, following security best practices). Namespaces are labeled with an enforcement level, and the API server enforces the corresponding constraints at admission time. The Restricted standard requires non-root execution, disables privilege escalation, drops all capabilities, and requires a read-only root filesystem: controls that significantly limit the blast radius of a compromised container.

Kubernetes-Specific Risks

Exposed API Server and Dashboards

The Kubernetes API server is the single control point for the entire cluster. It should never be directly exposed to the internet. In practice, managed Kubernetes services often expose the API server with IP allowlisting as the primary control: a configuration that is frequently left overly permissive. The Kubernetes dashboard, while useful for visibility, represents a high-value target that should be accessible only through authenticated, authorized channels, ideally via kubectl proxy or a proper identity-aware proxy rather than a publicly routable ingress.

RBAC Misconfiguration

Kubernetes RBAC is granular and complex. The cluster-admin ClusterRole grants unrestricted access to every resource in the cluster. It is also the most commonly over-assigned role in production Kubernetes environments. Service accounts used by CI/CD systems, monitoring tools, and operators frequently receive far more permission than their function requires. Attackers who compromise these service accounts: by exploiting a vulnerability in the tool, by stealing the service account token, or by exploiting token auto-mounting in pods: gain substantial cluster access.

RBAC auditing should enumerate all ClusterRoleBindings and RoleBindings, identify service accounts with cluster-level permissions, and validate that each binding is necessary and documented. Automated RBAC analysis tools can flag excessive permissions and suggest least-privilege alternatives.

etcd Access

etcd is the key-value store that backs all Kubernetes state, including secrets. Secrets stored in etcd are base64-encoded by default: not encrypted. An attacker with direct access to etcd, or with access to an unencrypted etcd backup, can extract every secret in the cluster. Encryption at rest for etcd is a Kubernetes feature that must be explicitly configured. etcd should be accessible only from the API server, with mutual TLS enforced, and etcd endpoints should never be exposed outside the control plane network.

Node Compromise

A compromised node gives an attacker access to all container workloads running on that node, the kubelet credentials, the node's cloud provider IAM role, and any secrets mounted into pods on that node. Node-level attacks frequently exploit container escape vulnerabilities: flaws in the container runtime or the Linux kernel that allow a containerized process to break out of its namespace. Keeping node OS images patched, using minimal OS distributions (Container-Optimized OS, Bottlerocket), and implementing node-level EDR are the primary mitigations.

VM Workload Protection in the Cloud

Virtual machines running in cloud environments require the same endpoint protection controls as on-premises servers: with additional cloud-specific considerations. EDR (Endpoint Detection and Response) agents should be deployed on all cloud VMs, with telemetry feeding into a centralized SIEM. Cloud provider native solutions (Microsoft Defender for Servers, AWS GuardDuty) provide baseline coverage, but typically need to be supplemented with more capable EDR platforms for enterprises with mature detection requirements.

Patch management for cloud VMs requires automation. Manual patching of fleets that scale dynamically is operationally untenable. Cloud-native patch management services (AWS Systems Manager Patch Manager, Azure Update Manager) can automate patch assessment and deployment across VM fleets, with compliance reporting and exception management. The key operational principle is immutable infrastructure: rather than patching running VMs, build new images with patches applied and redeploy. This approach eliminates configuration drift and ensures that what is running in production matches what was built and tested.

Drift detection identifies when a running VM has diverged from its desired state: when unauthorized software has been installed, when configuration files have been modified, when new user accounts have been created. These changes may represent legitimate administrative activity or may indicate compromise. Detecting and investigating drift is a core capability of mature cloud security operations.

Serverless Security

Serverless functions: AWS Lambda, Azure Functions, Google Cloud Functions: present a distinct security profile. The infrastructure is entirely managed; the attack surface is concentrated in the function code, its dependencies, its permissions, and its event sources.

Function permissions are the most critical control. Each function should have an IAM role with the minimum permissions required for its operation. Functions that process S3 events need read access to the relevant bucket: nothing else. Functions that write to DynamoDB need write access to the relevant table: nothing else. The instance metadata service is available to Lambda functions running in VPCs, and over-privileged execution roles are exploitable in the same way as over-privileged EC2 instance profiles.

Event injection attacks exploit the trust that serverless functions place in their event sources. A function that processes user-supplied data from an API Gateway, an SQS queue, or an S3 object and passes that data to a downstream service without validation is vulnerable to injection. The attack surface depends on what downstream services the function calls: SQL databases, shell commands, deserialization of untrusted data, SSRF via URL construction from event data.

Dependency scanning for serverless functions is particularly important because the entire dependency tree is bundled into the deployment package. A Lambda function with a vulnerable npm package is a vulnerable Lambda function, regardless of what the runtime environment looks like. Scanning function packages for vulnerable dependencies should be part of the deployment pipeline.

CSPM: Continuous Misconfiguration Detection, Powered by a Live Application Graph

Cloud Security Posture Management tools continuously assess cloud environment configurations against security benchmarks and compliance frameworks. They enumerate resources across AWS, Azure, and GCP, evaluate each resource against a rule set (CIS Benchmarks, NIST CSF, SOC 2, PCI-DSS, ISO 27001), and surface findings with risk scoring and remediation guidance.

The value of CSPM is in the continuous nature of the assessment. Point-in-time configuration reviews become stale immediately in dynamic cloud environments where resources are created and modified continuously. CSPM tools detect new misconfigurations as they are introduced, enabling rapid remediation before they are exploited. Some CSPM platforms offer auto-remediation for low-risk findings, though this capability requires careful scoping to avoid disrupting legitimate configurations.

CSPM coverage should extend to identity and access management configurations, not just resource configurations. IAM findings: unused access keys, overly permissive policies, MFA not enabled on privileged accounts, root account usage: are among the highest-risk findings in cloud environments and should be prioritized in any CSPM deployment.

CWPP: Runtime Threat Detection Across Workload Types

Cloud Workload Protection Platforms extend security coverage to running workloads: containers, VMs, and serverless functions. Where CSPM addresses configuration, CWPP addresses runtime behavior. The combination of the two provides detection across both the static configuration plane and the dynamic execution plane.

CWPP platforms typically integrate with the host OS, the container runtime, and the cloud provider APIs to collect telemetry. This telemetry is analyzed against behavioral baselines and threat intelligence feeds to detect anomalies: unusual network connections, unexpected process execution, file integrity violations, privilege escalation attempts. Effective CWPP deployment requires tuning to reduce false positive rates in environments with legitimate dynamic behavior.

Multi-Cloud Unified Visibility

Enterprises operating across multiple cloud providers face a fragmentation challenge. Each provider has native security tooling with provider-specific data models, APIs, and consoles. Security teams managing multi-cloud environments without a unified visibility layer spend significant time correlating findings across disparate tools, creating gaps and delayed response.

Unified SIEM and SOAR platforms address this by normalizing telemetry from cloud-native sources, CSPM tools, CWPP platforms, and endpoint agents into a common schema. SIEM correlation rules can then detect attack patterns that span multiple cloud environments: lateral movement from AWS to Azure using compromised credentials, for example. The unified visibility layer is not optional for mature multi-cloud security operations; it is the platform on which effective detection and response depends.

Cloud Identity Risk and Attack Path Analysis

The single largest cloud-security blind spot in most environments is not a missing patch or a misconfigured bucket; it is the graph of permissions. Entra ID service principals, AWS IAM roles, GCP service accounts, and Kubernetes service accounts interconnect into a web of inherited, federated, and over-permissioned identities that no human can hold in their head.

Modern cloud security platforms now build a continuous graph of every identity, every permission, every resource, and every trust relationship across the environment. The graph answers the question that matters: given a compromised identity, what is the shortest attack path to the crown-jewel data store, the production RBAC role, or the code-signing key? The platform scores the paths, ranks them by risk, and surfaces the five or ten that actually need mitigation this week, not the 40,000 raw findings that a traditional scanner would dump into a ticket queue.

In practice, attack path analysis is what turns a misconfiguration report into a decision. A public S3 bucket with no sensitive data is noise. A public S3 bucket reachable from an over-permissioned Lambda that assumes the role used by your CI pipeline is an actual intrusion path. Those two findings carry the same CVSS score. Only a platform that understands the graph can tell them apart.

Code to Cloud: The Same Finding, Everywhere It Lives

A single vulnerable package, say a Log4j variant bundled into a base image, appears in at least five places inside most enterprises: the Git repository that defines the Dockerfile, the CI pipeline that builds it, the container registry that stores the image, every running pod that uses it, and the IaC template that deploys it. Siloed tools find the vulnerability five times in five systems, and produce five tickets, none of which correlate.

A code-to-cloud approach traces the same finding end to end. The PR review, the CI gate, the registry scan, the Kubernetes admission control, and the runtime alert all share the same identifier and the same remediation plan. A fix merged in Git becomes a closed finding in production without a human manually reconciling tickets across platforms.

This is how shift-left stops being a slogan. The developer sees the issue in the PR, on the branch they were already working on, with a one-line remediation. The SOC sees it disappear from runtime without any ticket-pushing.

Agent and Agentless, Chosen Per Workload

Full runtime defence requires a workload-resident agent for VMs, long-lived containers, and production-critical compute. Agentless scanning (snapshot-based analysis of cloud-provider APIs and disk images) is faster to deploy, covers ephemeral workloads that an agent cannot reach in time, and is essential for shadow-IT discovery.

The right platform does both. Agentless runs continuously against cloud provider APIs to map every running workload, misconfiguration, exposed secret, and vulnerable package. Agents deploy selectively to the workloads where runtime detection justifies the operational overhead. The same data lake ingests both. The analyst sees one incident, not one incident per data source.

DevSecOps: Shifting Security Left Without Slowing Down

Security integrated into the CI/CD pipeline catches vulnerabilities when they are cheapest to fix and least likely to reach production. The shift-left model requires security tooling that fits into developer workflows: fast scan times, IDE integration, clear remediation guidance, and exception management processes that do not create operational bottlenecks.

Infrastructure as Code scanning brings security controls to Terraform, CloudFormation, ARM templates, and Helm charts before they are applied. Tools like Checkov, KICS, and tfsec analyze IaC files against security policy rules and surface findings in pull requests, where developers can address them before merge. Secret scanning prevents credentials from being committed to source control: a pervasive problem that has caused numerous significant incidents.

The key to effective DevSecOps is making security findings actionable for developers. Findings with clear severity ratings, remediation examples, and links to documentation are addressed. Findings that generate alert fatigue without actionable context are ignored. Security teams that instrument CI/CD pipelines without investing in developer experience typically find that their tools are disabled or bypassed within months.

Norwegian Cloud Context: Compliance and Sovereignty

Norwegian organizations operating in cloud environments face specific regulatory obligations. GDPR requires that personal data transferred outside the EEA meet adequacy standards or be protected by appropriate safeguards. Cloud providers with Norwegian regions: Azure Norway East and Norway West, in particular: enable data residency within Norway, satisfying the most stringent interpretations of data localization requirements.

But data residency addresses only one dimension of compliance. GDPR Article 25 (Data Protection by Design) and Article 32 (Security of Processing) impose technical and organizational requirements on how data is processed and protected. Cloud workload security controls: encryption at rest and in transit, access logging, breach detection, and incident response capabilities: are the technical implementation of these obligations. NIS2, which Norway has committed to implementing, extends these obligations to operators of essential services and important entities, with significant penalties for non-compliance.

Sovereign cloud requirements for Norwegian public sector organizations and critical infrastructure operators are increasingly driving demand for configurations that minimize dependency on cloud provider employees outside Norwegian or EEA jurisdictions. This includes customer-managed encryption keys, restricted support access configurations, and audit logging of all administrative actions by cloud provider personnel.

ZeroSubnet's Cloud Security Approach

ZeroSubnet provides comprehensive cloud workload protection for Norwegian and international organizations, combining CSPM continuous posture management, CWPP runtime threat detection, and DevSecOps integration into a unified managed service. Our XSOC (Extended Security Operations Center) provides 24/7 monitoring across cloud-native workloads, with Norwegian analysts who understand both the technical threat landscape and the Norwegian regulatory context.

Our cloud security engagements begin with a posture assessment that establishes the current state across IAM, network configuration, workload configuration, and data protection controls. We then implement a prioritized remediation roadmap, deploy monitoring and detection capabilities, and integrate security into the customer's CI/CD pipelines. Ongoing managed detection and response ensures that emerging threats are identified and contained before they become incidents.

For organizations operating in Azure's Norwegian regions or evaluating Norwegian data residency requirements, ZeroSubnet provides advisory services on sovereign cloud configurations and GDPR compliance in cloud environments. We understand the regulatory landscape and the technical controls required to meet it.

Contact ZeroSubnet to discuss your cloud workload protection requirements and learn how our managed cloud security services can reduce your risk exposure without adding operational burden to your engineering teams.