Install Config Sync

With Config Sync, you can manage Kubernetes resources with configuration files stored in a source of truth. Config Sync supports Git repositories, OCI images, and Helm charts as a source of truth. This page shows you how to enable and configure Config Sync so that it syncs from your root repository. Config Sync is available with Google Kubernetes Engine (GKE) Enterprise edition.

When you install Config Sync using the Google Cloud console or the Google Cloud CLI, the RootSync and RepoSync APIs are enabled by default. This provides you with additional features such as syncing from multiple repositories and syncing Kustomize and Helm configurations.

Before you begin

Before you install Config Sync, prepare your environment, ensure you meet cluster requirements, and grant the right user roles.

Prepare your local environment

Prepare your local environment by completing the following tasks:

1. Create, or make sure you have access to, a source of truth. This is where you add the configs that Config Sync syncs to. To learn more about how to set up your configs and source of truth, see one of the following guides:
   • Add configs to a source of truth.
   • Sync OCI artifacts from Artifact Registry.
   • Sync Helm charts from Artifact Registry.
2. Install and initialize the Google Cloud CLI, which provides the gcloud, and nomos commands. If you use Cloud Shell, the Google Cloud CLI comes pre-installed. If you previously installed the Google Cloud CLI, get the latest version by running gcloud components update.

3. Enable the GKE Enterprise API.

   Enable GKE Enterprise API

Review cluster requirements

Before you install Config Sync on your cluster, review cluster configuration recommendations and requirements.

Prepare your cluster

After you have created a suitable cluster, complete the following steps:

1. Grant the required IAM roles to the user registering the cluster.

2. If you plan to use the Google Cloud CLI to configure Config Sync or use clusters outside Google Cloud, ensure that your GKE clusters or clusters outside of Google Cloud are registered to a fleet now. If you plan to use the Google Cloud console, you can register GKE clusters when you configure Config Sync.

Install Config Sync

In the following sections, you grant Config Sync access to one of the following sources of truth:

• Git repository
• OCI image
• Helm chart

After you have granted access, you can configure Config Sync.

Grant access to Git

Config Sync needs read-only access to your Git repository so that it can read the configs committed to the repository and apply them to your clusters.

If your repository does not require authentication for read-only access, you can continue to configure Config Sync and use none as your authentication type. For example, if you can browse the repository using a web interface without logging in, or if you can use git clone to create a clone of the repository locally without providing credentials or using saved credentials, then you don't need to authenticate. In this case, you don't need to create a Secret.

However, most users need to create credentials because read access to their repository is restricted. If credentials are required, they are stored in the git-creds Secret on each enrolled cluster (unless you are using a Google service account). The Secret must be named git-creds because this is a fixed value.

Config Sync supports the following mechanisms for authentication:

• SSH key pair (ssh)
• Cookiefile (cookiefile)
• Token (token)
• Google service account (gcpserviceaccount)
• Compute Engine default service account (gcenode)
• GitHub App (githubapp)

The mechanism that you choose depends on what your repository supports. Generally, we recommend using an SSH key pair. GitHub and Bitbucket both support using an SSH key pair. However, if you are using a repository in Cloud Source Repositories, we recommend that you use a Google service account instead as the process is simpler. If your organization hosts your repository and you don't know which authentication methods are supported, contact your administrator.

To use a repository in Cloud Source Repositories as your Config Sync repository, complete the following steps to retrieve your Cloud Source Repositories URL:

1. List all repositories:

   gcloud source repos list
   

2. From the output, copy the URL from the repository that you want to use. For example:

   REPO_NAME  PROJECT_ID  URL
   my-repo    my-project  https://source.developers.google.com/p/my-project/r/my-repo-csr
   

   You need to use this URL when you configure Config Sync in the following section. If you configure Config Sync using the Google Cloud console, you add the URL in the URL field. If you configure Config Sync using the Google Cloud CLI, you add the URL to the syncRepo field of your configuration file.

SSH key pair

An SSH key pair consists of two files, a public key and a private key. The public key typically has a .pub extension.

Warning: Protect the files created by this command. They grant the ability to read from your repository.

To use an SSH key pair, complete the following steps:

1. Create an SSH key pair to allow Config Sync to authenticate to your Git repository. This step is necessary if you need to authenticate to the repository to clone it or read from it. Skip this step if a security administrator provides you with a key pair. You can use a single key pair for all clusters, or a key pair per cluster, depending on your security and compliance requirements.

   The following command creates a 4096-bit RSA key. Lower values are not recommended:

   ssh-keygen -t rsa -b 4096 \
   -C "GIT_REPOSITORY_USERNAME" \
   -N '' \
   -f /path/to/KEYPAIR_FILENAME
   

   Replace the following:

   • GIT_REPOSITORY_USERNAME: the username that you want Config Sync to use to authenticate to the repository
   • /path/to/KEYPAIR_FILENAME: a path to the key pair

   If you are using a third-party Git repository host such as GitHub, or you want to use a service account with Cloud Source Repositories, we recommend that you use a separate account.

   Note: You must create the SSH key without a passphrase. Config Sync does not support SSH key passphrases.

2. Configure your repository to recognize the newly created public key. Refer to the documentation for your Git hosting provider. Instructions for some popular Git hosting providers are included for convenience:

   • Cloud Source Repositories
   • Bitbucket
   • GitHub We recommend that you create separate deploy keys to provide read-only access to a single GitHub repository.
   • GitLab

3. Add the private key to a new Secret in the cluster:

   kubectl create ns config-management-system && \
   kubectl create secret generic git-creds \
    --namespace=config-management-system \
    --from-file=ssh=/path/to/KEYPAIR_PRIVATE_KEY_FILENAME
   

   Replace /path/to/KEYPAIR_PRIVATE_KEY_FILENAME with the name of the private key (the one without the .pub suffix).

4. (Recommended) To configure known hosts checking using SSH authentication, you can add the known hosts key to the data.known_hosts field in the git_creds secret. To disable known_hosts checking, you can remove the known_hosts field from the secret. To add the known hosts key, run:

   kubectl edit secret git-creds \
    --namespace=config-management-system
   

   Then, under data, add the known hosts entry:

   known_hosts: KNOWN_HOSTS_KEY
   

5. Delete the private key from the local disk or otherwise protect it.

6. When you configure Config Sync and add the URL for your Git repository, use the SSH protocol. If you are using a repository in Cloud Source Repositories, you must use the following format when you enter your URL:

   ssh://[e-mail]:2022/p/PROJECT_ID/r/REPO_NAME
   

   Replace the following:

   • EMAIL: your Google Cloud username
   • PROJECT_ID: the ID of the Google Cloud project where the repository is located
   • REPO_NAME: the name of the repository

Cookiefile

Note: Using cookiefile credentials is only supported with Cloud Source Repositories. If you would like to use GitHub with cookiefile authentication, you can use Cloud Source Repositories to mirror your GitHub repository.

The process for acquiring a cookiefile depends on the configuration of your repository. For an example, see Generate static credentials in the Cloud Source Repositories documentation. The credentials are usually stored in the .gitcookies file in your home directory, or they might be provided to you by a security administrator.

To use a cookiefile, complete the following steps:

