Code, Container, Cluster, Cloud: The 4C’s Of Cloud-Native Security – Part 1

Containers and cloud-native design patterns gained popularity over the past years. More and more organizations use containers in production and adopt cloud-native practices and methodologies to get even more value from existing containerized applications and underlying technologies such as container orchestrators like Kubernetes.

In diesem Artikel:

Adopting and implementing cloud-native patterns and methodologies is one thing. Another important aspect is securing and hardening cloud-native applications. Securing cloud-native applications is an ongoing, time-consuming, and maybe a tedious challenge. Especially smaller teams may struggle with securing all aspects of their cloud-native application.

In this article, we will look at the 4C’s of cloud-native security. Those “C’s” represent the different layers where developers and DevOps teams have to ensure security best practices to meet overall security goals and pass corresponding gates before exposing cloud-native applications to their customers.

In the upcoming paragraphs, we will take a quick look at each of the “C’s” and learn some fundamentals about their idioms, characteristics, and tools.

Code Security

From a developer’s perspective, we should first talk about code security. All tools available to increase code security fall into one of the following categories:

  • Static Application Security Testing (SAST)
  • Dynamic Application Security Testing (DAST)
  • Interactive Application Security Testing (IAST)

Producing secure code should be top of every developer’s mind. This means we’ve should not just use proper libraries and frameworks to reduce or eliminate the risk of attacks like SQL injections, cross-site scripting (XSS), or others. Additionally, we should design public API surfaces and interfaces with care and ensure proper handling of edge cases or invalid arguments being passed to those entry points. However, even if we as developers follow these rules, we can’t be 100% sure that all aspects of our application are safe.


Fortunately, there are tools available that can assist here. SAST tools scan our source code for known types of vulnerabilities and anti-patterns. As developers, we can use SAST tools – like, for example, CodeQL or SonarQube – locally (i.e. in the developer’s inner loop). Being able to check your code almost instantly is beneficial because you can fix potential vulnerabilities immediately.

Most popular SAST tools allow seamless integration with existing continuous integration (CI) systems such as GitHub Actions or Azure DevOps pipelines. Invoking SAST during CI runs is important because merging code may introduce unexpected vulnerabilities.


When it comes to DAST, you can think of black-box testing because the DAST tools do not have access to your application’s source code. In contrast, a running instance of your application is examined. DAST allows you to detect misconfiguration and misbehavior, not just by mistakes accidentally made in source code but also introduced by inappropriate runtime environment configuration.

DAST will help you harden your application against well-known vulnerabilities listed by the Open Web Application Security Project (OWASP).


The third category of tools for securing the code of your cloud-native application is IAST. You can think of IAST as a combination of SAST and DAST, where your application is actively observed at runtime. However, DAST incident or vulnerability information is enriched with important contextual information (traces, source references). This means IAST tools typically consist of three parts.

  • First, there is a library (or a package) that you’ve to integrate with your application on the source code level.
  • Second, an IAST server component is often used to analyze, categorize, and report incidents.
  • Third, a scanner that observes your application from the outside. This typically takes environmental aspects into consideration.

Container Security

The next layer that should be secured is the container layer. For containers, you have to care about two different security aspects. First, you should build your custom container images with care. Not relying on a privileged user (root) is perhaps the most popular and prominent rule when it comes to authoring a good Dockerfile.

On top of that, your Dockerfiles should be checked for numerous rules. Fortunately, we do not have to memorize all those rules. Instead, we can use tools like dockle to scan a container image and get recommendations to optimize its Dockerfile.

Additionally, you should always check all of your container images for known vulnerabilities. By scanning your container images, you cannot just find vulnerabilities of your application or the framework and programming language you have used. You can even spot vulnerabilities in all components being part of the container image and even the underlying operating system used in the container. Again there are many tools available to do vulnerability scanning for container images. Quite popular tools are provided from AquaSecQualys, and Snyk (which is also seamlessly integrated with Docker Desktop and accessible via the docker scan command).

Last but not least, you should consider signing your container images. You can ensure your container images integrity and establish higher trust with signed container images because you can prevent the execution of unsigned container images.

Docker Inc provides some good documentation on setting up and working with signed container images. Just browse the official documentation and look for Docker Content Trust (DCT) to dive deeper.

Cluster Security

The third layer in cloud-native security is the cluster layer (or, to be more precise: Kubernetes). Kubernetes and its vibrant open source community offer a wide variety of concepts and tools that we can use to harden both the Kubernetes cluster itself and our application workloads running in the cluster.

From a Kubernetes cluster point of view, we must ensure proper authentication and authorization. In conjunction, AuthN and AuthZ are used to limit access to the cluster only to desired people and services. If you’re using Azure Kubernetes Service (AKS), you can configure seamless integration with Azure Active Directory (AAD). With this integration in place, you can use plain old role-based access control (RBAC) to enforce control cluster access.

On top of that, you should consider implementing NetworkPolicies. By adding NetworkPolicies to your Kubernetes cluster, you can lock down your containerized applications and stop unwanted network communication between your application components or between different applications running in the same shared cluster.

