CI/CD
Deploy a secure CI/CD pipeline
Set up a secure CI/CD pipeline that follows best practices for building, scanning, storing, and deploying containers to Google Kubernetes Engine (GKE).
New customers get $300 in free credits to fully explore and conduct an assessment of Google Cloud.
Who this is for
Developers and DevOps Engineers
What you’ll deploy
A sample CI/CD pipeline with open source code on Google Cloud for learning purposes
How you’ll deploy
Once you’ve signed up for Google Cloud, you can deploy through the console.
Overview
What is CI/CD?
CI/CD stands for Continuous Integration/Continuous Delivery or Deployment.
What is continuous integration?
Continuous integration automates the integration of code changes from multiple developers into a central repository to run automated builds and tests.
What is continuous delivery and continuous deployment?
Continuous delivery goes further than continuous integration. With continuous delivery, every code change gets automatically built, tested and then shipped to the testing or staging environments. Continuous deployment expands one step further to fully automate the release cycle and directly push the code into the production environment with no human intervention.
What is a CI/CD pipeline?
A CI/CD pipeline is a series of steps for integrating, building, testing, and deploying code to release a new version of software. It is the fundamental component of automated software development and the backbone of the DevOps methodology.
What are the benefits of CI/CD?
By building and automating your CI/CD pipeline, you will be able to gain benefits such as reducing human errors, increasing code quality, and releasing software much faster and more frequently.
What are some CI/CD security best practices?
Some best practices of increasing CI/CD security posture include well controlled access to your CI/CD pipeline, secure handling of your credentials like secret and tokens, security scanning like static code scanning, registry scanning and runtime scanning, and timely updating your CI/CD toolchain and auditing.
Solution Details
Deploy a secure CI/CD pipeline
Set up a CI/CD pipeline that follows the security best practices with Google Cloud services such as Cloud Build, Cloud Deploy, Artifact Registry and Binary Authorization.
Solution Architecture
- A developer pushes new code or a code change for a container-based application to Cloud Source Repositories.
- The code push invokes a Cloud Build trigger. The Cloud Build trigger starts a build in a Cloud Build private worker pool that’s hosted in a customer-managed VPC. The outputs of the build are metadata files, Cloud Build logs, and containers.
- The metadata files and the Cloud Build logs are stored in a Cloud Storage bucket.
- The pipeline runs security scans (that you configure) and validates the container structure. When the scans and structure pass, the containers are stored in Artifact Registry.
- The Cloud Build trigger requests an attestation from Binary Authorization that certifies that the required scans passed. The attestation is stored as a cryptographic signature in Binary Authorization.
- The Cloud Build trigger starts a Cloud Deploy release to roll out the containers to the three environments: developer (dev), QA (qa), and production (prod). Each environment is one Kubernetes cluster in its own subnet. All three clusters and subnets are in the same GKE VPC. The last cluster is the production environment.
- As the rollout starts, Cloud Deploy sends the containers to the developer environment. Google Kubernetes Engine (GKE) uses the policy that’s defined for the cluster to check the container’s build attestation in Binary Authorization. When this check passes, GKE deploys the containers into the Kubernetes cluster.
- When Cloud Deploy releases the containers to the developer environment, Cloud Deploy sends a Pub/Sub message that starts the second Cloud Build trigger. This Cloud Build trigger runs post-deployment tests (that you configure) in the developer environment. To run these tests, Cloud Build worker pools communicate with the clusters using Connect Gateway.
- When the post-deployment checks succeed, the Cloud Build trigger requests an attestation from Binary Authorization. The attestation certifies that the required tests from the developer environment passed.
- Cloud Deploy promotes the release to the second Kubernetes cluster for the QA environment. Steps 7 to 9 run again with some differences: GKE checks for the two attestations before deploying, and after the tests pass, the quality attestation is created.
- Cloud Deploy promotes the release to the production environment, which is the third Kubernetes cluster. GKE uses a policy to check for all three attestations in Binary Authorization. When this check passes, GKE deploys the containers in the Kubernetes cluster for the production environment.
Secure CI/CD pipeline
Google Cloud Experience Level
Intermediate
Estimated deployment time
16 min
4 min to configure, 12 min to deploy
New customers get $300 in free credits to fully explore and conduct an assessment of Google Cloud.
Requirements
- Active Google Cloud account
- Administrator rights to your project
Products used
Artifact Registry
Store, manage, and secure container images and language packages
Cloud Source Repositories
Private Git repository to store,manage and track code
Cloud Build
Continuous integration and continuous delivery platform
Cloud Deploy
Fully managed continuous delivery to GKE, Cloud Run and Anthos.
Binary Authorization
Deploy-time security control
Google Kubernetes Engine
Managed environment for running containerized apps
Virtual Private Cloud
Virtual network for Google Cloud resources and cloud-based services
Cloud Storage
Object storage that’s secure, durable and scalable
Pub/Sub
Messaging service for event ingestion and delivery