1. After you create and obtain the cookiefile, add it to a new Secret in the cluster.

   If you don't use an HTTPS proxy, create the Secret with the following command:

   kubectl create ns config-management-system && \
   kubectl create secret generic git-creds \
    --namespace=config-management-system \
    --from-file=cookie_file=/path/to/COOKIEFILE
   

   If you need to use an HTTPS proxy, add it to the Secret together with cookiefile by running the following command:

   kubectl create ns config-management-system && \
   kubectl create secret generic git-creds \
    --namespace=config-management-system \
    --from-file=cookie_file=/path/to/COOKIEFILE \
    --from-literal=https_proxy=HTTPS_PROXY_URL
   

   Replace the following:

   • /path/to/COOKIEFILE: the appropriate path and filename
   • HTTPS_PROXY_URL: the URL for the HTTPS proxy that you use when communicating with the Git repository
   Note: HTTP proxy is not supported for security reasons.

2. Protect the contents of the cookiefile if you still need it locally. Otherwise, delete it.

Token

If your organization does not permit the use of SSH keys, you might prefer to use a token. With Config Sync, you can use GitHub's personal access tokens (PATs), GiLab's PATs or deploy keys, or Bitbucket's app password as your token.

To create a Secret using your token, complete the following steps:

1. Create a token using GitHub, GitLab, or Bitbucket:

   • GitHub: Create a PAT. Grant the token the repo scope so that it can read from private repositories. Because you bind a PAT to a GitHub account, we also recommend that you create a machine user and bind your PAT to the machine user.
   • GitLab: Create a PAT or create a deploy token
   • Bitbucket: Create an app password.

2. After you create and obtain the token, add it to a new Secret in the cluster.

   If you don't use an HTTPS proxy, create the Secret with the following command:

   kubectl create ns config-management-system && \
   kubectl create secret generic git-creds \
     --namespace="config-management-system" \
     --from-literal=username=USERNAME \
     --from-literal=token=TOKEN
   

   Replace the following:

   • USERNAME: the username that you want to use.
   • TOKEN: the token that you created in the previous step.

   If you need to use an HTTPS proxy, add it to the Secret together with username and token by running the following command:

   kubectl create ns config-management-system && \
   kubectl create secret generic git-creds \
    --namespace=config-management-system \
    --from-literal=username=USERNAME \
     --from-literal=token=TOKEN \
    --from-literal=https_proxy=HTTPS_PROXY_URL
   

   Replace the following:

   • USERNAME: the username that you want to use.
   • TOKEN: the token that you created in the previous step.
   • HTTPS_PROXY_URL: the URL for the HTTPS proxy that you use when communicating with the Git repository.
   Note: HTTP proxy is not supported for security reasons.

3. Protect the token if you still need it locally. Otherwise, delete it.

Google service account

If your repository is in Cloud Source Repositories, and your cluster uses GKE Workload Identity Federation for GKE or fleet Workload Identity Federation for GKE, you can give Config Sync access to a repository in the same project as your managed cluster by using a Google service account.

1. If you don't already have a service account, create a service account.

2. Grant the Cloud Source Repositories Reader (roles/source.reader) IAM role to the Google service account. For more information about Cloud Source Repositories roles and permissions, see Grant permissions to view repositories.

   • Grant project-wide permission if the same permissions apply to all repositories in the project.

     gcloud projects add-iam-policy-binding PROJECT_ID \
       --role=roles/source.reader \
       --member="serviceAccount:GSA_NAME@PROJECT_ID.iam.gserviceaccount.com"
     

   • Grant repository-specific permission when you want service accounts to have different levels of access for each repository in your project.

     gcloud source repos set-iam-policy REPOSITORY POLICY_FILE --project=PROJECT_ID
     

3. If you configure Config Sync using the Google Cloud console, select Workload Identity Federation for GKE as the Authentication Type and then add your service account email.

   If you configure Config Sync using the Google Cloud CLI, add gcpserviceaccount as the secretType and then add your service account email to gcpServiceAccountEmail.

4. After configuring Config Sync, create an IAM policy binding between the Kubernetes service account and the Google service account. The Kubernetes service account is not created until you configure Config Sync for the first time.

   If you are using clusters that are registered to a fleet, you only have to create the policy binding once per fleet. All clusters registered in a fleet share the same Workload Identity Federation for GKEpool. With fleet's concept of sameness, if you add the IAM policy to your Kubernetes service account in one cluster, then the Kubernetes service account from the same namespace on other clusters in the same fleet also get the same IAM policy.

   This binding lets the Config Sync Kubernetes service account act as the Google service account:

   gcloud iam service-accounts add-iam-policy-binding \
       GSA_NAME@PROJECT_ID.iam.gserviceaccount.com \
       --role=roles/iam.workloadIdentityUser \
       --member="serviceAccount:FLEET_HOST_PROJECT_ID.svc.id.goog[config-management-system/KSA_NAME]" \
       --project=PROJECT_ID
   

Replace the following:

• PROJECT_ID: the organization's project ID.
• FLEET_HOST_PROJECT_ID: if you're using GKE Workload Identity Federation for GKE, this is the same as PROJECT_ID. If you're using fleet Workload Identity Federation for GKE, this is the project ID of the fleet that your cluster is registered to.
• GSA_NAME: the custom Google service account that you want to use to connect to Artifact Registry. The service account must have the Artifact Registry Reader (roles/artifactregistry.reader) IAM role.
• KSA_NAME: the Kubernetes service account for the reconciler.
  • For root repositories, if the RootSync name is root-sync, use root-reconciler. Otherwise, use root-reconciler-ROOT_SYNC_NAME. If you install Config Sync using the Google Cloud console or the Google Cloud CLI, Config Sync automatically creates a RootSync object named root-sync.
• REPOSITORY: the name of the repository.
• POLICY_FILE: the JSON or YAML file with the Identity and Access Management policy.

Note: Creating this policy binding requires the iam.serviceAccounts.setIamPolicy permission.

Compute Engine default service account

If your repository is in Cloud Source Repositories, and your cluster is GKE with Workload Identity Federation for GKE disabled, you can use gcenode as your authentication type.

If you configure Config Sync using the Google Cloud console, select Google Cloud Repository as the Authentication Type.

If you configure Config Sync using the Google Cloud CLI, add gcenode as the secretType.

Selecting either Google Cloud Repository or gcenode lets you use the Compute Engine default service account. You must grant the Cloud Source Repositories Reader (roles/source.reader) IAM role to the Compute Engine default service account. For more information about Cloud Source Repositories roles and permissions, see Grant permissions to view repositories.

gcloud projects add-iam-policy-binding PROJECT_ID \
  --role=roles/source.reader \
  --member="serviceAccount:[e-mail]"

Replace PROJECT_ID with your organization's project ID, and replace PROJECT_NUMBER with your organization's project number.

GitHub App

Note: This authentication type is supported only in version 1.19.1 and later.

If your repository is in GitHub, you can use githubapp as your authentication type.

To use a GitHub App, complete the following steps:

1. Follow the instructions on GitHub to provision a GitHub App and give it permission to read from your repository.

