Cloud-native security involves incorporating security into an organization’s overall cloud-native application development strategy. This approach addresses changes to the infrastructure, teams, and processes required to build secure applications. Cloud-native security thus emphasizes application security to ensure the detection and remediation of vulnerabilities in a cloud environment.
Cloud-native security requires a holistic approach that bakes security into the software development life cycle (SDLC). A security platform can help developers deliver designs based on cloud-native principles—the development team is responsible for providing secure code. Every design decision should take cloud-native architecture into account to ensure the application is fully cloud-native.
There are several challenges to securing cloud-based infrastructure. Developers can deploy infrastructure dynamically with infrastructure-as-code (IaC) configurations, typically writing the infrastructure code simultaneously with the application code. Developers can integrate security tools into their workflows to provide insights and advice for remediation. For example, they might enable local testing with command-line interface (CLI) tools and make the security data visible in the integrated development environment (IDE).
This is part of an extensive series of guides about security testing.
In this article:
To help you organize your cloud-native security strategy, you can divide the security infrastructure into four categories—the cloud layer, the container layer, the cluster layer, and the code layer.
The cloud layer consists of the infrastructure that runs your cloud resources. When you set up a server with a cloud service provider (CSP), the provider is responsible for most infrastructural security. However, you are responsible for configuring the services, securing your data, and overseeing security.
Typical security issues affecting the cloud layer include misconfigurations and automated attacks. Attackers can exploit misconfigurations resulting from error or neglect, such as unchanged default settings or weak access protection to the administration console. Attackers can also use automation to scan for vulnerabilities and launch attacks rapidly.
The container layer consists of container images, which may contain vulnerabilities that you can scan for. Organizations commonly overlook issues such as image security, the use of unknown sources, and weak privilege configurations. It is important to keep containers regularly updated to minimize exposure through known vulnerabilities. You should also scan and verify any application running in your containers.
Make sure any image used was built by a known source or came from a trusted registry. An image signing tool, such as Docker Content Trust (DCT), can help you ensure that container content comes from trusted sources.
Ensure that containers do not run with a privileged user account, so they do not have root access to the host machine.
Related content: Read our guide to container security
The cluster layer consists of the Kubernetes components making up the worker nodes and control plane. It is at this layer that you secure your Kubernetes workloads. Kubernetes components use encrypted communication, requiring TLS certificates to authenticate with each other.
The most critical component to protect is the kube-api-server, which is the main Kubernetes interface. By default, this server can only be accessed via HTTPS, although you can use a third-party identity provider to protect it further with authentication. Typically, organizations use customized role-based access control (RBAC) rules for API server authorization, so you can administer the cluster and its workloads without requiring Secure Shell access.
The code layer, also known as the application layer, provides the highest level of security control. You can restrict exposed endpoints, ports, and services to manage security risks. You should protect communication between both internal and external services using TLS encryption.
Typical security issues at the code layer include insecure code, insufficient risk assessments, and vulnerabilities in third-party software dependencies. You should use a static code analysis (SCA) tool to identify insecure code and ensure safe coding practices quickly. Regularly scan and test your applications to ensure resilience against attacks like cross-site request forgery (CSRF) and cross-site scripting (XSS).
Most cloud-native apps consist of third-party libraries or dependencies, which are often left unchecked by static analysis. You can use a software composition analysis tool like OWASP Dependency-Check to identify vulnerable dependencies.
Organizations typically implement a cloud-native security strategy that ensures security throughout the tech stack. Here are some examples of common cloud-native security strategies:
DevOps teams should work closely with security teams. Developers may not be security specialists, but they can learn about secure coding practices that complement the expertise of the security team. Likewise, security experts can learn about the tools and processes used to develop, test, and deploy applications, so they can help make them more secure.
Cloud-native security requires various means of managing development and security teams, operating in tandem with close communication. Shared responsibility and collaboration are part of the cultural shift that enables organizations to integrate security into the development process.
Read our ebook: A holistic approach to securing containers and cloud-native applications
Shifting security left is another important cultural shift, which often requires new security tools that can handle the scale and speed of the cloud-native application development environment. This approach focuses on applying security measures early in the software development process, such as vulnerability scans. Developers must ensure that the application code is secure before deploying it to production.
Another way to protect your infrastructure is to avoid serverless features. Attackers can exploit vulnerabilities in serverless function code and containers. They can also use cloud infrastructure misconfigurations to access sensitive data, escalate privileges, and move laterally.
You should avoid using untrusted container images in the CI/CD pipeline. The security team should check any images for vulnerabilities before developers can use them to deploy applications.
Read our guide to shift-left security
Application code often contains open-source dependencies found in repositories like the Python Package Index (PyPI). You can protect application dependencies using automated tools that leverage comprehensive vulnerability databases.
A cloud-native orchestration tool can help you maintain security during development by triggering application security actions. You can run such tools continuously to prevent the introduction of vulnerable dependency packages into containers and serverless functions that run in your production environment.
This approach, also known as multi-layered security, uses network monitoring to detect and remediate individual threats. The security team should monitor every layer of the network. You can use various tools and techniques to prevent and respond to attacks and establish contingency plans for successful breaches.
Organizations often apply a cloud-agnostic security approach to their multi-cloud models. A cloud-native security platform (CNSP) can help you manage security across multiple clouds from different providers. You create a single security strategy that incorporates best practices that multiple parties must follow—this helps simplify your cloud-native monitoring, disaster recovery, and compliance efforts.
Related content: Read our guide to cloud-native monitoring
Calico Enterprise and Calico Cloud offer several features for zero-trust workload security for cloud-native applications. These include:
Next Steps
What Are Cloud-Native Application Protection Platforms (CNAPP)?
A CNAPP is an end-to-end cloud-native security solution. It provides a central control plane that unifies all security capabilities to protect cloud environments, making your security cloud native. Understand the need for a Cloud Native Application Protection Platform (CNAPP), key benefits, and how it combines CASB, CWPP, and CSPM into one solution.
Read more: What Are Cloud-Native Application Protection Platforms (CNAPP)?
Cloud-Native Monitoring: Challenges, Components, and Capabilities
Cloud-native monitoring is unlike traditional application monitoring, because monitoring systems must deal with ephemeral objects that can be frequently created and destroyed, and distributed applications made up of multiple independent components. Understand why cloud-native monitoring is complex, the four key components of cloud-native monitoring, and how to select a monitoring solution.
Read more: Cloud-Native Monitoring: Challenges, Components, and Capabilities
Cloud Native Architecture: Pros, Cons, and Basic Principles
A cloud native architecture is an application architecture explicitly built for the cloud. Learn about the pros and cons of cloud native architecture that make applications more flexible, scalable, and resilient.
Read more: Cloud Native Architecture: Pros, Cons, and Basic Principles
Together with our content partners, we have authored in-depth guides on several other topics that can also be useful as you explore the world of security testing.
Authored by Bright Security
Authored by Bright Security
Authored by Bright Security
Get updates on blog posts, workshops, certification programs, new releases, and more!
