On the path to adopting DevOps, many IT organizations are still reliant on traditional security practices, policies, and tools that cannot stand up to modern cloud-native approaches to scale and complexity. With less attention paid to security, companies are failing to change in this rapidly changing digital world. For many years these issues were the security team’s problem; Recent surveys and research highlight the importance of security in all phases of the software development lifecycle (SDLC).
The advent of DevSecOps has helped organizations shift security to the left, but is that enough? Organizations are only just beginning to understand the complexities and security threats associated with their cloud-native journey. Using modern cloud-native best practices and tools can help address vulnerabilities and threats across the SDLC.
What is cloud native?
About ten years ago, the term “cloud-native” was coined by companies such as Netflix and Amazon. They used modern cloud practices, tools and technologies. For many companies, cloud-native means innovating, reinventing and changing the way we do software development. Cloud-native software applications use microservices that are deployed in lightweight containers that use orchestration, runtime, and network services with low overhead. Cloud-native applications leverage cloud computing frameworks and infrastructures and promote accelerated time to market. These applications use modern cloud practices such as immutable infrastructure, infrastructure-as-code (IaC), containers and container registries, service meshes and APIs.
There are several steps a company can take to start and move forward on this journey. The basic principles of cloud-native include scalable apps, resilient architectures, and the ability to make frequent changes. There are three stages in the journey to mention.
Phase I> Developer focus> Container introduction
Phase II> DevOps focus> Application delivery
Phase III> Business focus (end-to-end)> Intelligent Operations
Basically, at the lower level, you have your typical IT access aspects – the load balancers, either your network load balancers or your application load balancers; then you have a large number of subnets that you’ve provisioned all of your hosts on, and on top of that, we can provision either managed or self-hosted Kubernetes, the orchestrator for our container deployments.
We also need storage, regardless of whether it is databases or cloud storage. Once we have all of these artifacts, we deploy our container orchestrators. One of the main ways we can consume, configure, and deploy applications on the Orchestrator is through its API. The orchestrator provides the API server and a variety of functions that clients then use to perform various actions on the orchestrator. Now the next step is to make sure we are isolated and one of the things that is made easier in a Kubernetes environment is the use of namespaces. These namespaces will eventually provide the application pods. So all of these different artifacts make up the new cloud-native application stack.
Why cloud-native security?
While the shift in security to the left is getting a lot of attention these days, security should be built into the entire software development lifecycle as a best practice. Having security controls at every stage is considered more effective. Moving left on security means prioritizing security very early in the development lifecycle and making it everyone’s responsibility. This avoids any vulnerabilities that could affect software delivery and cause bottlenecks in production. O’Reilly’s How Companies Adopt and Apply Cloud Native Infrastructure survey, interviewed 590 security professionals, DevOps managers, and C-level executives from around the world, found security and compliance barriers to be among the greatest challenges along the way Cloud natives include adoption.
Cloud-native security addresses these security concerns by moving security to the left in the SDLC and ensuring that vulnerabilities are detected, identified and remedied at the right time. This is similar to the DevSecOps approach; Baking security at every step in the software development lifecycle.
Cloud-native security acts as a gatekeeper and guardian for any security gaps that could intrude into your software flow.
Four Cs of cloud native security
Cloud infrastructure: The cloud is the basis of all security layers. Because developers cannot configure application security at the code level, security measures must be taken at the cloud level. It’s about running secure workloads in the environment of the respective cloud provider.
Cluster: After the cloud comes the cluster layer, in which Kubernetes is the standard orchestration tool. There are certain things to keep in mind when using Kubernetes – RBAC, pod security and network policies, secret management, logging, and monitoring.
Container security: At this level, container security management and best practices are important. When building applications in a container, a best security practice is to avoid running privileged containers first. Most applications do not require root access, with the exception of system containers such as monitoring or logging agents. This should prevent an intruder from gaining root access to the container and gaining access to the host node.
Code: The last “C” in the cloud-native security layer is code. Strengthening security over the code of an application is a DevSecOps best practice that starts with the source code. By identifying security gaps in SDLC at an early stage, companies can save time, money and effort. A best practice to limit the vulnerabilities in your code is to use code analysis and / or scanning tools that are specifically designed for this purpose.
A typical software development flow includes the following steps:
- The developer develops the code / software, tests locally on his / her machine and then passes the code to the version control system used;
- The CI / CD tool takes the code, builds it, and then submits it to Docker Compose, which also builds a container of images and packages from public repositories.
- It is then placed in the registers and goes to staging.
- Once the container has been successfully provided, it goes into production.
At each stage there are security risks that need to be addressed. The workflow may contain unsafe code with vulnerabilities. Libraries and images may have been downloaded from unknown sources; license-related problems, etc., may occur. As a DevSecOps best practice, use regular checkpoints at every stage of the development workflow along with cloud-native security tools. Google Cloud has a great table of implicit security requirements when moving to a cloud-native architecture.
Check for vulnerabilities in cloud-native apps
Typically, there are many layers of dependency in an application on its way from code to production. For example, if the application is written in Java, you might have Maven dependencies. The next step in the process could be to run the application on Linux, which introduces dependencies in Debian repositories. The next step is to package the app in Docker to run on Kubernetes and then you have Docker repositories to deal with. The Kubernetes universe will have repositories like Helm Center and so on.
Cloud-native businesses use a dedicated place to manage and store all of these dependencies, binaries, and libraries called the Artifactory. It saves all dependencies and libraries from trusted sources. Using Artifactory makes it easy for developers to have a single source of truth, and combining it with proprietary scanning tools can add comprehensive security auditing for cloud-native applications.
While DevOps methodologies focus on speed and agility, cloud-native security focuses on the security aspect across cloud-based SDLC. By combining speed and security, companies can easily continue on their desired path of digital transformation. With the increasing introduction of cloud-native principles, tools and platforms, security risks also increase, but these can be mitigated by security tools and DevSecOps principles. Use best-in-class tools to identify and analyze vulnerabilities, implement built-in security checkpoints across the SDLC, and make security everyone’s business. Let’s keep hackers and attackers away from our cloud-native systems.