Scanning for Vulnerabilities in Cloud-Native Applications
Security has become very important for cloud-native applications. This article elaborates on the cloud-native security principles and how to implement them.
Join the DZone community and get the full member experience.Join For Free
On the road to embracing DevOps, many IT organizations still depend on traditional security practices, policies, and tools that were not built to withstand the modern cloud-native approaches of scaling and complexity. With less attention paid to security, organizations fail to transform themselves in this rapidly-changing digital world. Recent surveys and researchers have found how important security has become in the software development lifecycle that was may have been ignored for years as the “security team’s problem.”
The emergence of DevSecOps has helped organizations to shift security left, but is that enough? Organizations have barely started to understand the complexity and security threats associated with their cloud-native journey. It is highly recommended to use modern cloud-native best practices and tools to tackle vulnerabilities and threats found in the SDLC.
What is cloud-native?
Approximately ten years ago, the word cloud-native was coined by businesses like Netflix and Amazon. They leveraged modern cloud practices, tools, and technologies. For many companies, cloud-native means innovating, reinventing, transforming the way we do software development.
Cloud-native software applications employ microservices deployed within lightweight containers that use low-overhead orchestration, runtime, and networking services. Cloud-native applications leverage cloud compute frameworks and infrastructures and encourage speeding time-to-market.
These applications use modern cloud practices like immutable infrastructure, Infrastructure as Code (IaC), containers and container registries, service meshes, declarative, and APIs.
Image source: DZone
There are multiple steps a company can take to begin and progress on this journey. Cloud-native’s fundamental principles include scalable apps, resilient architectures, and the ability to make frequent changes.
Three phases to mention in the journey.
Phase I > Developer Focus > Container Adoption
Phase II > DevOps Focus > Application Deployment
Phase III > Business Focus (end-to-end)> Intelligent Operations
Example of a modern cloud-native application stack
Image source: The Linux Foundation
Fundamentally at the lower layer, you will have your typical access aspects of it, the load balancers, either your network load balancers or application load balancers. Then you have a large number of subnets where you have deployed all your hosts, on top of which we can actually deploy either managed or self-hosted Kubernetes: The Kubernetes orchestrator for our container deployments.
We also need storage, whether it's databases or cloud storage. So once we have all these artifacts, we deploy our container orchestrators. One of the main avenues through which we can leverage and configure and deploy applications on the orchestrator is using the orchestrator API.
The orchestrator exposes the API server and a very rich set of functionalities which the clients then leverage to perform various actions on the orchestrator. Now, the next aspect is that we want to make sure that we have isolation, and one of the aspects that are facilitated in a Kubernetes environment is using Name Spaces. These Namespaces will finally deploy the application pods. So, all these different artifacts are what comprise the new cloud-native application stack.
Why cloud-native security?
While shifting security “left” is getting huge attention these days, it is highly recommended to have security integrated throughout the software development life cycle, and having security checkpoints at each stage is considered more effective. Shift-left in security means prioritizing security very early in the development life cycle and making it (security) as everyone’s job. This way, any vulnerabilities that can impact the software delivery and bottlenecks in production can be prevented.
O’Reilly's survey on “How Companies Adopt and Apply Cloud Native Infrastructure” report of 590 security practitioners, DevOps managers, and CxOs from across the world found that Security and compliance barriers among the top challenges for cloud-native adoption.
Image source: HELPNETSECURITY
Cloud-native security addresses the security concerns involved.
Cloud-native security forces the point of re-focusing on security and shifting the security left in the SDLC. Cloud-native applications must be secured for a successful digital transformation journey. Thus cloud-native security ensures that vulnerabilities are detected, identified, and remediated at the right time in the SDLC. This is where we recall the DevSecOps approach, baking security throughout the software development life cycle.
Image source: DZone
Cloud-native security acts as a gatekeeper and a guard for all the security vulnerabilities that might enter your software flow.
4 C's of cloud-native security (with regards to Kubernetes)
Image source: Kubernetes.io
The cloud is regarded as the base of the security layers. Steps must be taken at the cloud level since developers cannot configure application security at the code level. It is all about running secure workloads in the respective cloud provider's environment.
After cloud, comes the cluster layer, and Kubernetes is considered as the de facto orchestration tool. When using Kubernetes, there are certain things to consider - RBAC, Pod security and network policies, secret management, logging, and monitoring.
This layer talks about container security management and best practices.
When the applications are built inside a container, there are certain security best practices to follow. First, avoid running privileged containers. Most applications don’t need root access to operate, besides for system containers like monitoring or logging agents. This should prevent an invader from getting root access to the container and access the host node.
The last C in the cloud-native security layer is code. Strengthening security into an application’s code is one of the best practices in DevSecOps.
It all starts with the source code. By catching security vulnerabilities early in the software development life cycle (SDLC), companies can save developers time, cost, and effort.
One best policy to restrict the vulnerabilities in your code is to use tools built just for this purpose - something like JFrog's Xray.
Cloud-native security approach
Image source: Checkpoint
A typical software development flow will have the following steps: Developer develops the code/software, tests locally in his/her machine, then commits code to the version control system used; the CI/CD tool takes the code, builds it, and then pushes it to the Docker compose which also builds a container utilizing images and packages from public repositories. And then places it into the registries; after the step of successful staging, the container proceeds to production. All these steps pose security risks at each point and hence must be taken care of.
The workflow might have code with vulnerabilities, libraries, and images downloaded from unknown sources, license-related issues, etc. Hence, as a DevSecOps best practice, it is recommended to have regular checkpoints at each stage of the development workflow along with the cloud-native security tools.
Google cloud has put up a great table of implied requirements for security in moving to a cloud-native architecture.
Image source: Google Cloud
Scanning for vulnerabilities in cloud-native applications
There will usually be many dependency layers in an application, from their code to production journey.
For example, when the application is written in Java, you may have Maven dependencies. The next step would be running this application on Linux, and then you will have dependencies in Debian repositories. The next is wrapping it in Docker because you want to have it on Kubernetes, and then you will have Docker repositories immediately. The Kubernetes universe will have repositories like Helm center and so on.
Cloud-native enterprises make use of a dedicated place to manage and store all these dependencies, binaries, and libraries, and it is Artifactory. It has all the dependencies and libraries from trusted sources. Using Artifactory makes it easy for developers to have a single source of truth while developing, and any dependencies can be easily scanned with this tool called Xray. Artifactory and Xray both are connected and hence feature a full-blown security tool when working with cloud-native applications.
Security has come a long way, and it is here to stay. While DevOps focuses on speed and agility, cloud-native security focuses on the security aspect throughout the cloud-based SDLC. Combining both speed and security, enterprises can easily achieve their desired digital transformation journey. With the increasing adoption of cloud-native principles, tools, and platforms, there is a chance for security risks, which can be mitigated using security tools and DevSecOps principles. Employ the best-in-class tools to detect and analyze vulnerabilities, have integrated security checkpoints across the SDLC, and make security everyone's job. Let's keep hackers and attackers away from our systems.
Published at DZone with permission of Pavan Belagatti, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.