Validate configs

This tutorial shows you how to validate configs with Cloud Build when using Google Kubernetes Engine (GKE) Enterprise edition clusters. The same setup works in any other container-based CI/CD system, such as CircleCI, with minimal changes.

We recommend validating any configuration changes in your CI/CD pipeline in addition to checking the validity of your configs by running the nomos vet command.

Objectives

• Create a Cloud Build config file that instructs Config Sync to use nomos vet on the configs in your repository.
• Create a Cloud Build trigger so that your configs are checked whenever there's a change to the development branch.

Costs

In this document, you use the following billable components of Google Cloud:

• Config Sync (part of GKE Enterprise)
• Cloud Build

To generate a cost estimate based on your projected usage, use the pricing calculator. New Google Cloud users might be eligible for a free trial.

When you finish the tasks that are described in this document, you can avoid continued billing by deleting the resources that you created. For more information, see Clean up.

Before you begin

1. Sign in to your Google Cloud account. If you're new to Google Cloud, create an account to evaluate how our products perform in real-world scenarios. New customers also get $300 in free credits to run, test, and deploy workloads.

2. In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

   Note: If you don't plan to keep the resources that you create in this procedure, create a project instead of selecting an existing project. After you finish these steps, you can delete the project, removing all resources associated with the project.

   Go to project selector

3. Make sure that billing is enabled for your Google Cloud project.

4. Enable the Cloud Build API.

   Enable the API

5. In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

   Note: If you don't plan to keep the resources that you create in this procedure, create a project instead of selecting an existing project. After you finish these steps, you can delete the project, removing all resources associated with the project.

   Go to project selector

6. Make sure that billing is enabled for your Google Cloud project.

7. Enable the Cloud Build API.

   Enable the API

8. Create, or have access to, a GKE Enterprise cluster that meets the requirements for Config Sync. For details on how to create such a cluster, see Get started with Config Sync.

Grant the Cloud Build service account permission

Grant the Cloud Build service account permission to access your GKE Enterprise cluster.

gcloud

To add the Kubernetes Engine Developer role to the Cloud Build service account, run the following command:

PROJECT_ID=$(gcloud config get-value project)
PROJECT_NUM=$(gcloud projects list --filter="$PROJECT_ID" --format="value(PROJECT_NUMBER)")
gcloud projects add-iam-policy-binding $PROJECT_ID \
    --member=serviceAccount:$[e-mail] \
    --role=roles/container.developer

Console

1. Open the IAM page in Google Cloud console.

   Go to the IAM page

2. In the member column find the row with the Cloud Build service account:

   [e-mail]
   

3. In that row, click Edit principal.

4. Click Add another role.

5. In the Select a role list, select Kubernetes Engine Developer, and then click Save.

Create a Cloud Build config

Create a Cloud Build config file and store it in the root directory of the repository containing your config files (for example, my-repo/cloudbuild.yaml).

steps:
- name: 'gcr.io/cloud-builders/kubectl'
  args: ['config', 'current-context']
  volumes:
  - name: 'kube'
    path: '/kube'
  env:
  - 'KUBECONFIG=/kube/config'
  - 'CLOUDSDK_COMPUTE_ZONE=ZONE'
  - 'CLOUDSDK_CONTAINER_CLUSTER=CLUSTER_NAME'
  - 'CLOUDSDK_CONTAINER_USE_APPLICATION_DEFAULT_CREDENTIALS=true'
- name: 'bash'
  args: ['chmod', '444', '/kube/config']
  volumes:
  - name: 'kube'
    path: '/kube'
- name: 'gcr.io/config-management-release/nomos:stable'
  args: ['nomos', 'vet', '--path', '/workspace/POLICY_DIR']
  volumes:
  - name: 'kube'
    path: '/kube'
  env:
  - 'KUBECONFIG=/kube/config'
  timeout: 30s

Replace the following:

• ZONE: the zone where your cluster is running
• CLUSTER_NAME: the name of your cluster
• POLICY_DIR: the path within the Git repository that represents the top level of the repository to sync

There are three steps in this configuration:

1. Run kubectl config current-context to generate the kubeconfig file needed to authenticate to the my-cluster GKE cluster. The root user generates this file with restricted permissions.
2. Run chmod 444 /kube/config to make this file readable in the next step.
3. Run nomos vet on the Git repository which is automatically cloned in /workspace. If you are using an unstructured repo, run nomos vet --source-format=unstructured instead.

Create a build trigger

The following example creates a trigger that runs for every commit to the master branch of a Cloud Source Repositories repository.

1. Open the Triggers page in Google Cloud console.

   Go to the triggers page

2. Click Connect repository.

3. Select GitHub (mirrored), and then click Continue.

4. Select your repository, and then click Connect repository.

5. Click Add trigger.

6. Enter or select the corresponding entry in each field described in the following table:

   Field	Entry
   Event	Push to a branch
   Branch	^master$
   Configuration	Cloud Build configuration file (yaml or json)
   Cloud Build configuration file location	/ cloudbuild.yaml

7. Click Create to save your build trigger.

Test the build trigger

Manually test the setup by running the trigger:

1. Open the Triggers page in Google Cloud console.

   Go to the triggers page

2. Find the trigger you created, and then click Run trigger.

   The message "Build started on master branch" appears.

3. Click Show.

   The Cloud Build steps appear green if set up correctly.

Invalid Cloud Build configurations

A trigger cannot run if the Cloud Build configuration file is invalid.

To test this, update the Cloud Build config in your repository with the following file. Notice the invalid indentation on line 6:

steps:
- name: 'gcr.io/cloud-builders/kubectl'
  args: ['config', 'current-context']
  volumes:
  - name: 'kube'
  path: '/kube'
  env:
  - 'KUBECONFIG=/kube/config'
  - 'CLOUDSDK_COMPUTE_ZONE=ZONE'
  - 'CLOUDSDK_CONTAINER_CLUSTER=CLUSTER_NAME'
  - 'CLOUDSDK_CONTAINER_USE_APPLICATION_DEFAULT_CREDENTIALS=true'
- name: 'bash'
  args: ['chmod', '444', '/kube/config']
  volumes:
  - name: 'kube'
    path: '/kube'
- name: 'gcr.io/nomos-release/nomos:stable'
  args: ['nomos', 'vet', '--path', '/workspace/POLICY_DIR']
  volumes:
  - name: 'kube'
    path: '/kube'
  env:
  - 'KUBECONFIG=/kube/config'
  timeout: 30s

If you manually run the trigger again, you receive the following error message because path: on line 6 is not correctly indented:

Failed to trigger build: failed unmarshalling build config cloudbuild.yaml:
unknown field "path" in cloudbuild_go_proto.BuildStep.

To fix this config, indent path: on line 6 to the same level as name: on line 5. For more information about the structure of a Cloud Build configuration file, see Creating a basic Cloud Build config.

Clean up

Delete the project

Caution: Deleting a project has the following effects:

• Everything in the project is deleted. If you used an existing project for the tasks in this document, when you delete it, you also delete any other work you've done in the project.
• Custom project IDs are lost. When you created this project, you might have created a custom project ID that you want to use in the future. To preserve the URLs that use the project ID, such as an appspot.com URL, delete selected resources inside the project instead of deleting the whole project.

If you plan to explore multiple architectures, tutorials, or quickstarts, reusing projects can help you avoid exceeding project quota limits.

Delete a Google Cloud project:

gcloud projects delete PROJECT_ID

Delete individual resources

To delete the individual resources, complete the following steps:

1. Delete the Cloud Build config file.
2. Delete the Cloud Build trigger that you created.
3. Delete the cluster that you used for this tutorial.

What's next

• Learn about Cloud Build
• Temporarily stop syncing configs