Securing Cloud-Native Applications

Editor's Note: The following is an article written for and published in DZone's 2021 Application Security Trend Report.

Organizations are rapidly embracing cloud-native design patterns to modernize their business operations and enable faster time to market. Cloud-native architecture combines technologies like microservices, containers, automated CI/CD pipelines, container orchestration, unified observability, and cloud infrastructure. However, modern-day cloud computing services face security risks like data breaches, application vulnerabilities, account hijacking, insecure APIs, malicious insiders, data loss, denial of service, and insufficient credential management.

To protect against these threats, organizations should adopt a zero-trust model for their data and services, as well as embrace the DevSecOps movement to integrate security practices throughout their software development lifecycle (SDLC). Enterprises are using container technologies like Docker to simplify the packaging and deployment workflow of their cloud-native applications. Kubernetes is a popular container orchestration system for automating containerized application deployment, scaling, and management.

Adopting DevOps principles enables teams to deploy and release features rapidly, but it also introduces challenges to the security of your cloud-native applications. Hence, introducing security practices into DevOps is required.

This article will:

• Explain the four Cs of cloud-native security
• Overview cloud-native security challenges
• Showcase security considerations for cloud-native applications
• Explain how to integrate security into your CI/CD pipeline

Four Cs of Cloud-Native Security

The four Cs of cloud-native security are cloud, clusters, containers, and code. Each layer, as seen in Figure 1 on the next page, benefits from the outer security layers, with the code layer built on top of the cloud, cluster, and container layers. Let’s briefly go through the recommendations at each layer to secure your architecture:

• Cloud – It is the foundation of all security layers, and every cloud provider (like AWS, Microsoft Azure, Google Cloud, IBM Cloud) provides infrastructure security for the running workloads.
• Clusters – The primary security concerns in this layer are RBAC authorization, secrets management, pod security policies, and network policies, and Kubernetes is the standard operating tool.
• Containers – The security postures recommended in this layer are container vulnerability scanning, image signing, and prohibiting privileged users.
• Code – Organizations have the most control over this layer and can implement security recommendations like performing static code analyses, adopting DevSecOps practices, and making security part of the CI/CD pipeline.

Figure 1: The four Cs of cloud-native security

Cloud-Native Security Challenges

With organizations embracing a remote work model due to the COVID-19 pandemic, the need to secure data and systems has become more critical than ever before. The “Zero Trust” security model can improve your organization’s security posture in general, especially if they plan to adopt a mobile workforce or hybrid workspace environment. The basic principle is to avoid blindly trusting everything within the security parameter (corporate network) and to always authenticate and authorize every user, application, and device that tries to access the network — whether internal or external to the organization.

The key technologies and principles to build zero-trust-based architectures are:

• Multi-factor authentication
• Identity and access management
• Visibility into device inventory
• Firewall management
• Data classification and encryption
• Least privilege access
• Continuous network traffic monitoring

This is an excerpt from DZone's 2021 Application Security Trend Report.

For more:

Read the Report

Cloud-Native Application Security

Containers make it easy to package and deploy the runtime dependencies of your application and help resolve configuration management issues between your development and production environments. However, containers are transient and generally have a short life span, making container security challenging compared to traditional security mechanisms for threat detection and vulnerability scanning.

Container Security

Out of the box, containers provide some level of isolation and security, but at the same time, they also introduce a set of security concerns like kernel exploits, denial of service attacks, poisoned images, container breakouts, and compromised secrets. Reducing the container attack surface is critical since issues in one container can potentially impact other instances running on the same host. Applying the principle of least privilege and having restrictive user access to containers are good practices. A secret management solution is required to store credentials securely and allow the containers to access sensitive data during operation.

In addition, container images are immutable, so any vulnerability in the container image will persist for the life of the image. Therefore, you need to ensure that the images are regularly scanned for vulnerabilities as part of your CI/CD pipeline, updated with the latest patches, and pulled from trusted registries. When running your cloud-native applications in a containerized environment, you need complete visibility into your cluster configuration and to have monitoring in place.

Shared Responsibility Model for Security

In the public cloud, security is a shared responsibility between the cloud service provider and its customers. The differentiation of responsibility can be viewed as security “of” the cloud vs. security “in” the cloud. The cloud provider protects the overall infrastructure where the services are running and takes care of the operational concerns in the physical and network layer. On the other hand, customers are responsible for their business logic, including the application code and data layer protection.

Figure 2 illustrates Microsoft’s shared responsibility model, including areas of responsibility between the customer and Microsoft for workloads running on-premise and in the cloud.

Figure 2: Microsoft's shared responsibility model

Automating Cloud-Native Security

The DevOps methodology focuses on increasing collaboration and transparency between development and operations processes. However, in the pursuit of quick time to market, security practices must not be neglected and pushed further downstream in the pipeline. This is where DevSecOps comes into the picture, incorporating operations and security measures earlier in the development cycle.

Shift-Left Security Strategy

Shifting security left in the development process is essential because you don’t want security to be an afterthought. Instead, you should design and build systems with security top of mind. It is expensive and time-consuming to identify and fix security vulnerabilities in production, so the goal of shifting security left is to implement security practices and perform security testing during the development process — and not just before deployment to production. Your DevOps pipeline should allow you to deploy software with quality and speed while also adhering to security best practices.

Most vulnerabilities are introduced at the application level, and an attacker can compromise your system if your application contains vulnerabilities. Static application security testing (SAST) and SAST tools enable you to scan your entire codebase and execute security-related rules to detect vulnerabilities like SQL injection, cross-site scripting, denial of service, and code injection issues. In addition, as part of the continuous integration workflow, you can perform static code analysis for every code commit and implement automated vulnerability detection and compliance reporting.

Injecting Security Into CI/CD Pipelines

Integrating security controls into your automated pipelines, as seen in Figure 3, is key to successfully delivering high-quality software. The DevOps pipeline has the required permissions to deploy changes into your environment, so you must have stringent security guardrails around it. Developers can leverage several open-source and commercial security tools for their CI/CD pipelines. The goal is to identify security issues early, and low friction measures like following secure coding practices, the peer review process, and performing static code analysis are easier to implement.

If you are using open-source software or third-party libraries, you should have tooling in place for vulnerability management and threat detection. Implementing a lightweight penetration test in your pipeline helps enhance the security posture — for example, a dynamic application security testing (DAST) tool like OWASP ZAP acts as a security gate before deploying code to production. Along with scanning your containers, consider scanning your infrastructure code before deploying to the cloud.

Figure 3: Building security into the DevOps pipeline

Conclusion

With the cultural shift of building security into DevOps, development teams have an additional responsibility to automate application security testing and integrate it into the release pipeline. Training development teams on security principles and best practices can help bridge the knowledge gap. In addition, development teams working closely in collaboration with IT security teams can help both mitigate security vulnerabilities earlier in the SDLC and achieve the shift-left concept in the context of application development and security.

The Open Web Application Security Project (OWASP) is a non-profit global community that promotes application security mechanisms. It is highly recommended that developers working in the cloud-native space acclimate themselves with the OWASP Top 10 application security vulnerabilities, how hackers exploit them, and methods to eliminate these risks. Most of these vulnerabilities — like code injection, sensitive data exposure, broken authentication, security misconfigurations, cross-site scripting, and insufficient logging/monitoring — can be addressed with secure coding practices and following a stringent code review checklist.