Cloud-native applications increase development efficiency and flexibility but they impose additional security requirements. To fully protect your users, you must secure every part of your infrastructure, from your cloud environment down to your code.
In this article, you’ll learn how to use the 4C model to consistently enforce security at all layers.
We will cover:
Cloud-native applications are systems that have been specifically designed to run in cloud environments. Whereas legacy apps often need workarounds before they’re suitable for cloud deployment, cloud-native solutions are ready to take advantage of technologies such as container orchestration, auto-scaling, and burstable compute.
Furthermore, cloud-native apps are backed by DevOps processes that promote rapid iteration and continual improvement. They facilitate fast-paced delivery to production environments and integrate with observability suites to supply detailed operational information to infrastructure teams.
Cloud-native security encompasses several concepts that together form a strategy for protecting cloud-native applications. Although security has always been critical for every application, cloud-native demands a new model that’s capable of mitigating threats without impeding DevOps efficiency.
A cloud-native approach to security is builds on defense in depth and shift left principles to imbue threat management into your infrastructure and development processes. Moreover, teams should share responsibility for security to maximize overall expertise and avoid siloing of knowledge.
The theory is easy to conceptualize, but organizations often struggle to put it into practice. 4C is a concrete implementation of cloud-native security that you can use to secure your workloads.
4C is a security model for protecting cloud-native applications running in containerized environments such as Kubernetes. It defines a layer-based approach where each layer builds upon the defenses of the previous one. Thinking in terms of 4C highlights how weaknesses in one of the layers can cause any of the others to become compromised.
The model’s name derives from the inclusion of four different layers, each a single word beginning with the letter “C.” These are Cloud, Cluster, Container, and Code.
1. Cloud
The cloud is the foundational layer of any cloud-native deployment. It underpins everything else, including the clusters and container environments that you launch your applications into.
Compromising one of your cloud providers gives an attacker direct access to your infrastructure. Consequently, it’s vital you follow security best practices to protect your accounts and lessen the potential impact of a breach:
Stick to the principle of least privilege
Create as few user accounts as possible, each with the minimum set of permissions required for its role. This reduces the risk that lost or stolen credentials could be misused to perform sensitive actions. Similarly, you should avoid assigning too many permissions to your roles, as this has the same consequences as over-privileged user accounts. Keep your total role count small to enhance auditability and help you analyze who can perform each action in your system.
Lock down network access
Network interactions between your resources should default to blocking all communications. This will help stop attackers moving laterally through your infrastructure.
Ensure data is encrypted everywhere, both in transit and at rest
Comprehensive security and privacy protections depend upon data always being encrypted, whether it’s transiting through a network or stored in a database. Data remains sensitive whether it’s stored on a device or only transmitted to it.
Follow the platform-specific guidance from your provider
Public cloud providers such as AWS, Azure, and Google Cloud publish their own guidance for securing accounts and avoiding common pitfalls. Refer to this documentation each time you start using a new service.
Look for misconfigurations and default settings
Relaxed default settings and configuration errors during provisioning can be exploited by attackers. Regularly review your environment and disable any features that aren’t being used.
Enable audit logs so you can track changes
Recording when cloud resources are created, modified, and removed allows you to identify the effects of any successful attacks.
Once you’ve secured your cloud infrastructure, you can begin to focus on the resources within it.
2. Cluster
Clusters are the next 4C layer. Distributed environments such as Kubernetes and OpenShift add unique security requirements. Similarly to your cloud provider, clusters sit above your services and are an attractive target. A cluster-level breach gives attackers access to all your apps.
Read more about Kubernetes security.
To secure this layer, you should use the security capabilities of orchestrators like Kubernetes to tighten up your clusters:
Use RBAC to limit user access
RBAC controls let you make policy-based authorization decisions to determine whether a given user can perform an action in the cluster. Set up a different RBAC user for each integration you add, so that theft of one set of credentials doesn’t compromise other services.
Enable encryption for secrets at rest
Kubernetes doesn’t automatically encrypt secrets data. Sensitive values such as API tokens and certificates could be exfiltrated if an attacker breaches the physical environment that hosts your cluster.
Isolate the control plane to prevent illegitimate access
The cluster control plane should be isolated from external networks to lessen the risk of speculative attacks. Place your cluster behind a firewall that blocks Kubernetes API access from unauthorized clients.
Secure cluster Nodes
The Nodes in your cluster should be kept updated with kernel patches and new operating system packages. Dedicate your Nodes to Kubernetes to prevent vulnerabilities in other workloads from being used as a foothold to reach your cluster. You should also enable authentication for the Kubelet worker process APIs to prevent public control of your Node.
Setting up cluster protections creates a safer environment to deploy to. The security of your individual containers still matters though, because weaknesses could be exploited to attack neighbors in the same cluster or cloud.
3. Container
Container security comes in two forms: image-level security, and runtime security when you start your containers. Both areas need a proactive security approach to prevent vulnerabilities from being added to your images and exposed in production environments.
Start with a secure base image
Build your images upon hardened bases to reduce the risk of outdated or insecure packages being included. Bloated base images will increase the size of the build output without adding any benefits. For security-critical workloads, assemble your image’s filesystem from scratch so you know exactly what it includes.
Scan for vulnerabilities
Pass your container images through a vulnerability scanner before you deploy them into your cluster. You can perform this step as part of your CI/CD pipeline. It’ll ensure that images harboring newly discovered CVEs aren’t silently pushed into production.
Use image signing
Adopt zero-trust principles to increase your security. Don’t assume anything is as it appears, including the identity of your container images. Signing images with a digital signature lets you verify their integrity, preventing spoofed artifacts from reaching your cluster.
Configure Pod-level security features
Use Pod security contexts to reduce the Linux kernel capabilities available to your containers. This prevents compromised processes from running privileged actions on the host, which could lead to a container or cluster breakout. Set up Pod security admission rules to reject Pods that don’t meet your security requirements.
These techniques maximize the isolation that containers provide. They enforce a strict perimeter between different containers and the host platform.
4. Code
Cloud-native security is also impacted by your application’s code. Insecure development practices can be exploited to string together increasingly complex attacks.
In a worst-case scenario, attackers might be able to write to a container’s filesystem or run arbitrary commands within it. When combined with a zero-day vulnerability in a container runtime, they could break out of the container to access Nodes, clusters, and cloud resources.
You can mitigate these risks by shifting security left so it’s integrated into your development process:
Perform Static Application Security Testing (SAST) and Dynamic Application Security Testing (DAST)
SAST and DAST are automated testing techniques that uncover vulnerabilities in your system. SAST inspects your source code without executing it. It can spot common issues such as unsanitized values and insecure cryptography. DAST performs penetration testing against a live deployment of your service, allowing it to simulate user flows and discover runtime failures.
Audit your software supply chain to identify and remove vulnerable dependencies
Supply chain security has been made topical by high-profile real-world attacks such as the SolarWinds incident. Auditing your supply chain keeps you protected against this kind of threat. You can generate SBOMs to enumerate all the dependencies in your project, then remove any that are unused or no longer supported.
Scan for hardcoded secrets
Developer oversights are another cause of security issues. Unintentionally committed secrets such as API tokens become a permanent fixture of your source. They could be leaked anywhere your code is consumed, such as in CI/CD job logs or within container images. Use automated secret scanners to detect problem commits before they’re merged.
Ensure all changes pass through a consistent code review stage
Combining automated checks in CI/CD pipelines with manual code review gives you the best chance of spotting and resolving vulnerabilities before they reach production. Set up guardrails in your source control platform so code can’t be merged unless it’s passed all pipeline stages and received approval from relevant code owners.
To learn more, check out CI/CD security best practices.
Educate developers on secure coding practices
Don’t expect developers to automatically write secure code. Expectations should be clearly documented so your security standards can be met. Educate developers on why the baseline has been set and what they should do to meet it. You can use references such as OWASP’s Secure Coding Practices guide as a starting point.
Following these best practices during development will improve your system’s security at the source-code level. You can then containerize your project knowing it’s safe to use in production, with a lower risk of unknown vulnerabilities being present.
4C can be managed using cloud-native security platforms that provide visibility into threats (such as vulnerabilities and misconfigurations) with automated remediation options.
These platforms, often termed Cloud-Native Application Protection Platforms (CNAPP), consolidate security mechanisms into one cohesive interface that administrators, operators, and security experts can utilize. CNAPPs typically include features for threat scans, network monitoring, IaC misconfiguration detection, access control management, and environment monitoring. They may also allow you to conduct penetration tests against your infrastructure to uncover unsafe code paths.
Tools are only one part of good cloud-native security; your approach to the problem is also critical. Some proven strategies include:
- Shift Left – Shift security left to incorporate it into the development process. Security should be deeply integrated with your product, not bolted on late in development.
- Shared Responsibility – Security isn’t the preserve of security experts. Developers can also contribute; they should be conscious of how their decisions affect security. Similarly, product managers must also recognize how their requests impact the system’s security posture.
- Defense in Depth – Adopt multi-layered security methodologies such as 4C to increase protection in all parts of your stack. Any asset that could be compromised, or which permits access to other assets, should be monitored for security issues.
- Holistic Multi-Cloud Security – Cloud-native systems often comprise hundreds or thousands of services that may run across several different clouds. This distributed sprawl means it’s essential you choose tools and platforms that can index and prioritize threats across your entire infrastructure inventory.
For the greatest protection, you should incorporate all four of these components into your cloud-native security plan.
Looking for a solution to support 4C and cloud-native security? Here are a few popular choices.
- Snyk – Snyk is a tool that scans for code vulnerabilities and presents automatic remediation suggestions. It can detect code issues, IaC misconfigurations, and vulnerabilities in container images.
- Falco – Falco is a security platform that’s purpose-built for cloud-native environments. It uses Linux kernel data to detect abnormal system activity in real-time. Falco can also spot potential compliance violations.
- Orca – Orca Security’s platform finds and prioritizes risks across all cloud environments. It can detect infrastructure issues, find emerging vulnerabilities, and identify unintentionally exposed assets such as personal information.
- Check Point CloudGuard – Check Point’s CloudGuard platform is a dedicated CNAPP that works at the cloud, network, and application level. It supports multi-cloud scenarios and is designed to integrate into DevSecOps workflows.
You can use these tools to support the implementation of the 4C model at each of its layers.
The 4C model is an holistic approach to cloud-native security that acknowledges the risks associated with both infrastructure and source code. It emphasizes that your overall security posture is the sum of multiple components, ranging from the integrity of your code to your methods for protecting cloud provider accounts.
While cloud-native development brings increased flexibility and reduced time-to-market, it also carries new challenges for security teams. Benchmarking security across the 4Cs of Cloud, Cluster, Container, and Code isn’t guaranteed to defend against every threat, but it gives you the best chance of spotting problems before bad actors find them.
Security is everyone’s responsibility, and with the continuous modernization of infrastructure, the importance of it cannot be overstated. Spacelift’s number one priority is and always will be security. With our product, you not only minimize the chances of unauthorized access, but you also get improved resilience and reliability. If you want to see how flexible our product is in action, you are welcome to create a free account or book a demo with one of our engineers.
The Most Flexible CI/CD Automation Tool
Spacelift is an alternative to using homegrown solutions on top of a generic CI. It helps overcome common state management issues and adds several must-have capabilities for infrastructure management.