Another great example when it comes to cluster security is the use of custom admission controllers. In Kubernetes, we can use validating admission controllers to reject inappropriate requests sent to the Kubernetes API server. For example, you can use a validation admission controller to reject all privileged Pods.

These were just a few samples focusing on securing your Kubernetes cluster. Please consult the official Kubernetes documentation to dive deeper into securing and hardening your cluster and applications deployed to a certain Kubernetes cluster.

Cloud Security

Last but not least, we must take care of the surrounding cloud. Moving containerized applications to the cloud is easy. Cloud vendors simplify the onboarding experience to get more and more customers on their platform. However, securing those cloud infrastructures and continuously monitoring and responding to threats is time intensive and may become complex depending on the overall cloud footprint.

To harden and secure cloud infrastructures, teams typically use services from four different categories:

  • Security Information and Event Management (SIEM) hosting
  • Security Operations, Automation, and Response (SOAR)
  • Cloud Workload Protection (CWP)
  • Cloud Security Posture Management (CSPM)

SIEM analyzes activities and signals in an environment and distinguishes between regular and anomalous incidents. For anomalous incidents, SIEM alerts were generated. SOAR tools are used to react, automate and finally respond to anomalous incidents reported through SIEM alerts. Speaking about Microsoft Azure, Azure Sentinel addresses both SIEM and SOAR.

On the other hand, we have Azure Defender for Cloud (previously known as Azure Security Center), addressing both CWP and CSPM. It automatically monitors all security- and health-sensitive configuration of your Azure environment. Azure Defender for Cloud flags misconfigured services and provides its users with detailed recommendations on remediating them.

Additionally, users can integrate Azure Sentinel with Azure Defender for Cloud to respond quickly to insecure service configurations.


Separating responsibilities for securing your cloud-native applications according to the 4 C’s of cloud-native security helps define responsibilities and actionable work items. Often, each category comes with its own tools and tool vendors, which reflects in terms of licensing and legal discussions with those vendors. However, securing all aspects of your cloud-native application (and we did not even reference application layer security topics like OAuth 2.0 or OIDC in this post) is unfortunately often underrated or even ignored.

I think teams leveraging cloud-native technologies should care more about securing their workloads. Pushing some of the responsibilities to the left (towards developers) is generally good. Organizations must provide their teams with the necessary tools and licenses to ensure their products are secure and operated according to security best practices.

Mehr Artikel zu Cloud Native, Azure

Aktuelle Artikel, Screencasts, Webinare und Interviews unserer Experten für Sie

Verpassen Sie keine Inhalte zu Angular, .NET Core, Blazor, Azure und Kubernetes und melden Sie sich zu unserem kostenlosen monatlichen Dev-Newsletter an.

Newsletter Anmeldung
Diese Artikel könnten Sie interessieren
Cloud Native

Cloud Security: The 4C’s Of Cloud-Native Security – Part 5

In the last part of the article series on the 4C's of cloud-native security, we will look at securing the cloud environment itself. Although actual steps to harden your cloud infrastructure differ based on the cloud vendor and the services used to architecture your cloud-native application, many concepts and methodologies are quite similar.
Cloud Native

Code Security: The 4C’s Of Cloud-Native Security – Part 4

In this part of the article series on the 4C's of cloud-native security, we will take a closer look at code security. We will briefly inspect why code security is essential, why it should be addressed from the beginning, and why trends such as shift-left security are important aspects of overall security considerations.
Cloud Native

Cluster Security: The 4C’s Of Cloud-Native Security – Part 3

Securing the Kubernetes cluster (which may act as a runtime platform for several components of typical cloud-native applications) addresses one of the 4C's in cloud-native security. If you haven't heard about the 4C's of cloud-native security yet or want a quick refresher, you should read my corresponding introduction article.
Cloud Native

Container Security: The 4C’s Of Cloud-Native Security – Part 2

Securing the container images of your cloud-native application building blocks addresses one of the 4C's in cloud-native security. If you haven't heard about the 4C's of cloud-native security yet or want a quick refresher, you should read my corresponding introduction post.
Cloud Native

Ausführen von Containern in Azure Container Instances (ACI) direkt über die Docker CLI

Vor einigen Monaten haben sowohl Microsoft als auch Docker eine nahtlose Integration von Azure Container Instances (ACI) und Docker CLI angekündigt. Als Container-Enthusiast musste ich mich natürlich mit dieser Integration befassen. Ich habe es in verschiedenen Szenarien getestet, um zu sehen, wie es mich unterstützen und meine Produktivität steigern könnte.
Infrastructure as Code

Infrastructure-as-Code (IaC): Bicep und Terraform im Vergleich

Infrastructure as Code (IaC) ist eine wichtige Technik in der Automatisierung. Teams beginnen ihren Weg zu Cloud-Native oft so, dass sie alles automatisieren und die Infrastruktur ist hier keine Ausnahme. Die stetig wachsende Akzeptanz von Cloud-Diensten und die Digitalisierung sind nur einige Gründe, warum IaC-Tools wie Terraform so beliebt sind. Project Bicep ist hier ganz neu - eine neue Sprache, die erstellt wurde, um Azure Infrastruktur-Deployments als Code auszudrücken