Installing Anthos Config Management

Anthos Config Management lets cluster operators manage Kubernetes deployments by using files, called configs, stored in Git repositories.

This page shows you how to enable and configure Anthos Config Management. Follow these steps to install and configure Anthos Config Management in each cluster that you want to manage.

For instructions about how to install Anthos Config Management components, see Installing Config Connector, Installing Hierarchy Controller, and Installing Policy Controller.

Before you begin

Before you install Anthos Config Management, make sure that you have prepared your environment, clusters, and roles and enabled Anthos Config Management.

Preparing your local environment

Prepare your local environment by completing the following tasks:

  1. Enable the Anthos API for your project:

    Console

    In the Google Cloud Console, go to the Anthos API page.

    Go to the Anthos API page

    • Click Enable.

    gcloud

    Run the following command:

    gcloud services enable anthos.googleapis.com
    
  2. Install and initialize the Cloud SDK, which provides the gcloud, gsutil, kubectl, and nomos commands used in these instructions. If you use Cloud Shell, the Cloud SDK comes pre-installed.

  3. kubectl is not installed by default by the Cloud SDK. To install kubectl, use the following command:

    gcloud components install kubectl
    
  4. Use the gcloud auth login command to authenticate to Google Cloud so that you can download components of Anthos Config Management.

Preparing your cluster

Prepare your cluster by completing the following tasks:

  1. Ensure that your cluster is on an Anthos supported platform and version.

  2. Register your cluster to an Anthos environ by using Connect. Your project's environ provides a unified way to view and manage your clusters and their workloads as part of Anthos, including clusters outside Google Cloud. Anthos charges apply only to your registered clusters.

Preparing permissions

Depending on the installation method that you use, you need to grant the user that is installing Anthos Config Management different permissions. To learn how to grant Identity and Access Management (IAM) roles, see Granting, changing, and revoking access to resources.

Console

The Google Cloud user installing Anthos Config Management needs the GKE Hub Admin (roles/gkehub.admin) role to administer your cluster through the Hub API.

gcloud

The Google Cloud user installing Anthos Config Management needs the GKE Hub Admin (roles/gkehub.admin) role to administer your cluster through the Hub API.

kubectl

If you are using GKE, the Google Cloud user installing Anthos Config Management needs IAM permissions to create new roles in your cluster.

For example:

gcloud container clusters get-credentials CLUSTER_NAME

kubectl create clusterrolebinding cluster-admin-binding \
  --clusterrole cluster-admin --user USER_ACCOUNT

Replace the following:

  • CLUSTER_NAME: your cluster name
  • USER_ACCOUNT: your Google Cloud account's email address

Depending on how you configured the gcloud command-line tool on your local system, you might need to add the --project and --zone fields.

Enabling Anthos Config Management

If you are using Anthos Config Management for the first time, enable the feature by completing the following steps.

Console

  1. In the Google Cloud Console, go to the Anthos Features page.

    Go to the Anthos Features page

  2. In the Config Management row, click Enable.

  3. In the confirmation window, click Enable Config Management.

gcloud

Run the following command:

 gcloud alpha container hub config-management enable

Installing Anthos Config Management

In the following sections, you grant Anthos Config Management access to your repository. After you have granted access, you configure the installation.

Granting Anthos Config Management read-only access to Git

Anthos Config Management 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 credentials are required, they are stored in the git-creds Secret on each enrolled cluster.

If your repository does not require authentication for read-only access, you can continue to configure Anthos Config Management and set secretType to none. 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 do not need to authenticate. In this case, you do not need to create a git-creds Secret.

However, most users need to create credentials because read access to their repository is restricted. Anthos Config Management supports the following mechanisms for authentication:

  • SSH key pair
  • cookiefile
  • Token
  • Google Service Account (Google Source Repositories only)

The mechanism that you choose depends on what your repository supports. If all mechanisms are available, we recommend using an SSH key pair. GitHub, Cloud Source Repositories, and Bitbucket all support using an SSH key pair. If your organization hosts your repository and you don't know which authentication methods are supported, contact your administrator.

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.

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

  1. Create an SSH key pair to allow Anthos Config Management 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 Anthos Config Management 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.

  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:

  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. Delete the private key from the local disk or otherwise protect it.

cookiefile

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.

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

    Replace /path/to/COOKIEFILE with the appropriate path and filename.

  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 Anthos Config Management, you can use GitHub's personal access tokens (PATs) 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 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.

    • Bitbucket: Create an app password.

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

    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
  3. Protect the token if you still need it locally. Otherwise, delete it.

