Cloud-native applications that are based on new types of infrastructure such as containers and serverless platforms are being rapidly adopted by organizations worldwide. While cloud-native applications deliver compelling benefits such as elastic scalability, unmatched resilience and rapid development velocity, they also raise challenges.
Cloud-native applications have a huge number of moving parts and are based on short-lived infrastructure elements that are here one minute and gone the next. This raises operational and maintenance challenges, but above all, it creates security concerns. Cloud-native security requires new approaches, strategies and tools. In this article, I’ll cover a few tips that can help you improve security for your organization’s cloud-native portfolio.
What Is Cloud Native?
Cloud-native applications are built for the cloud, and oftentimes the entire software development life cycle—development, deployment, testing and updating—happens in a cloud environment. “Cloud” isn’t limited to the public cloud. It can mean a hybrid cloud with remote and local resources or a multi-cloud architecture with more than one cloud provider.
The Cloud Native Computing Foundation (CNCF)’s definition identifies three tools that should be used for cloud-native computing. These are containerization, a microservices architecture and dynamic orchestration. Containerization means that software is bundled with its dependencies, thus making it portable and scalable. Dynamic orchestration involves using tools like Kubernetes to manage containers in the cloud. And the microservices architecture is responsible for optimizing resources. Containers can be substituted by serverless functions, another common flavor of cloud-native computing.
Cloud Native Security Challenges
Cloud-native applications pose major challenges for infrastructure and application security. Here are a few of the key challenges.
Numerous Entities to Secure
DevOps and infrastructure teams leverage microservices to run cloud-native applications. In the past, multiple processes or software functionalities would run on one virtual machine. Now, each process or capability is packaged as a separate container or serverless function. Each entity is vulnerable to compromise and needs to be protected throughout the development lifecycle.
Diverse Architecture Patterns
Cloud-native systems can encompass a wide range of public and private clouds, cloud services and application architectures. Each architectural pattern might have different vulnerabilities and security requirements. Security teams are required to understand this complex attack surface and find solutions for securing each different architecture.
Environments in Flux
Public and private cloud environments are constantly changing. Rapid software release cycles mean that every component of a microservices application might be updated daily. In addition, the adoption of practices like immutability and infrastructure as code (IaC) means that applications are constantly torn down and re-created. Security teams can find it difficult to secure these deployments without slowing down the release cycle.
How to Secure Cloud Native Applications
There are several ways to secure cloud-native applications. These include shifting security left, applying perimeter security at the function and container level, enforcing minimal roles and privileges, securing application dependencies and leveraging shared responsibility for security.
Shift Security Left
Many companies still rely on existing security tools that cannot handle the speed, size and dynamic network environment of cloud-native applications. Adding serverless features makes the infrastructure more abstract, making the problem worse.
Cyber attackers look for vulnerabilities in containers and serverless function code as well as misconfigurations of cloud infrastructure to access entities that contain sensitive information, use them to escalate privileges and compromise other entities.
Another part of the problem is that organizations use CI/CD tools (e.g. Jenkins, Azure DevOps and Bamboo) to continuously develop, test and release applications. When using containers to deploy cloud-native applications, developers use base images retrieved from local storage or public repositories but often without checking if those images contain security vulnerabilities.
One solution is to provide your security team with tools to prevent untrusted images in your CI/CD pipeline as well as mechanisms to avoid security issues in code before it is deployed to production. By scanning for image vulnerabilities, secrets and malware early in the development process, developers can participate in enforcing security standards.
Apply Perimeter Security at the Function and Container Level
In serverless applications, the system is broken into multiple, callable components that accept event-driven triggers from different sources. This gives attackers a larger variety of targets and many more vectors for malicious activity.
One important practice is to use API and application security tools built for a cloud-native environment. Beyond that, the general approach is to enforce perimeter security at the function level—identifying functions that are triggered by a different source than usual and monitoring for anomalies in event triggers.
In containerized environments, it is important to address security at multiple levels—the orchestrator control plane, physical hosts, pods and containers. Security best practices for orchestrators like Kubernetes include isolating nodes, limiting and monitoring traffic between containers and using third-party authentication for the API server.
Minimal Roles and Privileges
There are numerous and frequent interactions between cloud-native resources. The ability to assign a unique set of permissions to each serverless function or container provides a great opportunity to enhance security.
When you run IAM on a per-function basis or define granular permissions for containers in a cluster, you can use those access controls to enforce security. Take the time to create a minimal role or set of permissions for each function or container. This ensures that if an element in the cloud-native architecture is compromised, it will cause minimal damage and prevent privilege escalation to other components.
Secure Application Dependencies
Serverless functions and application code often include packages with dependencies that are retrieved from repositories like npm or PyPI.
To protect your application's dependencies, you need automated tools that include a comprehensive database of open-source components and their vulnerabilities. You also need cloud-native orchestration tools that can trigger application security activities during the development process. By running these tools continuously, you can prevent the inclusion of vulnerable packages in a function or container running in production.
Shared Responsibility for Security
Build close partnerships between developers, DevOps and security teams. Developers are not security experts, but they should be educated in security practices and ensure they code securely. Security teams should become aware of how applications are developed, tested and deployed as well as which tools are used in the process so that they can help add security to these processes in an effective manner.
Cloud native requires a variety of ways to manage how organizations manage security and development, so it's important to close the gap between different teams as soon as possible. Cloud-native adoption is a rare opportunity for an organization to facilitate a cultural shift towards collaboration and shared ownership.
This article provided two definitions of cloud native and explained cloud-native security challenges including the large number of entities to secure and the constant flux of environments and architectures. The article also presented several best practices that can help you improve security in cloud native environment:
- Shift security left to avoid problems before they reach production
- Apply perimeter security at the function and container level
- Assign minimal roles and privileges to entities in a cloud-native application
- Secure your application dependencies
- Encourage shared responsibility for security between dev, ops and security
Hopefully, these insights and best practices will help you make a safe and secure transition to a cloud-native model.
Editor’s Note: The opinions expressed in this guest author article are solely those of the contributor, and do not necessarily reflect those of Tripwire, Inc.