2. Add the GitHub App configuration to a new Secret in the cluster:

   Using Client ID

   kubectl create ns config-management-system && \
   kubectl create secret generic git-creds \
     --namespace=config-management-system \
     --from-literal=github-app-client-id=CLIENT_ID \
     --from-literal=github-app-installation-id=INSTALLATION_ID \
     --from-file=github-app-private-key=/path/to/GITHUB_PRIVATE_KEY \
     --from-literal=github-app-base-url=BASE_URL
   

   • Replace CLIENT_ID with the client ID for the GitHub App.
   • Replace INSTALLATION_ID with the installation ID for the GitHub App.
   • Replace /path/to/GITHUB_PRIVATE_KEY with the name of the file containing the private key.
   • Replace BASE_URL with the base URL for the GitHub API endpoint. This is only needed when the repository is not hosted at www.github.com. The argument can otherwise be omitted and will default to https://api.github.com/.

   Using Application ID

   kubectl create ns config-management-system && \
   kubectl create secret generic git-creds \
     --namespace=config-management-system \
     --from-literal=github-app-application-id=APPLICATION_ID \
     --from-literal=github-app-installation-id=INSTALLATION_ID \
     --from-file=github-app-private-key=/path/to/GITHUB_PRIVATE_KEY \
     --from-literal=github-app-base-url=BASE_URL
   

   • Replace APPLICATION_ID with the application ID for the GitHub App.
   • Replace INSTALLATION_ID with the installation ID for the GitHub App.
   • Replace /path/to/GITHUB_PRIVATE_KEY with the name of the file containing the private key.
   • Replace BASE_URL with the base URL for the GitHub API endpoint. This is only needed when the repository is not hosted at www.github.com. The argument can otherwise be omitted and will default to https://api.github.com/.

3. Delete the private key from the local disk or otherwise protect it.

4. When you configure Config Sync and add the URL for your Git repository, use the githubapp auth type.

Grant Config Sync read-only access to OCI

Config Sync needs read-only access to your OCI image stored in Artifact Registry so that it can read the configs included in the image and apply them to your clusters.

If your image does not require authentication for read-only access, you can continue to configure Config Sync and use none as your authentication type. For example, if your image is public and can be accessed by anyone on the internet, then you don't need to authenticate.

However, most users need to create credentials to access restricted images. Config Sync supports the following mechanisms for authentication:

• Kubernetes service account (k8sserviceaccount)
• Google service account (gcpserviceaccount)

• Compute Engine default service account (gcenode)

Kubernetes service account

If you store your OCI image in Artifact Registry and your cluster uses GKE Workload Identity Federation for GKE or fleet Workload Identity Federation for GKE, you can use k8sserviceaccount as your authentication type in version 1.17.2 and later. This option is recommended over gcpserviceaccount due to its simplified configuration process.

1. Grant the Artifact Registry Reader (roles/artifactregistry.reader) IAM role to the Kubernetes service account with the Workload Identity Federation for GKE pool. For more information about Artifact Registry roles and permissions, see Configure roles and permissions for Artifact Registry.

   • Grant project-wide permission if the same permissions apply to all repositories in the project.

     gcloud projects add-iam-policy-binding PROJECT_ID \
           --role=roles/artifactregistry.reader \
           --member="serviceAccount:FLEET_HOST_PROJECT_ID.svc.id.goog[config-management-system/KSA_NAME]"
     

   • Grant repository-specific permission when you want service accounts to have different levels of access for each repository in your project.

     gcloud artifacts repositories add-iam-policy-binding REPOSITORY \
        --location=LOCATION \
        --role=roles/artifactregistry.reader \
        --member="serviceAccount:FLEET_HOST_PROJECT_ID.svc.id.goog[config-management-system/KSA_NAME]" \
        --project=PROJECT_ID
     

   Replace the following:

   • PROJECT_ID: the organization's project ID.
   • FLEET_HOST_PROJECT_ID: if you're using GKE Workload Identity Federation for GKE, this is the same as PROJECT_ID. If you're using fleet Workload Identity Federation for GKE, this is the project ID of the fleet that your cluster is registered to.
   • KSA_NAME: the Kubernetes service account for the reconciler.
     • For root repositories, if the RootSync name is root-sync, use root-reconciler. Otherwise, use root-reconciler-ROOT_SYNC_NAME. If you install Config Sync using the Google Cloud console or the Google Cloud CLI, Config Sync automatically creates a RootSync object named root-sync.
   • REPOSITORY: the ID of the repository.
   • LOCATION: the regional or multi-regional location of the repository.
   Note: Creating this policy binding requires the iam.serviceAccounts.setIamPolicy permission.

Google service account

If you store your OCI image in Artifact Registry and your cluster uses GKE Workload Identity Federation for GKE or fleet Workload Identity Federation for GKE, you can use gcpserviceaccount as your authentication type. Starting from version 1.17.2, it's recommended to use k8sserviceaccount instead. This option eliminates the extra steps of creating a Google service account and the associated IAM policy binding.

1. If you don't already have a service account, create a service account.

2. Grant the Artifact Registry Reader (roles/artifactregistry.reader) IAM role to the Google service account. For more information about Artifact Registry roles and permissions, see Configure roles and permissions for Artifact Registry.

   • Grant project-wide permission if the same permissions apply to all repositories in the project.

     gcloud projects add-iam-policy-binding PROJECT_ID  \
        --role=roles/artifactregistry.reader \
        --member="serviceAccount:GSA_NAME@PROJECT_ID.iam.gserviceaccount.com"
     

   • Grant repository-specific permission when you want service accounts to have different levels of access for each repository in your project.

     gcloud artifacts repositories add-iam-policy-binding REPOSITORY \
        --location=LOCATION \
        --role=roles/artifactregistry.reader \
        --member="serviceAccount:GSA_NAME@PROJECT_ID.iam.gserviceaccount.com" \
        --project=PROJECT_ID
     

3. Create an IAM policy binding between the Kubernetes service account and the Google service account by running the following command:

   gcloud iam service-accounts add-iam-policy-binding
     GSA_NAME@PROJECT_ID.iam.gserviceaccount.com \
       --role=roles/iam.workloadIdentityUser \
       --member="serviceAccount:FLEET_HOST_PROJECT_ID.svc.id.goog[config-management-system/KSA_NAME]" \
       --project=PROJECT_ID
   

Replace the following:

• PROJECT_ID: the organization's project ID.
• FLEET_HOST_PROJECT_ID: if you're using GKE Workload Identity Federation for GKE, this is the same as PROJECT_ID. If you're using fleet Workload Identity Federation for GKE, this is the project ID of the fleet that your cluster is registered to.
• GSA_NAME: the custom Google service account that you want to use to connect to Artifact Registry. The service account must have the Artifact Registry Reader (roles/artifactregistry.reader) IAM role.
• KSA_NAME: the Kubernetes service account for the reconciler.
  • For root repositories, if the RootSync name is root-sync, use root-reconciler. Otherwise, use root-reconciler-ROOT_SYNC_NAME. If you install Config Sync using the Google Cloud console or the Google Cloud CLI, Config Sync automatically creates a RootSync object named root-sync.
• REPOSITORY: the ID of the repository.
• LOCATION: the regional or multi-regional location of the repository.

Note: Creating this policy binding requires the iam.serviceAccounts.setIamPolicy permission.

Compute Engine default service account

If you store your Helm chart in Artifact Registry and your cluster is GKE with Workload Identity Federation for GKE disabled, you can use gcenode as your authentication type. Config Sync uses the Compute Engine default service account. You must grant your Compute Engine default service account reader access to Artifact Registry.

