The What and Why of Cloud-Native Security | #cloudsecurity

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. For many years, these issues were the security team’s problem; recent surveys and research highlight the importance of security at all stages of the software development life cycle (SDLC).

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. Using modern cloud-native best practices and tools can help tackle vulnerabilities and threats across the SDLC.

What is Cloud-Native?

Approximately ten years ago, the term ‘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 computing frameworks and infrastructures and encourage an accelerated time-to-market. These applications use modern cloud practices like immutable infrastructure, infrastructure-as-code (IaC), containers and container registries, service meshes and APIs.

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. There are 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

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 orchestrator for our container deployments.

We also need storage, whether that means 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 its API. The orchestrator exposes the API server and a very rich set of functionalities which clients then leverage to perform various actions on the orchestrator. Now, the next step is to make sure that we have isolation, and one of the aspects that are facilitated in a Kubernetes environment is using namespaces. 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 a lot of attention these days, as a best practice, security should be integrated throughout the software development life cycle; having security checkpoints at each stage is considered more effective. Shift left with regard to security means prioritizing security very early in the development life cycle and making it everyone’s job. This way, any vulnerabilities that can impact software delivery and create bottlenecks in production can be prevented. O’Reilly’s survey, “How Companies Adopt and Apply Cloud Native Infrastructure” surveyed 590 security practitioners, DevOps managers and C-level executives from around the world and found security and compliance barriers were among the top challenges faced on the road to cloud-native adoption.


Cloud-native security addresses these security concerns by shifting the security left in the SDLC and ensures that vulnerabilities are detected, identified and remediated at the right time. This is similar to the DevSecOps approach; baking security throughout every step in the software development life cycle.

Cloud-native security acts as a gatekeeper and a guard for all the security vulnerabilities that might enter your software flow.

Four Cs of Cloud-Native Security

Cloud infrastructure: The cloud is the foundation of all security layers. Since developers cannot configure application security at the code level, security steps must be taken at the cloud level. It is all about running secure workloads in the respective cloud provider’s environment.

Cluster: After cloud comes the cluster layer, where Kubernetes is considered the standard orchestration tool. When using Kubernetes, there are certain things to consider—RBAC, pod security and network policies, secrets management, logging and monitoring.

Container security: At this layer, container security management and best practices are important. When applications are built inside a container, security best practices include first, avoiding running privileged containers. Most applications don’t need root access to operate, except for system containers like monitoring or logging agents. This should prevent an invader from gaining root access to the container and being able to access the host node.

Code: The last ‘C’ in the cloud-native security layer is code. Strengthening security via an application’s code is a DevSecOps best practice that starts with the source code. By catching security vulnerabilities early in the SDLC, companies can save time, cost and effort. One best practice to restrict the vulnerabilities in your code is to use code analysis and/or scanning tools built just for this purpose.

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 Docker compose which also builds a container using images and packages from public repositories.
  • It is then placed into the registries and proceeds to staging.
  • After successful staging, the container proceeds to production.

There are security risks at each stage that must be addressed. The workflow might have insecure code with vulnerabilities; libraries and images might have been downloaded from unknown sources; there might be license-related issues, etc. As a DevSecOps best practice, use regular checkpoints at each stage of the development workflow along with cloud-native security tools. Google Cloud has a great table of implied requirements for security when moving to a cloud-native architecture.

Scanning for Cloud-Native App Vulnerabilities

There are usually many dependency layers in an application on its code-to-production journey. For example, if the application is written in Java, you may have Maven dependencies. The next step in the process could involve running the application on Linux, which introduces dependencies in Debian repositories. The next step is wrapping the app in Docker to run on Kubernetes and then you will have Docker repositories to contend with. 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 called Artifactory. It stores all the 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 a full-featured security check for cloud-native applications.

While DevOps methodologies focus on speed and agility, cloud-native security focuses on the security aspect throughout the cloud-based SDLC. By combining both speed and security, enterprises can easily progress on their desired digital transformation journey. With the increasing adoption of cloud-native principles, tools and platforms, security risks also increase, but they can be mitigated using security tools and DevSecOps principles. Employ best-in-class tools to detect and analyze vulnerabilities, implement integrated security checkpoints across the SDLC and make security everyone’s job. Let’s keep hackers and attackers away from our cloud-native systems.

Original Source link

Leave a Reply

Your email address will not be published. Required fields are marked *

twenty four − sixteen =