Google Service Account

If your repository is in Cloud Source Repositories, you can use secretType: gcenode to give Anthos Config Management access to a repository in the same project as your managed cluster.

Prerequisites

Before you begin, ensure that the following prerequisites are met:

  • Access scopes for the nodes in the cluster must include cloud-source-repos-ro. By default, the Compute Engine default service account PROJECT_ID-compute@developer.gserviceaccount.com has source.reader access to the repository for the same project, but if needed, you can add the role with the following command:

    gcloud projects add-iam-policy-binding PROJECT_ID \
      --member serviceAccount:PROJECT_NUMBER-compute@developer.gserviceaccount.com \
      --role roles/source.reader
    

    Replace the following:

    • PROJECT_ID: your organization's project ID
    • PROJECT_NUMBER: your organization's project number
  • Access scopes for the nodes in the cluster must include cloud-source-repos-ro. You can add this scope by including cloud-source-repos-ro in the --scopes list specified at cluster creation time, or by using the cloud-platform scope at cluster creation time:

    gcloud container clusters create example-cluster --scopes=cloud-platform
    

Using Cloud Source Repositories as your SyncRepo

After these prerequisites are met, set spec.git.syncRepo for the URL of the wanted repository in Cloud Source Repositories when you configure the Config Management Operator.

To use a repository in Cloud Source Repositories as your SyncRepo, complete the following steps:

  1. List all repositories:

    gcloud source repos list
    
  2. From the output, copy the URL from the repository that you want to use:

    REPO_NAME  PROJECT_ID  URL
    my-repo    my-project  https://source.developers.google.com/p/my-project/r/my-repo-csr
    
  3. Add the URL as your syncRepo. For example:

    spec.git.syncRepo: https://source.developers.google.com/p/my-project/r/my-repo-csr
    

Using Cloud Source Repositories with Workload Identity

If Workload Identity is enabled on your cluster, additional steps are required to use secretType: gcenode. After completing the preceding steps, and configuring Anthos Config Management (which you do in the following section) 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 Anthos Config Management for the first time.

This binding allows the Anthos Config Management Kubernetes service account to act as the Compute Engine default service account:

gcloud iam service-accounts add-iam-policy-binding \
  --role roles/iam.workloadIdentityUser \
  --member "serviceAccount:PROJECT_ID.svc.id.goog[config-management-system/importer]" \
  PROJECT_ID-compute@developer.gserviceaccount.com

Replace PROJECT_ID with your organization's project ID.

After you've created the binding, add an annotation to the Anthos Config Management Kubernetes service account using the email address of the Compute Engine default service account:

kubectl annotate serviceaccount -n config-management-system importer \
  iam.gke.io/gcp-service-account=PROJECT_NUMBER-compute@developer.gserviceaccount.com

Replace PROJECT_NUMBER with your organization's project number.

Configuring Anthos Config Management

The Google Cloud Console guides you through the installation process and automates many of the steps. You can also use the gcloud command-line tool or kubectl commands to complete the installation.

If you are using a GKE cluster, we recommend that you use the Cloud Console to configure Anthos Config Management. If you are using a GKE on-prem cluster, you should use kubectl commands to install Anthos Config Management because private registries aren't supported in the Cloud Console or the gcloud tool.

To configure Anthos Config Management, complete the following steps.

Console

  1. In the Cloud Console, go to the Anthos Config Management page.

    Go to the Anthos Config Management page

  2. Select your registered clusters and click Configure.

  3. In the Git Repository Authentication for ACM section, select one of the following options:

    • None
    • SSH
    • Cookiefile
    • Token
    • Google Cloud Repository

    If you have not done so already, grant Anthos Config Management read-only access to Git.

  4. Click Continue.

  5. In the ACM settings for your clusters section, complete the following:

    1. In the Version field, select the version for Anthos Config Management.
    2. Select the Enable Config Sync checkbox.
      1. In the URL field, add the URL of the Git repository to use as the source of truth. This field is required.
      2. In the Branch field, add the branch of the repository to sync from. The default is the main (master) branch. This field is required.
      3. In the Tag/Commit field, add the Git revision (tag or hash) to check out. The default is HEAD.
      4. In the Policy directory field, add the path within the repository to the top of the policy hierarchy to sync. The default is the root directory of the repository.
      5. In the Sync wait field, add the period in seconds between consecutive syncs. The default is 15 seconds.
      6. In the Git proxy field, enter the URL for the HTTPS proxy to be used when communicating with the Git repository. This is an optional field, and if it's left blank, no proxy is used.
      7. In the Source format field, choose whether the repository has a hierarchy or is unstructured.
  6. Click Done. You are taken back to the Anthos Config Management page. After a few minutes, you should see Synced in the status column next to the clusters that you configured. If you see Error, click on the word Error for more information.