1. Grant the Compute Engine service account read permission to Artifact Registry by running the following command:

   gcloud projects add-iam-policy-binding PROJECT_ID \
      --member=serviceAccount:[e-mail] \
      --role=roles/artifactregistry.reader
   

   Replace PROJECT_ID with your organization's project ID, and replace PROJECT_NUMBER with your organization's project number.

Grant Config Sync read-only access to Helm

Config Sync needs read-only access to your Helm repository so that it can read the Helm charts in your repository and install them in your clusters.

If your repository does not require authentication for read-only access, you can continue to configure Config Sync and use none as your authentication type. For example, if your Helm repository is public and can be accessed by anyone on the internet, then you don't need to authenticate.

However, most users need to create credentials to access private Helm repositories. Config Sync supports the following mechanisms for authentication:

• Token (token)
• Kubernetes service account (k8sserviceaccount)
• Google service account (gcpserviceaccount)
• Compute Engine default service account (gcenode)

Note: Config Sync doesn't support configuring helm as the source type using the Google Cloud console or the Google Cloud CLI. You can configure your RootSync or RepoSync object to sync from a Helm repository using the Kubernetes API, or declare it in another source of truth. See Configuration for the Helm repository for more information.

Token

Create a Secret with a Helm repository username and password:

kubectl create secret generic SECRET_NAME \
    --namespace=config-management-system \
    --from-literal=username=USERNAME \
    --from-literal=password=PASSWORD

Replace the following:

• SECRET_NAME: the name that you want to give your Secret.
• USERNAME: the Helm repository username.
• PASSWORD: the Helm repository password.

When you Configure the ConfigManagement Operator, you will use the Secret name you chose for spec.helm.secretRef.name.

Kubernetes service account

If you store your Helm chart in Artifact Registry and your cluster uses GKE Workload Identity Federation for GKE or fleet Workload Identity Federation for GKE, you can use k8sserviceaccount as your authentication type in version 1.17.2 and later. This option is recommended over gcpserviceaccount due to its simplified configuration process.

1. Grant the Artifact Registry Reader (roles/artifactregistry.reader) IAM role to the Kubernetes service account with the Workload Identity Federation for GKE pool. For more information about Artifact Registry roles and permissions, see Configure roles and permissions for Artifact Registry.

   • Grant project-wide permission if the same permissions apply to all repositories in the project.

     gcloud projects add-iam-policy-binding PROJECT_ID \
        --role=roles/artifactregistry.reader \
        --member="serviceAccount:FLEET_HOST_PROJECT_ID.svc.id.goog[config-management-system/KSA_NAME]"
     

   • Grant repository-specific permission when you want service accounts to have different levels of access for each repository in your project.

     gcloud artifacts repositories add-iam-policy-binding REPOSITORY \
        --location=LOCATION \
        --role=roles/artifactregistry.reader \
        --member="serviceAccount:FLEET_HOST_PROJECT_ID.svc.id.goog[config-management-system/KSA_NAME]" \
        --project=PROJECT_ID
     

   Replace the following:

   • PROJECT_ID: the organization's project ID.
   • FLEET_HOST_PROJECT_ID: if you're using GKE Workload Identity Federation for GKE, this is the same as PROJECT_ID. If you're using fleet Workload Identity Federation for GKE, this is the project ID of the fleet that your cluster is registered to.
   • KSA_NAME: the Kubernetes service account for the reconciler.
     • For root repositories, if the RootSync name is root-sync, use root-reconciler. Otherwise, use root-reconciler-ROOT_SYNC_NAME.
   • REPOSITORY: the ID of the repository.
   • LOCATION: the regional or multi-regional location of the repository.

Note: Creating this policy binding requires the iam.serviceAccounts.setIamPolicy permission.

Google service account

If you store your Helm chart in Artifact Registry and your cluster uses GKE Workload Identity Federation for GKE or fleet Workload Identity Federation for GKE, you can use gcpserviceaccount as your authentication type. Starting from version 1.17.2, it's recommended to use k8sserviceaccount instead. This option eliminates the extra steps of creating a Google service account and the associated IAM policy binding.

1. If you don't already have a service account, create a service account.

2. Grant the Artifact Registry Reader (roles/artifactregistry.reader) IAM role to the Google service account. For more information about Artifact Registry roles and permissions, see Configure roles and permissions for Artifact Registry.

   • Grant project-wide permission if the same permissions apply to all repositories in the project.

     gcloud projects add-iam-policy-binding PROJECT_ID  \
           --role=roles/artifactregistry.reader \
           --member="serviceAccount:GSA_NAME@PROJECT_ID.iam.gserviceaccount.com"
     

   • Grant repository-specific permission when you want service accounts to have different levels of access for each repository in your project.

     gcloud artifacts repositories add-iam-policy-binding REPOSITORY \
        --location=LOCATION \
        --role=roles/artifactregistry.reader \
        --member="serviceAccount:GSA_NAME@PROJECT_ID.iam.gserviceaccount.com" \
        --project=PROJECT_ID
     

3. Create an IAM policy binding between the Kubernetes service account and the Google service account by running the following command:

   gcloud iam service-accounts add-iam-policy-binding
     GSA_NAME@PROJECT_ID.iam.gserviceaccount.com \
       --role=roles/iam.workloadIdentityUser \
       --member="serviceAccount:FLEET_HOST_PROJECT_ID.svc.id.goog[config-management-system/KSA_NAME]"
       --project=PROJECT_ID
   

Replace the following:

• PROJECT_ID: the organization's project ID.
• FLEET_HOST_PROJECT_ID: if you're using GKE Workload Identity Federation for GKE, this is the same as PROJECT_ID. If you're using fleet Workload Identity Federation for GKE, this is the project ID of the fleet that your cluster is registered to.
• GSA_NAME: the custom Google service account that you want to use to connect to Artifact Registry. The service account must have the Artifact Registry Reader (roles/artifactregistry.reader) IAM role.
• KSA_NAME: the Kubernetes service account for the reconciler.
  • For root repositories, if the RootSync name is root-sync, use root-reconciler. Otherwise, use root-reconciler-ROOT_SYNC_NAME.
• REPOSITORY: the ID of the repository.
• LOCATION: the regional or multi-regional location of the repository.

Note: Creating this policy binding requires the iam.serviceAccounts.setIamPolicy permission.

Compute Engine default service account

If you store your Helm chart in Artifact Registry and your cluster is GKE with Workload Identity Federation for GKE disabled, you can use gcenode as your authentication type. Config Sync uses the Compute Engine default service account. You must grant your Compute Engine default service account reader access to Artifact Registry. You might need to grant the storage-ro access scope to grant read-only permission to pull images.

1. Grant the Compute Engine service account read permission to Artifact Registry:

   gcloud projects add-iam-policy-binding PROJECT_ID \
       --member=serviceAccount:[e-mail] \
       --role=roles/artifactregistry.reader
   

   Replace PROJECT_ID with your organization's project ID, and replace PROJECT_NUMBER with your organization's project number.

Configure Config Sync

In this section, you configure the settings for your root repository. If you're syncing to a Git repository, you can use the Google Cloud console to guide you through the installation process and automate some steps.

