Implementing DevSecOps with GCP’s Built-in Tools and Solutions

A survey of 600 IT and security professionals reveals that the average cost of cloud account losses due to security breaches was $6.2 million in a year in the U.S. Cloud account takeovers pose a great security threat to businesses, stressing the need for better security of the cloud infrastructure.

In a shift-left approach, DevSecOps is becoming popular, where security is introduced earlier in the application development life cycle. This facilitates a collaborative approach by integrating security with development with deployment and making security a shared responsibility. Security becomes the responsibility of all those who are part of the SDLC and the DevOps services: continuous integration and continuous delivery (CI/CD) workflow.

Read this amazing blog on: Shifting From DevOps to DevSecOps

Security with Speed and Quality

As the time to market shrinks, the need to deliver products quickly and with quality takes priority. By integrating security during the application development lifecycle using a DevSecOps approach, developers can deliver secure applications. DevSecOps encompasses the entire development life cycle from planning to designing, coding, building, testing, and release. Usually, security is added at the end, but fixing security issues post-production can be costly and time-consuming, not to mention delaying the release. DevSecOps prevents this by allowing testing, triaging, and risk mitigation to be incorporated into the CI/CD workflow. This way, security issues can be fixed in real-time in the code instead of being added at the end.

DevSecOps with Google Cloud Platform

Google Cloud’s built-in services enable the development of a secure CI/CD pipeline. Initially, the developers commit the changes to the code to a source code repository, which triggers the delivery pipeline automatically. It also builds and deploys the code changes into various environments, from non-prod environments to production.

The security aspect is also incorporated into the pipeline right at the beginning with open-source libraries and container images when building the source code. By integrating security safeguards within the CI/CD pipeline, the software being built and deployed can be free from vulnerabilities. This also helps determine the type of code/container image that should be permitted to be deployed on the target runtime environment.

Also read: 5 Best Practices While Building a Multi-Tenant SaaS Application using AWS Serverless/AWS EKS

The Google Cloud built-in services that enable the building of a secure pipeline include:

Cloud Build – A serverless CI/CD platform, it facilitates automating building, testing, and deploying tasks.

Artifact Registry – A secure service that allows the storing and managing of your artifacts.

Cloud Deploy – A fully managed Continuous Delivery service for GKE and Anthos.

Binary Authorization – Providing deployment time security controls for GKE and Cloud Run deployments.

GKE – A fully managed Kubernetes platform.

Google Pub/Sub – A serverless messaging platform.

Cloud Functions – A serverless platform for running the code.

The CI/CD pipeline can be set up without enforcing the security policy. But to integrate security with the design and development, the process involves:

• Allowing vulnerability scans to be performed on Artifact Registry and using the Binary Authorization service for creating a security policy.
• Deploying a specific image to the GKE cluster by the developer by checking in the code to a GitHub repo.
• Configuring a Cloud Build trigger to detect the checking in of any new code to the GitHub repo and begin the ‘build’ process.
• The failing of the build process and the triggering of an error message notifying the presence of vulnerabilities in the image.
• When a Binary Authorization policy is violated, an email is sent to a pre-configured email id about the deployment failure.

Cloud Build and Deply Capabilities of Google Cloud

GCP’s Cloud Build enables importing source code from different repositories and cloud storage spaces, executing a build based on specifications, and producing artifacts such as Java archives or Docker containers.

Cloud Build also protects the software supply chain as it complies with the supply chain Levels for Software Artifacts (SLSA) level 3.

Cloud Build features enable securing the builds using features such as:

Automated Builds: In an automated or scripted build, all steps are defined using build script or configuration, including how to retrieve and build the code. The command to run the build is the only manual command used. A build config file is used to provide the Cloud Build steps. Automation ensures consistency of build steps and improves security.

Build Provenance: The provenance metadata is a source of verifiable data about a build and provides details such as:

• Digests of the built images
• Input source locations
• Build toolchain
• Build duration

This helps ensure that the built artifact is from a trusted source location and build system. Build provenance can be generated in Cloud Build for container images with SLSA level 2 assurance.

Ephemeral Build Environment: Ephemeral environments or temporary environments enable a single build invocation, after which the build environment is deleted and leaves behind no residual files or environment settings. This prevents the risk of attackers injecting malicious files and content, reduces maintenance overhead, and decreases inconsistencies in the build environment.

Deployment Policies: By integrating Cloud Build with Binary Authorization, build attestations and block deployments of images not generated by Cloud Build can be verified. This reduced the risk of unauthorized software being deployed.

Customer-Managed Encryption Keys: Compliant customer-managed encryption keys (CMEK) is a default feature in Cloud Build that eliminates the need for users to configure anything specifically. The key is generated uniquely for each build by the encryption of build-time persistent disk (PD) with a temporary key generated every time. This key is destroyed and removed from memory after the completion of the build and the data protected by such a key is inaccessible forever.

Google Cloud Deploy: Google Cloud Deploy is a managed infrastructure deployment service for automating the creation and management of Google Cloud resources. It automates the delivery of applications to a series of target environments in a pre-defined sequence. It ensures GKE and Anthos Continuous Delivery, and once the build is ready, a Cloud Deploy pipeline is created. This will deploy the container image to the three GKE environments of testing, staging, and production. It requires an approval process to be implemented, ensuring security.

Indium–for DevSecOps with GCP

Indium Software is a leading software solution provider offering a comprehensive set of DevOps services to increase the high-quality throughput of new capabilities. The solutions offered include:

CI/CD Services: Create code pipelines free of blocks and with a smooth value stream flowing from development to integration, testing, security, and deployment

Deployment Automation: Automate deployment and free up resources to perform value-added tasks

Containerization: Packaged executables that allow build anywhere-deploy anywhere approach

Assessment & Planning: Establish traceable metrics to assess performance and achieve the desired state

Security Integration: Ensure end-to-end security integration with ‘Security as Code’ using DevSecOps