gcloud

  1. Create a file named config-management.yaml and copy the following YAML file into it:

    # config-management.yaml
    
    apiVersion: configmanagement.gke.io/v1
    kind: ConfigManagement
    metadata:
      name: config-management
    spec:
      git:
        syncRepo: REPO
        syncBranch: BRANCH
        secretType: TYPE
        policyDir: "DIRECTORY"
    

    Replace the following:

    • REPO: the URL of the Git repository to use as the source of truth. This field is required.
    • BRANCH: the branch of the repository to sync from. The default is the main (master) branch. This field is required.
    • TYPE: one of the following SecretTypes:

      • none
      • ssh
      • cookiefile
      • token
      • gcenode
    • DIRECTORY: the path within the repository to the top of the policy hierarchy to sync. The default is the root directory of the repository.

      For a complete list of fields that you can add to the spec field, see the following Configuration for the Git repository section. Do not change configuration values outside the spec field.

  2. Apply the config-management.yaml file:

     gcloud alpha container hub config-management apply \
         --membership=CLUSTER_NAME \
         --config=CONFIG_YAML_PATH \
         --project=PROJECT_ID
    

    Replace the following:

    • CLUSTER_NAME: the name of the registered cluster that you want to apply this configuration to
    • CONFIG_YAML_PATH: the path to your config-management.yaml file
    • PROJECT_ID: your project ID

kubectl

When you install Anthos Config Management with kubectl, you need to deploy the Operator before you can configure it. The Operator is a controller that manages Anthos Config Management in a Kubernetes cluster.

Deploying the Operator

After ensuring that you meet all the prerequisites, you can deploy the Operator by downloading and applying a YAML manifest.

  1. Download the latest version of the Operator CustomResourceDefinition (CRD) by using the following command. To download a specific version instead, see Downloads.

    gsutil cp gs://config-management-release/released/latest/config-management-operator.yaml config-management-operator.yaml
    
  2. Apply the CRD:

    kubectl apply -f config-management-operator.yaml

If this command fails, see Troubleshooting.

Configuring Anthos Config Management

To configure the behavior of Anthos Config Management, create a configuration file for the ConfigManagement CustomResource, and then apply it by using the kubectl apply command:

  1. Create a file named config-management.yaml and copy the following YAML file into it.

    # config-management.yaml
    
    apiVersion: configmanagement.gke.io/v1
    kind: ConfigManagement
    metadata:
      name: config-management
    spec:
      # clusterName is required and must be unique among all managed clusters
      clusterName: CLUSTER_NAME
      git:
        syncRepo: REPO
        syncBranch: BRANCH
        secretType: TYPE
        policyDir: "DIRECTORY"
    

    Replace the following:

    • CLUSTER_NAME: the name of the registered cluster that you want to apply this configuration to
    • REPO: the URL of the Git repository to use as the source of truth. This field is required.
    • BRANCH: the branch of the repository to sync from. The default is the main (master) branch. This field is required.
    • TYPE: one of the following SecretTypes:

      • none
      • ssh
      • cookiefile
      • token
      • gcenode
    • DIRECTORY: the path within the repository to the top of the policy hierarchy to sync. The default is the root directory of the repository.

    For a complete list of fields that you can add to the spec field, see the following Configuration for the Git repository section. Do not change configuration values outside the spec field.

  2. Apply the configuration with the kubectl apply command:

    kubectl apply -f config-management.yaml
    

    You might need to create separate configuration files for each cluster or each type of cluster. You can specify the cluster using the --context option:

    kubectl apply -f config-management1.yaml --context=CLUSTER_NAME
    

    Replace CLUSTER_NAME with the name of the cluster that you want to use.

Verifying the installation

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

Console

  1. In the Cloud Console, go to the Anthos Config Management page.

    Go to the Anthos Config Management page

  2. View the Status column. A successful installation has a status of Synced.

For a detailed view of your cluster status:

  • Select the cluster that you want to explore. The Cluster details page appears. On this page, you can see details for your cluster and details for your Anthos Config Management installation.

gcloud

Run the following command:

gcloud alpha container hub config-management status
    --project=PROJECT_ID

Replace PROJECT_ID with your project's ID.

A successful installation has a status of SYNCED. 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 alpha container hub config-management apply

kubectl

To check whether Anthos Config Management is installed successfully, you can use the nomos status command. 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.