When you install Config Sync using the Google Cloud console or the Google Cloud CLI, Config Sync automatically creates a RootSync object named root-sync. You can use kubectl commands to modify root-sync and add additional Config Sync configurations. To learn more, see Configure Config Sync with kubectl commands.

Console

Install Config Sync

To install Config Sync, all clusters must be registered to a fleet. When you install Config Sync in the Google Cloud console, selecting individual clusters automatically registers those clusters to your fleet.

1. In the Google Cloud console, go to the Config page under the Features section.

   Go to Config

2. Click Install Config Sync.
3. Select Auto-upgrades (Preview) to enable Config Sync to upgrade versions automatically or select Manual upgrades to manage the Config Sync version yourself. For more information about how auto-upgrades work, see Upgrade Config Sync.
4. Under Installation options, select one of the following options:
   • Install Config Sync on entire fleet (recommended): Config Sync will be installed on all clusters in the fleet.
   • Install Config Sync on individual clusters: all selected clusters will be automatically registered to a fleet. Config Sync will be installed on all clusters in the fleet.
5. If you're installing Config Sync on individual clusters, in the Available clusters table, select the clusters on which you want to install Config Sync.
6. Click Install Config Sync. In the Settings tab, after a few minutes, you should see Enabled in the Status column for the clusters in your fleet.

Deploy a package

After you have registered your clusters to a fleet and installed Config Sync, you can configure Config Sync to deploy a package to a cluster from a source of truth. You can deploy the same package to multiple clusters or deploy different packages to different clusters. You can edit a package after deploying it, except for some settings like package name and sync type. For more information, see Manage packages.

Note: If you want Config Sync to render and apply a Helm chart, you must configure Config Sync with the Google Cloud CLI instead.

To deploy a package, complete the following steps:

1. In the Google Cloud console, go to the Config Sync dashboard.

   Go to Config Sync dashboard

2. Click Deploy Package.

3. In the Select clusters for package deployment table, select the cluster that you want to deploy a package to and then click Continue.

4. Select either Package hosted on Git or Package hosted on OCI as your source type and then click Continue.

5. In the Package details section, enter a Package name, which identifies the RootSync or RepoSync object.

6. In the Sync type field, choose either Cluster scoped sync or Namespace scoped sync as the sync type.

   Cluster scoped sync creates a RootSync object and Namespace scoped sync creates a RepoSync object. For more information about these objects, see Config Sync architecture.

7. In the Source section, complete the following:

   • For sources hosted in a Git repository, enter the following fields:

     1. Enter the URL of the Git repository that you're using as a source of truth as the Repository URL.
     2. Optional: Update the Revision field to check out if you're not using the default HEAD.
     3. Optional: Update the Path field if you don't want to sync from the root repository.
     4. Optional: Update the Branch field if you're not using the default main branch.

   • For sources hosted in an OCI image, enter the following fields:

     1. Enter the URL of the OCI image that you're using as a source of truth as the Image.
     2. Enter the path of the directory to sync from, relative to the root directory, as the Directory.

8. (Optional): Expand the Advanced settings section to complete the following:

   1. Select an Authentication type. Config Sync needs read-only access to your source of truth to read the configuration files in the source and apply them to your clusters. Unless your source requires no authentication, such as a public repository, ensure that you grant Config Sync read-only access to your Git repository, OCI image, or Helm chart (gcloud CLI only). Choose the same authentication type that you configured when you installed Config Sync:

      Note: for OCI, you can only select Workload Identity for authentication.
      • None: Use no authentication.
      • SSH: Authenticate by using an SSH key pair.
      • Cookiefile: Authenticate by using a cookiefile.
      • Token: Authenticate by using an access token or password.
      • Google Cloud Repository: Use a Google service account to access a Cloud Source Repositories repository. Only select this option if Workload Identity Federation for GKE is not enabled in your cluster.
      • Workload Identity: Use a Google service account to access a Cloud Source Repositories repository.

   2. Enter a number in seconds to set the Sync wait time, which determines how long Config Sync waits between attempts to pull from the source of truth.

   3. Enter a Git proxy URL for the HTTPS proxy to be used when communicating with the source of truth.

   4. Choose Hierarchy to change the Source format.

      The default value Unstructured is recommended in most cases since it lets you organize your source of truth however you want.

9. Click Deploy Package.

   You are redirected to the Config Sync Packages page. After a few minutes, you should see Synced in the Sync status column for the cluster that you configured.

gcloud

Before you continue, make sure you've registered your clusters to a fleet.

1. Enable the ConfigManagement fleet feature:

   gcloud beta container fleet config-management enable
   

