Skip to content

Latest commit

 

History

History
142 lines (97 loc) · 6.19 KB

README.md

File metadata and controls

142 lines (97 loc) · 6.19 KB
Raw

Binary Authorization Pipeline Blueprint

The following blueprint shows to how to create a CI and a CD pipeline in Cloud Build for the deployment of an application to a private GKE cluster with unrestricted access to a public endpoint. The blueprint enables a Binary Authorization policy in the project so only images that have been attested can be deployed to the cluster. The attestations are created using a cryptographic key pair that has been provisioned in KMS.

The diagram below depicts the architecture used in the blueprint.

Architecture

The CI and CD pipelines are implemented as Cloud Build triggers that run with a user-specified service account.

The CI pipeline does the following:

  • Builds and pushes the image to Artifact registry
  • Creates an attestation for the image.

The CD pipeline deploys the application to the cluster.

Running the blueprint

Clone this repository or open it in cloud shell, then go through the following steps to create resources:

  • terraform init
  • terraform apply -var project_id=my-project-id

WARNING: The blueprint requires the activation of the Binary Authorization API. That API does not support authentication with user credentials. A service account will need to be used to run the blueprint

Testing the blueprint

Once the resources have been created, do the following to verify that everything works as expected.

  1. Fetch the cluster credentials

     gcloud container clusters get-credentials cluster --project <PROJECT_ID>

  2. Apply the manifest tenant-setup.yaml available in your work directory.

     kubectl apply -f tenant-setup.yaml

    By applying that manifest thw following is created:

    • A namespace called "apis". This is the namespace where the application will be deployed.
    • A Role and a RoleBinding in previously created namespace so the service account that has been configured for the CD pipeline trigger in Cloud Build is able to deploy the kubernetes application to that namespace.

  3. Change to the image subdirectory in your work directory

     cd <WORK_DIR>/image

  4. Run the following commands:

     git init
 git remote add origin ssh://<USER>:2022/p/<PROJECT_ID>/r/image
 git push -u origin main

  5. In the Cloud Build > History section in the Google Cloud console you should see a job running. That job is build the image, pushing to Artifact Registry and creating an attestation.

    Once the job finishes copy the digest of the image that is displayed in the Cloud Build job output.

  6. Change to the app subdirectory in your working directory.

     cd <WORK_DIR>/app

  7. Edit the app.yaml file and replace the string DIGEST with the value you copied before.

  8. Run the following commands:

     git init
 git remote add origin ssh://<USER>:2022/p/<PROJECT_ID>/r/app
 git push -u origin main

  9. In the Cloud Build > History section in the Google Cloud console you should see a job running. The job will deploy the application to the cluster.

  10. Go to the Kubernetes Engine > Workloads section to check that the deployment was successful and that the Binary Authorization admissions controller webhook did not block the deployment.

  11. Change to the working directory and try to deploy an image that has not been attested.

    cat <<EOF | kubectl apply -f -
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx-deployment
spec:
selector:
    matchLabels:
    app: nginx
replicas: 2 
template:
    metadata:
    labels:
        app: nginx
    spec:
    containers:
    - name: nginx
        image: gcr.io/google-containers/nginx:latest
        ports:
        - containerPort: 80
EOF

  12. Go to the Kubernetes Engine > Workloads section to check that that the Binary Authorization admissions controller webhook did not block the deployment.

The application deployed to the cluster is an RESTful API that enables managing Google Cloud storage buckets in the project. Workload identity is used so the app can interact with the Google Cloud Storage API.

Once done testing, you can clean up resources by running terraform destroy.

Variables

name description type required default
prefix Prefix used for resource names. string ✓
project_id Project ID. string ✓
master_cidr_block Master CIDR block. string "10.0.0.0/28"
pods_cidr_block Pods CIDR block. string "172.16.0.0/20"
project_create Parameters for the creation of the new project. object({…}) null
region Region. string "europe-west1"
services_cidr_block Services CIDR block. string "192.168.0.0/24"
subnet_cidr_block Subnet CIDR block. string "10.0.1.0/24"
zone Zone. string "europe-west1-c"

Outputs

name description sensitive
app_repo_url App source repository url.
image_repo_url Image source repository url.

Test

module "test" {
  source = "./fabric/blueprints/gke/binauthz"
  prefix = "test"
  project_create = {
    billing_account_id = "12345-12345-12345"
    parent             = "folders/123456789"
  }
  project_id = "my-project"
}
# tftest modules=14 resources=49