When Anthos Config Management is deployed successfully, it runs in a Pod whose name begins with config-management-operator in the kube-system namespace. The Pod might take a few moments to initialize.

Verify that the Pod is running:

kubectl -n kube-system get pods | grep config-management

If the Pod is running, the command's response is similar to the following example:

config-management-operator-6f988f5fdd-4r7tr 1/1 Running 0 26s

You can also verify that the config-management-system namespace exists:

kubectl get ns | grep 'config-management-system'

The command's output is similar to the following example:

config-management-system Active 1m

If the commands don't return output similar to the preceding example, view the logs to see what went wrong:

kubectl -n kube-system logs -l k8s-app=config-management-operator

You can also use kubectl get events to check whether Anthos Config Management has created any events.

kubectl get events -n kube-system

It's possible to have an invalid configuration that isn't detected right away, such as a missing or invalid git-creds Secret. For troubleshooting steps, see Valid but incorrect ConfigManagement object in the Troubleshooting section of this page.

Upgrading Anthos Config Management versions

This section provides general instructions for upgrading to a new version. Before upgrading, check the release notes for any specific instructions.

Console

  1. In the Cloud Console, go to the Anthos Config Management page.

    Go to the Anthos Config Management page

  2. Select the clusters that you want to upgrade.

  3. Click Configure.

  4. Click ACM settings for your clusters.

  5. From the Version dropdown, select the version that you want to upgrade to.

  6. Click Done.

kubectl

Run these commands for each enrolled cluster.

  1. Download the Anthos Config Management manifest and nomos commands for the new version.

  2. Apply the Anthos Config Management manifest:

    kubectl apply -f config-management-operator.yaml
    

    This command updates the Anthos Config Management image. Kubernetes retrieves the new version and restarts the Anthos Config Management Pod using the new version. When Anthos Config Management starts, it runs a reconcile loop that applies the set of manifests bundled in the new image. This updates and restarts each component Pod.

  3. Replace the nomos or nomos.exe command on all clients with the new version. This change ensures that the nomos command can always get the status of all enrolled clusters and can validate configs for them.

Uninstalling Anthos Config Management from a cluster

Follow these instructions to uninstall Anthos Config Management from a cluster. You must follow these steps for each cluster that you no longer want to manage with Anthos Config Management.

Console

  1. In the Google Cloud Console, go to the Anthos Features page.

    Go to the Anthos Features page

  2. In the Config Management row of the Features table, click Details. The Status summary page appears.

  3. Click Disable config management. A confirmation page appears.

  4. On the confirmation page, click Disable config management.

gcloud

Run the following command:

gcloud alpha container hub config-management delete \
    --project=PROJECT_ID \
    --membership=CLUSTER_NAME

Replace the following:

  • CLUSTER_NAME: the name of the registered cluster that you want to apply this configuration to
  • PROJECT_ID: your project ID

To delete all Anthos Config Management configurations and statuses, run the following command:

gcloud alpha container hub config-management disable \
    --project=PROJECT_ID

Replace PROJECT_ID with your project ID.

kubectl

  1. Delete the ConfigManagement object from the cluster:

    kubectl delete configmanagement --all
    

    The following things happen:

    • Any ClusterRoles and ClusterRoleBindings created in the cluster by Anthos Config Management are deleted from the cluster.
    • Any admission controller configurations installed by Anthos Config Management are deleted.
    • The contents of the config-management-system namespace are deleted, with the exception of the git-creds Secret. Anthos Config Management cannot function without the config-management-system namespace. Any CustomResourceDefinitions (CRDs) created or modified by Anthos Config Management are removed from the clusters where they were created or modified. The CRD required to run Anthos Config Management still exists because from the point of view of Kubernetes, they were added by the user who installed Anthos Config Management. Information about removing these components is covered in the next step.
  2. At this point, the Operator still exists in your cluster, but does nothing. If you are using GKE on-prem, you cannot remove the Operator manually.

    If you are using GKE and decide that you no longer want to use Anthos Config Management at all, you can uninstall Anthos Config Management by following these steps:

    1. Verify that the config-management-system namespace is empty after deleting the ConfigManagement object in the previous step. Wait until the kubectl -n config-management-system get all command returns No resources found.

    2. Delete the config-management-system namespace:

      kubectl delete ns config-management-system
      
    3. Delete the ConfigManagement CustomResourceDefinition:

      kubectl delete crd configmanagements.configmanagement.gke.io
      
    4. Delete all Anthos Config Management objects from the kube-system namespace:

      kubectl -n kube-system delete all -l k8s-app=config-management-operator
      