2. Prepare the configuration by either creating a new apply-spec.yaml manifest or by using an existing manifest. Using an existing manifest lets you configure your cluster with the same settings used by another cluster.

   Create new manifest

   To configure Config Sync with new settings for your cluster, create a file named apply-spec.yaml and copy the following YAML file into it.

   You can set all of the optional spec.configSync fields that you need when you create your manifest, and later use kubectl commands for configuration. You can also only set the spec.configSync.enabled field as true and omit the optional fields. You can then later use kubectl commands to create additional RootSync objects or RepoSyncs that you can fully manage using kubectl commands later.

   # apply-spec.yaml
   
   applySpecVersion: 1
   spec:
     # upgrades: UPGRADE_SETTING
     configSync:
       # Set to true to install and enable Config Sync
       enabled: true
       # If you don't have a source of truth yet, omit the
       # following fields. You can configure them later.
       sourceType: SOURCE_TYPE
       sourceFormat: FORMAT
       syncRepo: REPO
       syncRev: REVISION
       syncBranch: BRANCH
       secretType: SECRET_TYPE
       gcpServiceAccountEmail: EMAIL
       metricsGcpServiceAccountEmail: METRICS_EMAIL
       policyDir: DIRECTORY
       preventDrift: PREVENT_DRIFT
   

   Replace the following:

   • (Preview) UPGRADE_SETTING: un-comment the field and set to auto to configure Config Sync to automatically upgrade. Set to manual to manually upgrade Config Sync yourself. The default value is manual. This flag is supported only for GKE on Google Cloud clusters. To use this field, you might need to update the gcloud CLI by running gcloud components update.

     Caution: You can't disable auto-upgrades by setting the upgrades flag back to manual. To switch from auto-upgrades to manual upgrades, you need to uninstall Config Sync and reinstall it.

   • SOURCE_TYPE: add git to sync from a Git repository, oci to sync from an OCI image, or helm to sync from a Helm chart. If no value is specified, the default is git.

   • FORMAT: add unstructured to use an unstructured repository or add hierarchy to use a hierarchical repository. These values are case-sensitive. This field is optional and the default value is hierarchy. We recommend that you add unstructured, because this format lets you organize your configs in the way that is most convenient to you.

   • REPO: add the URL of the source of truth. Git and Helm repository URLs use either the HTTPS or SSH protocol. For example, https://github.com/GoogleCloudPlatform/anthos-config-management-samples. If you plan to use SSH as your secretType, enter your URL with the SSH protocol. This field is required and if you don't enter a protocol, the URL is treated as an HTTPS URL.

     OCI URLs use the following format: LOCATION-docker.pkg.dev/PROJECT_ID/REPOSITORY_NAME/PACKAGE_NAME. By default, the image is pulled from the latest tag, but you can pull in images by TAG or DIGEST instead. Specify TAG or DIGEST in the PACKAGE_NAME:

     • To pull by TAG: LOCATION-docker.pkg.dev/PROJECT_ID/REPOSITORY_NAME/PACKAGE_NAME:TAG
     • To pull by DIGEST: LOCATION-docker.pkg.dev/PROJECT_ID/REPOSITORY_NAME/PACKAGE_NAME@sha256:DIGEST
     Caution: Config Sync requires that the OCI layer is compressed in the tar or tar+gzip format. Other formats (for example, tar+bz2) won't be recognized by Config Sync. Switching from a valid REPO to an OCI image with an unsupported format will cause managed resources to be pruned without an error.

   • REVISION: the Git revision (tag or hash) to sync from. This field is optional and the default value is HEAD. Starting from Config Sync version 1.17.0, you can also specify a branch name in the syncRev field. When using a hash in version 1.17.0 or later, it must be a full hash, and not an abbreviated form.

   • BRANCH: the branch of the repository to sync from. This field is optional and the default is master. Starting from Config Sync version 1.17.0, it's recommended to use the syncRev field to specify a branch name for simplicity. If both the syncRev field and the syncBranch field are specified, syncRev takes precedence over syncBranch.

   • SECRET_TYPE: one of the following secretTypes:

     git

     • none: Use no authentication.
     • ssh: Use an SSH key pair.
     • cookiefile: Use a cookiefile.
     • token: Use a token.
     • gcpserviceaccount: Use a Google service account to access a Cloud Source Repositories. If you select this authentication type, you need to create an IAM policy binding after you finish configuring Config Sync. For details, see the Google service account tab of the Grant Config Sync read-only access to Git section.
     • gcenode: Use a Google service account to access a Cloud Source Repositories. Only select this option if Workload Identity Federation for GKE is not enabled in your cluster.
     • githubapp: Use a GitHub App to authenticate to a GitHub repository.

     For more information on these authentication types, see Granting Config Sync read-only access to Git.

     oci

     • none: Use no authentication
     • gcenode: Use the Compute Engine default service account to access an image in Artifact Registry. Only select this option if Workload Identity Federation for GKE is not enabled in your cluster.
     • gcpserviceaccount: Use a Google service account to access an image.

     helm

     • token: Use a token.
     • gcenode: Use the Compute Engine default service account to access an image in Artifact Registry. Only select this option if Workload Identity Federation for GKE is not enabled in your cluster.
     • gcpserviceaccount: Use a Google service account to access an image.

   • EMAIL: If you added gcpserviceaccount as your secretType, add your Google service account email address. For example, acm@PROJECT_ID.iam.gserviceaccount.com.

   • METRICS_EMAIL: the email of the Google Cloud Service Account (GSA) used for exporting Config Sync metrics to Cloud Monitoring. The GSA should have the Monitoring Metric Writer (roles/monitoring.metricWriter) IAM role. The Kubernetes ServiceAccount default in the namespace config-management-monitoring should be bound to the GSA.

   • DIRECTORY: the path of the directory to sync from, relative to the root of the Git repository. All sub-directories of the directory that you specify are included and synced to the cluster. The default value is the root directory of the repository.

   • PREVENT_DRIFT: If set to true, enables the Config Sync admission webhook to prevent drifts by rejecting conflicting changes from being pushed to live clusters. The default setting is false. Config Sync always remediates drifts no matter the value of this field.

   For a complete list of fields that you can add to the spec field, see gcloud fields.

   Note: If you don't have a source of truth prepared yet, you can enable Config Sync without configuring any settings by setting spec.configSync.enabled to true and omitting all other spec.configSync fields. When you have prepared your repository, edit your apply-spec.yaml to add the configuration settings.

   Use existing manifest

   To configure your cluster with the same settings used by another cluster, fetch the settings from a registered cluster:

   gcloud alpha container fleet config-management fetch-for-apply \
       --membership=MEMBERSHIP_NAME \
       --project=PROJECT_ID \
       > CONFIG_YAML_PATH
   

   Replace the following:

   • MEMBERSHIP_NAME: the membership name of the registered cluster that has the Config Sync settings you want to use
   • PROJECT_ID: your project ID
   • CONFIG_YAML_PATH: the path to the apply-spec.yaml file which contains the settings fetched from the cluster

3. Apply the apply-spec.yaml file. If you are using an existing manifest, you should apply the file to the cluster that you want to configure with the settings that you fetched in the previous command:

   gcloud beta container fleet config-management apply \
       --membership=MEMBERSHIP_NAME \
       --config=CONFIG_YAML_PATH \
       --project=PROJECT_ID
   

   Replace the following:

   • MEMBERSHIP_NAME: the fleet membership name that you chose when you registered your cluster. You can find the name with gcloud container fleet memberships list.
   • CONFIG_YAML_PATH: the path to your apply-spec.yaml file.
   • PROJECT_ID: your project ID.

Terraform

For each cluster that you want to configure Config Sync, apply a google_gkehub_feature_membership resource block that contains a configmanagement and config_sync block:

Note: You can use Terraform to configure Config Sync as a fleet default for new clusters. For more information, see the Configure fleet-level defaults section of this page.

git

resource "google_container_cluster" "cluster" {
 name = "EXISTING_CLUSTER_NAME"
 location = "EXISTING_CLUSTER_LOCATION"
}

resource "google_gke_hub_membership" "membership" {
 membership_id = "MEMBERSHIP_ID"
 endpoint {
   gke_cluster {
     resource_link = "//container.googleapis.com/${google_container_cluster.cluster.id}"
   }
 }
}

resource "google_gke_hub_feature" "feature" {
 name = "configmanagement"
 location = "global"
}

resource "google_gke_hub_feature_membership" "feature_member" {
 location = "global"
 feature = google_gke_hub_feature.feature.name
 membership = google_gke_hub_membership.membership.membership_id
 configmanagement {
   version = "VERSION"
   config_sync {
     # The field `enabled` was introduced in Terraform version 5.41.0, and
     # needs to be set to `true` explicitly to install Config Sync.
     enabled = true
     git {
       sync_repo = "REPO"
       sync_branch = "BRANCH"
       policy_dir = "DIRECTORY"
       secret_type = "SECRET"
     }
   }
 }
}

Replace the following:

• EXISTING_CLUSTER_NAME: the name of your existing cluster.
• EXISTING_CLUSTER_LOCATION: the location of your existing cluster.
• MEMBERSHIP_ID: the membership binding ID.
• VERSION: (optional) the Config Sync version number. Must be set to version 1.17.0 or later. If left blank, the default is the latest version.
• REPO: the URL to the repository containing your configuration files.
• BRANCH: the repository branch, for example main.
• DIRECTORY: the path within the Git repository that represents the top level of the repository you want to sync.
• SECRET: the secret auth type.

oci

resource "google_container_cluster" "cluster" {
 name = "EXISTING_CLUSTER_NAME"
 location = "EXISTING_CLUSTER_LOCATION"
}

resource "google_gke_hub_membership" "membership" {
 membership_id = "MEMBERSHIP_ID"
 endpoint {
   gke_cluster {
     resource_link = "//container.googleapis.com/${google_container_cluster.cluster.id}"
   }
 }
}

