Defining Security Policies

Whatever we do in the cloud needs to be secure. Cloud providers only provide tools. You need to define how to use these tools. In order to determine what these tools should do, you need to think about what type of assets you want to protect and how you need to protect them. There are quite a number of security baselines—for example, the baseline as defined by the Center for Internet Security (CIS), which provides guidelines.

In this chapter, we will learn what a security framework is and why it’s important as a starting point for security policies. We will discover what we need to protect in our cloud environments. Next, we will look at the globally adopted CIS benchmark for Azure, AWS, GCP, Alibaba Cloud, and OCI and learn how to implement CIS using the security suites of these platforms. We will then learn what the difference is between security governance and management, and lastly, study Cloud Security Posture Management ...

Join our book community on Discord

https://packt.link/multicloud

The typical reason why most enterprises adopt the cloud is to accelerate application development. Applications are constantly evaluated and changed to add new features. Since everything is codified in the cloud, these new features need to be tested on the infrastructure of the target cloud. The final step in the life cycle of applications is the actual deployment of applications to the cloud and the handover to operations so that developers have their hands free to develop new features again, based on business requirements.

To speed up this process, organizations work in DevOps cycles, with continuous development and the possibility to test, debug, and deploy code multiple times per week, or even per day, so that these applications are constantly improved. Consistency is crucial: the source code needs to be under strict version control. That is what CI/CD pipelines are for: continuous integration and continuous delivery...

Understanding the need for DevSecOps

Before we dive into the layers of DevSecOps, it’s good to understand why DevSecOps is important in multi-cloud. First, we must understand the layers in securing the cloud. There are four layers to be considered:

1. Organizational level or the overarching governance
2. Enterprise level, ensuring the security across accounts, auditing centralized compliancy through monitoring and logging, and promoting automation
3. Subscription level, using Role Based Access Control (RBAC), threat detection and in-depth defence
4. Solution level, using CI/CD with validated templates, blueprints and images

We must define security on all levels. The following diagram shows all levels of defence in cloud.

Figure 13.1 – Levels of security in application stacks

The top of the stack is formed by the application payloads. In multi-cloud, enterprises will likely use containers and CI/CD (Continuous Integration/Continuous Deployment) pipelines in multi-cloud. With multi...

Starting with implementing a DevSecOps culture

In the previous section we already mentioned the NIST guide to secure containers. That guide starts with something non-technical: a mindset. The first advice NIST gives is ‘Tailor the organization’s operational culture and technical processes to support the new way of developing, running, and supporting applications made possible by containers.’

Why would we need to change the culture in the way we do IT? Because with cloud, cloud-native and containers the way of doing software development changes drastically. Developers and operations might be less concerned with traditional IT processes such as patching and upgrading systems. We want to integrate security in the builds of the applications, including the way applications utilize the underlying infrastructure without having to worry about the physical infrastructure or even the virtual machines. Let software take care of it, but then the software must be programmed, configured...

Setting up CI/CD

Before we start building pipelines, it’s good to have a definition of CI and CD.

• Continuous Integration (CI) is built on the principle of a shared repository, where code is frequently updated and shared across teams that work in the cloud environments. CI allows developers to work together on the same code at the same time. The changes in the code are directly integrated and ready to be fully tested in different test environments.
• Continuous Delivery or Deployment (CD) focuses on the automated transfer of software to test environments. The ultimate goal of CD is to bring software to production in a fully automated way. Various tests are performed automatically. After deployment, developers immediately receive feedback on the functionality of the code.

CI/CD enables the DevOps cycle. Combined with CI/CD, all responsibilities, from planning to management, lie with the team, and changes can reach the customer much faster through an automated and robust development...

Working with CI/CD in multi-cloud

The development of code for applications can be cloud-agnostic, meaning that it doesn't matter to which cloud the code is pushed: the functionality of the code remains the same. That’s the reason why we use containers: to abstract the code from the underlying infrastructure. However, a lot of developers will discover that it does matter and that's it not that simple to develop in a truly multi-cloud fashion.

In multi-cloud, developers also work from one repository, but during deployment, platform-specific configuration might be added and tested, even when we utilize Kubernetes platforms in our clouds. You will find that Kubernetes is the same, but the various implementations of Kubernetes platforms in clouds might differ.

There are a few steps that developers have to take to make it successful. First, the DevOps way of working should be consistent, regardless of the platform where applications will eventually land. A company might want...

Exploring tools for CI/CD

The tooling landscape for CI/CD and DevOps is massive and changes almost every month. There's no right or wrong answer in choosing the toolset, as long as it fits the need of the enterprise and people are trained in the usage of the tools. In this section, the native CI/CD tooling in the major clouds are discussed: Azure DevOps, AWS CodePipeline and CloudFormation and Google Cloud Build. We will also look at tooling for Alibaba Cloud and OCI.

First, we will look at Kubernetes, since that will be likely be the platform that we’ll use in multi-cloud. Key components of Kubernetes CI/CD are:

• Container management
• Cluster operations
• Configuration management for the underlying infrastructure
• Version control system
• Image registries for Docker container images.
• Security testing and audits
• Continuous monitoring and observability

To create a good pipeline, we should consider the following design principles:

• All-in-one CI/CD tool instead of cloud-specific...

Following the principles of Secure by Design

In the previous sections we designed our CI/CD pipelines. But as we have concluded, security starts at the very beginning of DevOps and should be integrated throughout the entire process, from the moment the code is pulled, or new code is written up until deployment to production. We need to apply security by design. This is the second layer of DevSecOps and includes the following activities:

• Securing pipelines: best practice is to apply zero trust-principles to the pipeline. Pipelines should only be accessed through least privilege policies. Also, continuous testing must be integrated in the pipeline. This includes Static Application Security Testing (SAST), but also penetration testing to find any backdoors in the pipelines or any other vulnerabilities.
• Clean code practice: this one is subject to multiple interpretatons, but key is the principle of KISS: keep it simple, stupid. Try to keep the code as simple and short as possible. Document...

Securing development and operations using automation

Automation is a must in DevSecOps. At a minimum, we should consider automating the following processes:

• Version Control
• Continuous Integration
• Continuous Testing
• Configuration Management & Deployment
• Continuous Monitoring

We talked about containers, side cars and orchestration. Clouds offer tools to also automate this as a completely managed service. Containerization with automated orchestration offers great benefits to companies. Orchestration platforms such as Kubernetes and the various managed Kubernetes services in public clouds, take care of the installation, scaling, and management of containerized workloads and services, including debugging and deployment of new versions of applications.

Containers are isolated by default. One failing container will not impact other containers. Individual containers can be updated without causing downtime for other containers. This also means that containers are protected very well from...

Summary

After completing this chapter, you should have a good understanding of the DevOps way of working and the use of CI/CD pipelines in cloud environments. Everything is code in cloud, from the application to the infrastructure and the configuration. Code needs to be stored in a central repository and brought under version control. That's where the CI/CD pipeline starts. Next, the DevOps team defines the phases of the pipeline, typically build, test, and deploy. Actions in these phases are automated as much as possible.

We learned that we must integrate security from the moment developers start writing or pulling code. Access to the code, the code itself, the pipelines, and the target clouds that we use must be secured and protected from breaches by identifying vulnerabilities and taking appropriate mitigating actions. We studied the various technologies and tools that provide CI/CD functionality and explored how we can protect our applications when we work with CI/CD by applying...