Troubleshooting

The following sections help you troubleshoot your Anthos Config Management installation.

Using Audit Logs

Audit Logs can be a useful debugging tool.

If you installed Anthos Config Management using the Cloud Console or the gcloud command-line tool, complete the following steps to use Audit Logs to investigate Anthos Config Management.

Console

  1. Enable the GKE Connect/Hub APIs Audit Logs.

    1. In the Cloud Console, go to the IAM Audit Logs page.

      Go to the Audit Logs page

    2. In the table, select the GKE Connect/Hub APIs checkbox.

    3. Select the following checkboxes:

      • Admin Read
      • Data Read
      • Data Write
    4. Click Save.

  2. Go to the Logs Explorer page.

    Go to the Logs Explorer page

  3. In the Query builder text box, add the following filters:

    resource.type="audited_resource" resource.labels.service="gkehub.googleapis.com"
    
  4. Click Run Query.

  5. In the Queries results section, select entries to learn more about the events.

Insufficient CPU

The output of kubectl get events might include an event with the type FailedScheduling. The event looks like the following example:

LAST SEEN   TYPE      REASON              OBJECT                                       MESSAGE
9s          Warning   FailedScheduling    pod/config-management-operator-74594dc8f6    0/1 nodes are available: 1 Insufficient cpu.

To fix this error, choose one of the following options:

  • Add a node to an existing GKE node pool.
  • Create a node pool with larger nodes.

Error: attempt to grant extra privileges

If you receive the following error when you try to apply the config-management-operator.yaml file, you might have fewer permissions than are required for the installation:

Error from server (Forbidden): error when creating "config-management-operator.yaml": clusterroles.rbac.authorization.k8s.io "config-management-operator" is forbidden: attempt to grant extra privileges: [...] ruleResolutionErrors=[]

To ensure that you have the required permissions, review Preparing permissions.

Valid but incorrect ConfigManagement object

If installation fails due to a problem with the ConfigManagement object that is not due to a YAML or JSON syntax error, the ConfigManagement object might be instantiated in the cluster, but might not work correctly. In this situation, you can use the nomos status command to check for errors in the ConfigManagement object.

A valid installation with no problems has a status of PENDING or SYNCED.

An invalid installation has a status of NOT CONFIGURED and lists one of the following errors:

  • missing git-creds Secret
  • missing required syncRepo field
  • git-creds Secret is missing the key specified by secretType

To fix the problem, correct the configuration error. Depending on the type of error, you might need to re-apply the ConfigManagement manifest to the cluster.

If the problem is that you forgot to create the git-creds Secret, Anthos Config Management detects the Secret as soon as you create it, and you do not need to re-apply the configuration.

config-management.yaml fields

The following sections explain the different fields that you can set in your config-management.yaml file.

Configuration for the Git repository

Key Description
spec.git.syncRepo The URL of the Git repository to use as the source of truth. Required.
spec.git.syncBranch The branch of the repository to sync from. Default: master.
spec.git.policyDir The path within the Git repository that represents the top level of the repository to sync. Default: the root directory of the repository.
spec.git.syncWait Period in seconds between consecutive syncs. Default: 15.
spec.git.syncRev Git revision (tag or hash) to check out. Default HEAD.
spec.git.secretType The type of secret configured for access to the Git repository. One of ssh, cookiefile, token, gcenode, or none. Required.
spec.sourceFormat When set to unstructured, configures a non-hierarchical repo. Default: hierarchy.

Proxy configuration for the Git repository

If your organization's security policies require you to route traffic through an HTTP(S) proxy, you can use the proxy's URI to configure Anthos Config Management to communicate with your Git host.

Key Description
spec.git.proxy.httpProxy Defines an HTTP_PROXY env variable used to access the Git repository.
spec.git.proxy.httpsProxy Defines an HTTPS_PROXY env variable used to access the Git repository.

If both the httpProxy and httpsProxy fields are specified, httpProxy is ignored.

Configuration for behavior of the ConfigManagement object

Key Description
spec.clusterName The user-defined name for the cluster used by ClusterSelectors to group clusters together. Unique within an Anthos Config Management installation. You cannot configure this field in the Cloud Console.

Configuration for integrations

These fields enable integration with Config Connector and Policy Controller.

Key Description
spec.configConnector.enabled If true, installs Config Connector. Defaults to false.
spec.policyController.enabled If true, enables Policy Controller. Defaults to false.
spec.policyController.templateLibraryInstalled If true, installs the constraint template library. Defaults to true.

What's next