resource "google_gke_hub_feature" "feature" {
 name = "configmanagement"
 location = "global"
}

resource "google_gke_hub_feature_membership" "feature_member" {
 location = "global"
 feature = google_gke_hub_feature.feature.name
 membership = google_gke_hub_membership.membership.membership_id
 configmanagement {
   version = "VERSION"
   config_sync {
     # The field `enabled` was introduced in Terraform version 5.41.0, and
     # needs to be set to `true` explicitly to install Config Sync.
     enabled = true
     oci {
       sync_repo = "REPO"
       policy_dir = "DIRECTORY"
       secret_type = "SECRET"
     }
   }
 }
}

Replace the following:

• EXISTING_CLUSTER_NAME: the name of your existing cluster.
• EXISTING_CLUSTER_LOCATION: the location of your existing cluster.
• MEMBERSHIP_ID: the membership binding ID.
• VERSION: (optional) the Config Sync version number. If left blank, the default is the latest version.
• REPO: the URL to the OCI image repository containing your configuration files.
• DIRECTORY: the absolute path of the directory containing the resources you want to sync. Leave blank to use the root directory.
• SECRET: the secret auth type.

Repeat this process for each cluster that you want to sync.

After you have finished configuring your root repository, you can optionally choose to configure syncing from multiple repositories, including other root repositories and namespace repositories. The namespace repositories are helpful if you want a repository that contains namespace-scoped configs synced to a particular namespace across clusters.

Configure fleet-level defaults

If you have enabled Google Kubernetes Engine (GKE) Enterprise edition, you can enable and configure Config Sync as a fleet-level default for your clusters. This means that every new GKE on Google Cloud cluster created in the fleet will have Config Sync enabled on the cluster with the settings you specify. You can find out more about fleet default configuration in Manage fleet-level features.

If you use only the Google Cloud console, you can enable Config Sync by default on your clusters and set the Config Sync version for your fleet. If you use gcloud CLI or Terraform, you can enable Config Sync by default on your clusters, set the Config Sync version for your fleet, and set up the connection to your Git repository or OCI image repository.

Note: To configure your source of truth across your fleet using the Google Cloud console, use the Deploy packages feature.

To configure fleet-level defaults for Config Sync, complete the following steps:

gcloud

Run the enable command for the feature, passing the apply-spec.yaml configuration file that you created when you configured Config Sync on an individual cluster:

gcloud beta container fleet config-management enable \
    --fleet-default-member-config=apply-spec.yaml

You can use this command to update your fleet default settings at any time. If you update your fleet default settings, you must re-sync your existing clusters to the default settings.

Console

1. In the Google Cloud console, go to the Feature Manager page.

   Go to Feature Manager

2. In the Config Sync pane, click Configure.

3. Review your fleet-level settings. All new clusters you create in the fleet inherit these settings.

4. Optional: To change the default settings, click Customize fleet settings. In the dialog that appears, do the following:

5. Select Auto-upgrades (Preview) to have Config Sync upgrade versions automatically or select Manual upgrades to manage the Config Sync version yourself. For more information about how auto-upgrades work, see Upgrade Config Sync.

6. If you selected Manual upgrades, in the Version list, select the Config Sync version that you want to use.

7. Click Save changes.

8. Click Configure.

9. In the Configuring fleet settings confirmation dialog, click Confirm. If you haven't previously enabled Config Sync, clicking Confirm also enables the anthosconfigmanagement.googleapis.com API.

Terraform

1. Create a directory for the fleet-default configuration Terraform files. To that directory, add a main.tf file with the following resource that configures Config Sync's settings:

   git

   terraform {
     required_providers {
       google = {
         source = "hashicorp/google"
         version = ">=5.16.0"
         }
       }
     }
   
   provider "google" {
     project = "PROJECT_ID"
   }
   
   resource "google_gke_hub_feature" "feature" {
     name = "configmanagement"
     location = "global"
     provider = google
     fleet_default_member_config {
       configmanagement {
       version = "VERSION"
       config_sync {
       source_format = "unstructured"
         git {
           sync_repo = "REPO"
           sync_branch = "BRANCH"
           policy_dir = "DIRECTORY"
           secret_type = "SECRET"
         }
       }
       }
     }
   }
   

   Replace the following:

   • PROJECT_ID: the fleet host project ID.
   • VERSION: (optional) the Config Sync version number. If left blank, the default is the latest version.
   • REPO: the URL to the repository containing your configuration files.
   • BRANCH: the repository branch, for example main.
   • DIRECTORY: the path within the Git repository that represents the top level of the repository you want to sync.
   • SECRET: the secret auth type.

   For a full list of settings supported in the Config Sync git block, see the Terraform reference documentation for GKE hub features.

   OCI

   terraform {
     required_providers {
       google = {
         source = "hashicorp/google"
         version = ">=5.16.0"
         }
       }
     }
   
   provider "google" {
     project = "PROJECT_ID"
   }
   
   resource "google_gke_hub_feature" "feature" {
     name = "configmanagement"
     location = "global"
     provider = google
     fleet_default_member_config {
       configmanagement {
       version = "VERSION"
       config_sync {
       source_format = "unstructured"
         oci {
           sync_repo = "REPO"
           policy_dir = "DIRECTORY"
           secret_type = "SECRET"
         }
       }
       }
     }
   }
   

   Replace the following:

   • PROJECT_ID: the fleet host project ID.
   • VERSION: the Config Sync version number. Must be set to version 1.17.0 or later. If left blank, the default is the latest version.
   • REPO: the URL to the OCI image repository containing configuration files.
   • DIRECTORY: the absolute path of the directory containing the resources you want to sync. Leave blank to use the root directory.
   • SECRET: the secret auth type.

   For a full list of settings supported in the Config Sync oci block, see the Terraform reference documentation for GKE hub features.

2. Initialize Terraform in the directory that you created:

   terraform init
   

3. Check that the changes you propose with Terraform match the expected plan:

   terraform plan
   

4. Create the default fleet member configurations:

   terraform apply
   

To update existing clusters to use your default Config Sync settings, you can use the Google Cloud console or gcloud CLI to sync selected fleet clusters to your fleet defaults. Alternatively, you can manually configure each cluster with the same settings using Terraform by following the instructions for configuring Config Sync. If you previously used Terraform to specify fleet defaults, use the same configmanagement and config_sync block that you used to set the defaults to configure your chosen clusters.

To sync Config Sync default settings across your fleet, follow these steps:

gcloud

1. Sync an existing membership to the fleet default configuration:

   gcloud beta container fleet config-management apply \
       --origin=FLEET \
       --membership=MEMBERSHIP_NAME
   

   Replace MEMBERSHIP_NAME with the fleet membership name of the cluster that you want to sync with the fleet default configuration.

2. Confirm that your membership configurations are synced with the fleet default:

   gcloud beta container fleet config-management status
   

   The output of this command should display as Yes for the Synced_to_Fleet_Default status for the membership that you synced.

console

1. Go to Feature Manager:

   Go to Feature Manager: Config Sync

2. In the cluster table, select the clusters that you want to sync to fleet settings.

3. Click Sync to fleet settings.

To disable Config Sync default settings across your fleet, follow these steps:

1. To disable the fleet default configuration, run the following command:

   gcloud beta container fleet config-management disable --fleet-default-member-config
   

2. Confirm that the fleet default configuration is disabled:

   gcloud beta container fleet config-management status
   

The Config Sync default settings are applied to any clusters that you select. Although the Google Cloud console shows only a subset of settings, like the Config Sync version, all fleet-level settings are synced to the clusters. For example, if you configure Config Sync to sync to a a Git repository by using Terraform or the gcloud CLI, that setting is synced to your clusters, but is not shown in the Google Cloud console.

Verify the installation

After you have installed and configured Config Sync, you can verify that the installation completed successfully.

Console

Complete the following steps:

1. In the Google Cloud console, go to the Config page under the Features section.

   Go to Config

2. On the Packages tab, check the Sync status column in the cluster table. A successful installation of Config Sync has a status of Installed. A successfully configured source of truth has a status of Synced.

gcloud

Run the following command:

gcloud beta container fleet config-management status \
    --project=PROJECT_ID

Replace PROJECT_ID with your project's ID.

A successful installation has a status of SYNCED. Starting in Config Sync version 1.18.0, the output also displays which version of Config Sync is installed and Config Sync's upgrade setting.

If you see an error after running the preceding command, make sure that you created the git-creds Secret. If you have created the Secret, try rerunning the following command:

gcloud beta container fleet config-management apply

You can also use the nomos status command to check if the Config Sync is installed successfully. A valid installation with no problems has a status of PENDING or SYNCED. An invalid or incomplete installation has a status of NOT INSTALLED OR NOT CONFIGURED. The output also includes any reported errors.

Role-based access controls (RBAC) and permissions

Config Sync includes highly-privileged workloads. The following table lists permissions for these workloads:

Component	Namespace	Service Account	Permissions	Description
ConfigManagement Operator	config-management-system	config-management-operator	cluster-admin	ConfigManagement Operator installs the other components in this table. Some of those components require cluster-admin permissions, so ConfigManagement Operator requires them as well.
Config Sync	config-management-system			See Config Sync permissions for required permissions.

Resource requests

The following section lists the resource requests for Config Sync.

The following table lists Kubernetes resource requirements for Config Sync components. For more information, see Managing Resources for Containers in the Kubernetes documentation.

Not all components listed are created. The following conditions cause each component to be scheduled:

• config-management-operator is installed when Config Sync is enabled.
• reconciler-manager is installed when Config Sync is enabled.
• admission-webhook is installed when drift prevention is enabled.
• a reconciler is installed for each RootSync and RepoSync.
• otel-collector is installed when Config Sync is enabled.

To learn more about these components, see Config Sync architecture.

1.18

Deployment name	CPU request (m) per replica	Memory request (Mi) per replica
config-management-operator	100	200
resource-group-controller-manager	110	300
admission-webhook^1	10	100
otel-collector	200	400
reconciler-manager	20	150
reconciler (one per RootSync and RepoSync)	See reconciler deployment for details.

¹ The admission webhook has two replicas, so when calculating the total resource requests, you need to double the value if you are using the admission webhook. The admission webhook is disabled by default.

1.17

Deployment name	CPU request (m) per replica	Memory request (Mi) per replica
config-management-operator	100	200
resource-group-controller-manager	110	300
admission-webhook^1	10	100
otel-collector	200	400
reconciler-manager	20	150
reconciler (one per RootSync and RepoSync)	See reconciler deployment for details.

¹ The admission webhook has two replicas, so when calculating the total resource requests, you need to double the value if you are using the admission webhook. The admission webhook is disabled by default.

1.16

Deployment name	CPU request (m) per replica	Memory request (Mi) per replica
config-management-operator	100	200
resource-group-controller-manager	110	300
admission-webhook^1	10	100
otel-collector	200	400
reconciler-manager	20	150
reconciler (one per RootSync and RepoSync)	See reconciler deployment for details.

¹ The admission webhook has two replicas, so when calculating the total resource requests, you need to double the value if you are using the admission webhook. The admission webhook is disabled by default.

Reconciler deployment

For each RootSync and RepoSync object, Config Sync creates an independent reconciler deployment to handle syncing. The reconciler deployment consists of multiple containers. To learn more about these containers, see Reconciler containers.

In Config Sync version 1.17.0 and later, the default resource requests for reconcilers are different for Standard and Autopilot clusters. All other cluster types use the Standard defaults.

Standard clusters

1.18

Container name	CPU request (m)	Memory request (Mi)
reconciler	50	200
otel-agent	10	100
hydration-controller (Optional)	10	100
git-sync	10	16
gcenode-askpass-sidecar (Optional)	10	20
helm-sync	75	128
oci-sync	25	32

1.17

Container name	CPU request (m)	Memory request (Mi)
reconciler	50	200
otel-agent	10	100
hydration-controller (Optional)	10	100
git-sync	10	16
gcenode-askpass-sidecar (Optional)	10	20
helm-sync	75	128
oci-sync	25	32

1.16

Container name	CPU request (m)	Memory request (Mi)
reconciler	50	200
otel-agent	10	100
hydration-controller (Optional)	10	100
git-sync	10	200
gcenode-askpass-sidecar (Optional)	10	20
helm-sync	50	256
oci-sync	10	200

Autopilot clusters

1.18

Container name	CPU request and limit (m)	Memory request and limit (Mi)
reconciler	700	512
otel-agent	10	64
hydration-controller (Optional)	200	256
git-sync	20	32
gcenode-askpass-sidecar (Optional)	50	64
helm-sync	250	384
oci-sync	50	64

1.17

Container name	CPU request and limit (m)	Memory request and limit (Mi)
reconciler	700	512
otel-agent	10	64
hydration-controller (Optional)	200	256
git-sync	20	32
gcenode-askpass-sidecar (Optional)	50	64
helm-sync	150	256
oci-sync	50	64

1.16

In Config Sync versions earlier than 1.17.0, the resource requests are the same for Standard and Autopilot.

To learn how to override the defaults resource requests and limits, see resource overrides.

Bundled Helm and Kustomize versions

Config Sync leverages the Helm and Kustomize executables to render the configurations under the hood. The following table provides a list of Config Sync versions that support the rendering feature, alongside the bundled Helm and Kustomize versions.

Config Sync versions	Helm version	Kustomize version
1.18.0	v3.14.3	v5.3.0
1.17.1 and 1.17.3	v3.13.3	v5.3.0
1.16.3 and 1.17.0	v3.13.1	v5.1.1
1.16.1 and 1.16.2	v3.12.3	v5.1.1
1.16.0	v3.12.2	v5.1.1
1.15.3	v3.12.2	v5.1.0
1.15.1 to 1.15.2	v3.11.3	v5.0.3
1.15.0	v3.11.3	v5.0.1
1.11.0 to 1.14.3	v3.6.3	v4.5.2

For information about rendering Helm through Kustomize, see Configure Kubernetes with Kustomize. For information about using the Helm API, see Syncing Helm charts from Artifact Registry.

What's next

• Learn how to upgrade Config Sync.
• Learn more about the gcloud commands for configuring Config Sync.
• Discover how to configure syncing from multiple repositories.
• Use the nomos command.
• Read the Introduction to troubleshooting Config Sync.
• Learn how to uninstall Config Sync.
• Review the Default Config Sync permissions.