Configurer la synchronisation à partir de plusieurs sources de vérité

Cette page explique comment configurer plusieurs sources de vérité à l'échelle de la racine et de l'espace de noms en créant des objets RootSync et RepoSync.

Disposer d'une source de vérité racine vous permet de synchroniser les configurations appliquées au niveau du cluster et au niveau de l'espace de noms. Une source de vérité racine peut utiliser des identifiants de niveau administrateur pour appliquer des règles sur les espaces de noms de l'application et remplacer les modifications locales qui dépassent l'état que vous avez déclaré dans vos configurations. Un administrateur central régit généralement les sources de vérité racine.

Les sources de vérité à l'échelle d'un espace de noms sont facultatives et peuvent contenir des configurations à l'échelle d'un espace de noms synchronisées avec un espace de noms particulier sur plusieurs clusters. Vous pouvez déléguer la configuration et le contrôle d'une source de vérité à l'échelle d'un espace de noms à des utilisateurs non administrateurs. Bien que Config Sync détecte automatiquement les modifications de la source de vérité, vous pouvez ajouter une couche de détection de dérive supplémentaire en ajoutant un webhook d'admission à une source de vérité à l'échelle de l'espace de noms. Pour en savoir plus, consultez la section Éviter les dérives de configuration.

Avant de commencer

Créez une source de vérité non structurée pouvant contenir les configurations avec lesquelles Config Sync se synchronise, ou assurez-vous d'y avoir accès. Config Sync est compatible avec les dépôts Git, les charts Helm et les images OCI en tant que source de vérité. Les sources de vérité à l'échelle d'un espace de noms doivent utiliser le format non structuré.
Créez un cluster situé sur une plate-forme et une version compatibles de l'édition Google Kubernetes Engine (GKE) Enterprise, ou assurez-vous d'y avoir accès, et qui répond à la configuration requise pour Config Sync.

Limites

NamespaceSelectors (y compris les annotations pointant vers des sélecteurs) ne fonctionnent que dans une source de vérité racine.
Si vous avez installé Config Sync à l'aide de la console Google Cloud ou de Google Cloud CLI, Config Sync a créé automatiquement un objet RootSync appelé root-sync. Par conséquent, vous ne pouvez pas nommer vos objets RootSync root-sync.

Choisir la méthode de configuration appropriée

Choisissez l'une des deux méthodes de configuration des sources :

Contrôler les sources dans une source de vérité racine Cette méthode centralise la configuration d'une source de vérité dans une autre source de vérité, permettant ainsi à un administrateur central de contrôler entièrement la configuration.
Contrôler les sources avec l'API Kubernetes Utilisez cette méthode si vous souhaitez déléguer le contrôle de votre source de vérité à différents propriétaires.

Contrôler les sources dans une source de vérité racine

Contrôler les sources racines dans une source de vérité racine

Config Sync accepte la synchronisation à partir de plusieurs sources de vérité. L'administrateur central peut utiliser une source de vérité racine pour gérer toutes les autres sources. Étant donné que Config Sync gère les objets RootSync, cette méthode empêche toute modification locale des configurations RootSync dans le cluster.

Pour utiliser cette méthode, effectuez les tâches suivantes :

Enregistrez l'un des fichiers manifestes suivants sous le nom root-sync.yaml. Utilisez la version du fichier manifeste correspondant au type de source de vos configurations.
Git
```
# root-sync.yaml
apiVersion: configsync.gke.io/v1beta1
kind: RootSync
metadata:
  name: ROOT_SYNC_NAME
  namespace: config-management-system
spec:
  sourceType: git
  sourceFormat: ROOT_FORMAT
  git:
    repo: ROOT_REPOSITORY
    revision: ROOT_REVISION
    branch: ROOT_BRANCH
    dir: ROOT_DIRECTORY
    auth: ROOT_AUTH_TYPE
    gcpServiceAccountEmail: ROOT_EMAIL
    secretRef:
      name: ROOT_SECRET_NAME
    noSSLVerify: ROOT_NO_SSL_VERIFY
    caCertSecretRef:
      name: ROOT_CA_CERT_SECRET_NAME
```
Remplacez les éléments suivants :
- ROOT_SYNC_NAME : ajoutez le nom de votre objet RootSync.
- ROOT_FORMAT : ajoutez unstructured pour utiliser un dépôt non structuré ou hierarchy pour utiliser un dépôt hiérarchique. Ces valeurs sont sensibles à la casse. Ce champ est facultatif et la valeur par défaut est hierarchy. Nous vous recommandons d'ajouter la valeur unstructured, car ce format vous permet d'organiser vos configurations de la manière la plus adaptée à vos besoins.
- ROOT_REPOSITORY : ajoutez l'URL du dépôt Git à utiliser comme dépôt racine. Vous pouvez saisir des URL à l'aide du protocole HTTPS ou SSH. Par exemple, https://github.com/GoogleCloudPlatform/anthos-config-management-samples utilise le protocole HTTPS. Ce champ est obligatoire.
- ROOT_REVISION : ajoutez la révision Git (tag ou valeur de hachage) à partir de laquelle la synchronisation doit être effectuée. Ce champ est facultatif et la valeur par défaut est HEAD. À partir de la version 1.17.0 de Config Sync, vous pouvez également spécifier un nom de branche dans le champ revision. Lorsque vous utilisez un hachage dans la version 1.17.0 ou ultérieure, il doit s'agir d'un hachage complet et non d'une forme abrégée.
- ROOT_BRANCH : ajoutez la branche du dépôt à partir de laquelle la synchronisation doit être effectuée. Ce champ est facultatif et la valeur par défaut est master. À partir de la version 1.17.0 de Config Sync, il est recommandé d'utiliser le champ revision afin de spécifier un nom de branche pour plus de simplicité. Si les champs revision et branch sont spécifiés, revision est prioritaire sur branch.
- ROOT_DIRECTORY : ajoutez le chemin d'accès dans le dépôt Git au répertoire racine contenant la configuration que vous souhaitez synchroniser. Ce champ est facultatif et le paramètre par défaut est le répertoire racine (/) du dépôt.
- ROOT_AUTH_TYPE : ajoutez l'un des types d'authentification suivants :
  - none : n'utiliser aucune authentification
  - ssh : utiliser une paire de clés SSH
  - cookiefile : utiliser un cookiefile
  - token : utiliser un jeton
  - gcpserviceaccount : utilisez un compte de service Google pour accéder à Cloud Source Repositories.
  - gcenode : utilisez un compte de service Google pour accéder à Cloud Source Repositories. Ne sélectionnez cette option que Workload Identity Federation for GKE n'est pas activé dans votre cluster.
  Pour en savoir plus sur ces types d'authentification, consultez la page Accorder à Config Sync un accès en lecture seule à Git.
  
  Ce champ est obligatoire.
- ROOT_EMAIL : si vous avez ajouté gcpserviceaccount comme ROOT_AUTH_TYPE, ajoutez l'adresse e-mail de votre compte de service Google. Par exemple, acm@PROJECT_ID.iam.gserviceaccount.com.
- ROOT_SECRET_NAME : ajoutez le nom de votre secret. Si ce champ est défini, vous devez ajouter la clé publique du secret au fournisseur Git. Ce champ est facultatif.
- ROOT_NO_SSL_VERIFY : pour désactiver la validation du certificat SSL, définissez ce champ sur true. La valeur par défaut est false.
- ROOT_CA_CERT_SECRET_NAME : ajoutez le nom de votre secret. Si ce champ est défini, votre fournisseur Git doit utiliser un certificat émis par cette autorité de certification (CA). Le secret doit contenir le certificat de l'autorité de certification sous une clé nommée cert. Ce champ est facultatif.
  
  Pour en savoir plus sur la configuration de l'objet Secret du certificat CA, consultez la section Configurer l'autorité de certification.
Pour obtenir une explication des champs et une liste complète des champs que vous pouvez ajouter au champ spec, consultez la section Champs RootSync.

Ce fichier manifeste crée un objet RootSync qui utilise Git comme source.
OCI
```
# root-sync.yaml
apiVersion: configsync.gke.io/v1beta1
kind: RootSync
metadata:
  name: ROOT_SYNC_NAME
  namespace: config-management-system
spec:
  sourceType: oci
  sourceFormat: ROOT_FORMAT
  oci:
    image: ROOT_IMAGE
    dir: ROOT_DIRECTORY
    auth: ROOT_AUTH_TYPE
    gcpServiceAccountEmail: ROOT_EMAIL
    caCertSecretRef:
      name: ROOT_CA_CERT_SECRET_NAME
```
Remplacez les éléments suivants :
- ROOT_SYNC_NAME : ajoutez le nom de votre objet RootSync.
- ROOT_FORMAT : ajoutez unstructured pour utiliser un dépôt non structuré ou hierarchy pour utiliser un dépôt hiérarchique. Ces valeurs sont sensibles à la casse. Ce champ est facultatif et la valeur par défaut est hierarchy. Nous vous recommandons d'ajouter la valeur unstructured, car ce format vous permet d'organiser vos configurations de la manière la plus adaptée à vos besoins.
- ROOT_IMAGE : URL de l'image OCI à utiliser comme dépôt racine, par exemple LOCATION-docker.pkg.dev/PROJECT_ID/REPOSITORY_NAME/PACKAGE_NAME. Par défaut, l'image est extraite du tag latest, mais vous pouvez récupérer les images par TAG ou DIGEST à la place. Spécifiez TAG ou DIGEST dans PACKAGE_NAME :
  - Pour extraire par TAG : LOCATION-docker.pkg.dev/PROJECT_ID/REPOSITORY_NAME/PACKAGE_NAME:TAG
  - Pour extraire par DIGEST : LOCATION-docker.pkg.dev/PROJECT_ID/REPOSITORY_NAME/PACKAGE_NAME@sha256:DIGEST
Attention : Config Sync nécessite que la couche OCI soit compressée dans le fichier tar ou tar+gzip. Les autres formats (par exemple, tar+bz2) ne seront pas reconnus par Config Sync. Le passage d'un dépôt valide à une image OCI avec un format non compatible entraînera l'élimination des ressources gérées sans erreur.
- ROOT_DIRECTORY : ajoutez le chemin d'accès dans le dépôt au répertoire racine contenant la configuration que vous souhaitez synchroniser. Ce champ est facultatif et le paramètre par défaut est le répertoire racine (/) du dépôt.
- ROOT_AUTH_TYPE : ajoutez l'un des types d'authentification suivants :
  - none : n'utiliser aucune authentification
  - gcenode : utilisez le compte de service Compute Engine par défaut pour accéder à une image dans Artifact Registry. Ne sélectionnez cette option que si Workload Identity Federation for GKE n'est pas activé dans votre cluster.
  - gcpserviceaccount : utilisez un compte de service Google pour accéder à une image.
  Ce champ est obligatoire.
- ROOT_EMAIL : si vous avez ajouté gcpserviceaccount comme ROOT_AUTH_TYPE, ajoutez l'adresse e-mail de votre compte de service Google. Par exemple, acm@PROJECT_ID.iam.gserviceaccount.com.
- ROOT_CA_CERT_SECRET_NAME : ajoutez le nom de votre secret. Si ce champ est défini, votre fournisseur OCI doit utiliser un certificat émis par cette autorité de certification (CA). Le secret doit contenir le certificat de l'autorité de certification sous une clé nommée cert. Ce champ est facultatif.
Pour en savoir plus sur la configuration de l'objet Secret du certificat CA, consultez la section Configurer l'autorité de certification.

Pour obtenir une explication des champs et une liste complète des champs que vous pouvez ajouter au champ spec, consultez la section Champs RootSync.

Ce fichier manifeste crée un objet RootSync qui utilise une image OCI comme source.
Helm
```
# root-sync.yaml
apiVersion: configsync.gke.io/v1beta1
kind: RootSync
metadata:
  name: ROOT_SYNC_NAME
  namespace: config-management-system
spec:
  sourceType: helm
  sourceFormat: ROOT_FORMAT
  helm:
    repo: ROOT_HELM_REPOSITORY
    chart: HELM_CHART_NAME
    version: HELM_CHART_VERSION
    releaseName: HELM_RELEASE_NAME
    namespace: HELM_RELEASE_NAMESPACE
    values:
      foo:
        bar: VALUE_1
      baz:
      - qux: VALUE_2
        xyz: VALUE_3
    includeCRDs: HELM_INCLUDE_CRDS
    auth: ROOT_AUTH_TYPE
      gcpServiceAccountEmail: ROOT_EMAIL
      secretRef:
        name: ROOT_SECRET_NAME
    caCertSecretRef:
      name: ROOT_CA_CERT_SECRET_NAME
```
Remplacez les éléments suivants :
- ROOT_SYNC_NAME : ajoutez le nom de votre objet RootSync.
- ROOT_FORMAT : ajoutez unstructured pour utiliser un dépôt non structuré ou hierarchy pour utiliser un dépôt hiérarchique. Ces valeurs sont sensibles à la casse. Ce champ est facultatif et la valeur par défaut est hierarchy. Nous vous recommandons d'ajouter la valeur unstructured, car ce format vous permet d'organiser vos configurations de la manière la plus adaptée à vos besoins.
- ROOT_HELM_REPOSITORY : URL du dépôt Helm à utiliser comme dépôt racine. Vous pouvez saisir des URL à l'aide du protocole HTTPS ou SSH. Par exemple, https://github.com/GoogleCloudPlatform/anthos-config-management-samples utilise le protocole HTTPS. Ce champ est obligatoire.
- HELM_CHART_NAME : ajoutez le nom de votre chart Helm. Ce champ est obligatoire.
- HELM_CHART_VERSION : version de votre chart. Ce champ est facultatif. Si aucune valeur n'est spécifiée, la dernière version est utilisée.
- HELM_RELEASE_NAME : nom de la version de Helm. Ce champ est facultatif.
- HELM_RELEASE_NAMESPACE : espace de noms cible d'une version. Il ne définit un espace de noms que pour les ressources dont les modèles contiennent namespace: {{ .Release.Namespace }}. Ce champ est facultatif. Si aucune valeur n'est spécifiée, l'espace de noms par défaut config-management-system est utilisé.
- HELM_INCLUDE_CRDS : définissez cette valeur sur true si vous souhaitez que le modèle Helm génère également un objet CustomResourceDefinition. Ce champ est facultatif. Si aucune valeur n'est spécifiée, la valeur par défaut est false et aucun objet CRD n'est généré.
- VALUE : valeurs à utiliser à la place des valeurs par défaut qui accompagnent le chart Helm. Mettez en forme ce champ de la même manière que le fichier values.yaml du chart Helm. Ce champ est facultatif.
- ROOT_AUTH_TYPE : ajoutez l'un des types d'authentification suivants :
  - none : n'utiliser aucune authentification
  - token : utilisez un nom d'utilisateur et un mot de passe pour accéder à un dépôt Helm privé.
  - gcenode : utilisez le compte de service Compute Engine par défaut pour accéder à une image dans Artifact Registry. Ne sélectionnez cette option que si Workload Identity Federation for GKE n'est pas activé dans votre cluster.
  - gcpserviceaccount : utilisez un compte de service Google pour accéder à une image.
  Ce champ est obligatoire.
- ROOT_EMAIL : si vous avez ajouté gcpserviceaccount comme ROOT_AUTH_TYPE, ajoutez l'adresse e-mail de votre compte de service Google. Par exemple, acm@PROJECT_ID.iam.gserviceaccount.com.
- ROOT_SECRET_NAME : ajoutez le nom de votre secret si token est le ROOT_AUTH_TYPE. Ce champ est facultatif.
- ROOT_CA_CERT_SECRET_NAME : ajoutez le nom de votre secret. Si ce champ est défini, votre fournisseur Helm doit utiliser un certificat émis par cette autorité de certification (CA). Le secret doit contenir le certificat de l'autorité de certification sous une clé nommée cert. Ce champ est facultatif.
Pour en savoir plus sur la configuration de l'objet Secret du certificat CA, consultez la section Configurer l'autorité de certification.

Pour obtenir une explication des champs et une liste complète des champs que vous pouvez ajouter au champ spec, consultez la section Champs RootSync.

Ce fichier manifeste crée un objet RootSync qui utilise Helm comme source.

Effectuez un commit des modifications dans la source de vérité racine :

 git add .
 git commit -m 'Setting up a new root source of truth.'
 git push

Vous pouvez répéter les étapes ci-dessus si vous devez configurer plusieurs sources racines. Vous pouvez également stocker les configurations de plusieurs objets RootSync dans une source de vérité racine synchronisée par un autre objet RootSync, afin de gérer plusieurs objets RootSync de manière centralisée en mode GitOps.

Contrôler des objets à l'échelle d'un espace de noms dans une source de vérité racine

Les sources de vérité à l'échelle d'un espace de noms peuvent être gérées par une source de vérité racine. Étant donné que les sources à l'échelle d'un espace de noms sont gérées par Config Sync, cette méthode empêche toute modification locale des définitions sources à l'échelle de l'espace de noms.

Pour utiliser cette méthode, effectuez les tâches suivantes :

Dans la source de vérité racine, déclarez une configuration namespace :
```
# ROOT_SOURCE/namespaces/NAMESPACE/namespace.yaml
apiVersion: v1
kind: Namespace
metadata:
  name: NAMESPACE
```
Remplacez NAMESPACE par le nom de votre espace de noms.
Dans la source de vérité racine, créez l'un des objets RepoSync suivants dans le même espace de noms. Utilisez le fichier manifeste correspondant au type de source pour vos configurations :
Git
```
#ROOT_SOURCE/namespaces/NAMESPACE/repo-sync.yaml
apiVersion: configsync.gke.io/v1beta1
kind: RepoSync
metadata:
  name: REPO_SYNC_NAME
  namespace: NAMESPACE
spec:
  sourceType: git
  # Since this is for a namespace repository, the format is unstructured
  sourceFormat: unstructured
  git:
    repo: NAMESPACE_REPOSITORY
    revision: NAMESPACE_REVISION
    branch: NAMESPACE_BRANCH
    dir: "NAMESPACE_DIRECTORY"
    auth: NAMESPACE_AUTH_TYPE
    gcpServiceAccountEmail: NAMESPACE_EMAIL
    secretRef:
      name: NAMESPACE_SECRET_NAME
    noSSLVerify: NAMESPACE_NO_SSL_VERIFY
    caCertSecretRef:
      name: NAMESPACE_CA_CERT_SECRET_NAME
```
Remplacez les éléments suivants :
- REPO_SYNC_NAME : ajoutez le nom de votre objet RepoSync. Le nom doit être unique dans l'espace de noms.
- NAMESPACE : ajoutez le nom de votre espace de noms.
- NAMESPACE_REPOSITORY : ajoutez l'URL du dépôt Git à utiliser comme dépôt de l'espace de noms. Vous pouvez saisir des URL à l'aide du protocole HTTPS ou SSH. Par exemple, https://github.com/GoogleCloudPlatform/anthos-config-management-samples utilise le protocole HTTPS. Si vous ne saisissez pas de protocole, l'URL est traitée comme une URL HTTPS. Ce champ est obligatoire.
- NAMESPACE_REVISION : ajoutez la révision Git (tag ou valeur de hachage) à partir de laquelle la synchronisation doit être effectuée. Ce champ est facultatif et la valeur par défaut est HEAD. À partir de la version 1.17.0 de Config Sync, vous pouvez également spécifier un nom de branche dans le champ revision. Lorsque vous utilisez un hachage dans la version 1.17.0 ou ultérieure, il doit s'agir d'un hachage complet et non d'une forme abrégée.
- NAMESPACE_BRANCH : ajoutez la branche du dépôt à partir de laquelle la synchronisation doit être effectuée. Ce champ est facultatif et la valeur par défaut est master. À partir de la version 1.17.0 de Config Sync, il est recommandé d'utiliser le champ revision afin de spécifier un nom de branche pour plus de simplicité. Si les champs revision et branch sont spécifiés, revision est prioritaire sur branch.
- NAMESPACE_AUTH_TYPE : ajoutez l'un des types d'authentification suivants :
  - none : n'utiliser aucune authentification
  - ssh : utiliser une paire de clés SSH
  - cookiefile : utiliser un cookiefile
  - token : utiliser un jeton
  - gcpserviceaccount : utiliser un compte de service Google pour accéder à un dépôt dans Cloud Source Repositories
  - gcenode : utiliser un compte de service Google pour accéder à un dépôt dans Cloud Source Repositories. Ne sélectionnez cette option que Workload Identity Federation for GKE n'est pas activé dans votre cluster.
    
    Pour en savoir plus sur ces types d'authentification, consultez la page Accorder à Config Sync un accès en lecture seule à Git.
  Ce champ est obligatoire.
- NAMESPACE_EMAIL : si vous avez ajouté gcpserviceaccount comme NAMESPACE_AUTH_TYPE, ajoutez l'adresse e-mail de votre compte de service Google. Par exemple, acm@PROJECT_ID.iam.gserviceaccount.com.
- NAMESPACE_SECRET_NAME : ajoutez le nom que vous souhaitez donner à votre Secret. Ce champ est facultatif.
- NAMESPACE_NO_SSL_VERIFY : pour désactiver la validation du certificat SSL, définissez ce champ sur true. La valeur par défaut est false.
- NAMESPACE_CA_CERT_SECRET_NAME : ajoutez le nom de votre secret. Si ce champ est défini, votre fournisseur Git doit utiliser un certificat émis par cette autorité de certification (CA). Le secret doit contenir le certificat de l'autorité de certification sous une clé nommée cert. Ce champ est facultatif.
  
  Pour en savoir plus sur la configuration de l'objet Secret du certificat CA, consultez la section Configurer l'autorité de certification.
Pour obtenir une explication des champs et une liste complète des champs que vous pouvez ajouter au champ spec, consultez la section Champs RepoSync.
OCI
```
# ROOT_SOURCE/namespaces/NAMESPACE/repo-sync.yaml
apiVersion: configsync.gke.io/v1beta1
kind: RepoSync
metadata:
  name: REPO_SYNC_NAME
  namespace: NAMESPACE
spec:
  sourceType: oci
  # Since this is for a namespace repository, the format is unstructured
  sourceFormat: unstructured
  oci:
    image: NAMESPACE_IMAGE
    dir: NAMESPACE_DIRECTORY
    auth: NAMESPACE_AUTH_TYPE
    gcpServiceAccountEmail: NAMESPACE_EMAIL
    caCertSecretRef:
      name: NAMESPACE_CA_CERT_SECRET_NAME
```
Remplacez les éléments suivants :
- REPO_SYNC_NAME : ajoutez le nom de votre objet RepoSync. Le nom doit être unique dans l'espace de noms.
- NAMESPACE : ajoutez le nom de votre espace de noms.
- NAMESPACE_IMAGE : URL de l'image OCI à utiliser comme source d'espace de noms, par exemple LOCATION-docker.pkg.dev/PROJECT_ID/REPOSITORY_NAME/PACKAGE_NAME. Par défaut, l'image est extraite du tag latest, mais vous pouvez récupérer les images par TAG ou DIGEST à la place. Spécifiez TAG ou DIGEST dans PACKAGE_NAME :
  - Pour extraire par TAG : LOCATION-docker.pkg.dev/PROJECT_ID/REPOSITORY_NAME/PACKAGE_NAME:TAG
  - Pour extraire par DIGEST : LOCATION-docker.pkg.dev/PROJECT_ID/REPOSITORY_NAME/PACKAGE_NAME@sha256:DIGEST
  Attention : Config Sync nécessite que la couche OCI soit compressée dans le fichier tar ou tar+gzip. Les autres formats (par exemple, tar+bz2) ne seront pas reconnus par Config Sync. Le passage d'un dépôt valide à une image OCI avec un format non compatible entraînera l'élimination des ressources gérées sans erreur.
- NAMESPACE_DIRECTORY : ajoutez le chemin d'accès dans la source au répertoire racine contenant la configuration que vous souhaitez synchroniser. Ce champ est facultatif et le paramètre par défaut est le répertoire racine (/) de la source.
- NAMESPACE_AUTH_TYPE : ajoutez l'un des types d'authentification suivants :
  - none : n'utiliser aucune authentification
  - gcenode : utilisez le compte de service Compute Engine par défaut pour accéder à une image dans Artifact Registry. Ne sélectionnez cette option que si Workload Identity Federation for GKE n'est pas activé dans votre cluster.
  - gcpserviceaccount : utilisez un compte de service Google pour accéder à une image.
  Ce champ est obligatoire.
- NAMESPACE_EMAIL : si vous avez ajouté gcpserviceaccount comme ROOT_AUTH_TYPE, ajoutez l'adresse e-mail de votre compte de service Google. Par exemple, acm@PROJECT_ID.iam.gserviceaccount.com.
- NAMESPACE_CA_CERT_SECRET_NAME : ajoutez le nom de votre secret. Si ce champ est défini, votre fournisseur OCI doit utiliser un certificat émis par cette autorité de certification (CA). Le secret doit contenir le certificat de l'autorité de certification sous une clé nommée cert. Ce champ est facultatif.
  
  Pour en savoir plus sur la configuration de l'objet Secret du certificat CA, consultez la section Configurer l'autorité de certification.
Pour obtenir une explication des champs et une liste complète des champs que vous pouvez ajouter au champ spec, consultez la section Champs RootSync.
Helm
```
# ROOT_SOURCE/namespaces/NAMESPACE/repo-sync.yaml
apiVersion: configsync.gke.io/v1beta1
kind: RepoSync
metadata:
  name: REPO_SYNC_NAME
  namespace: NAMESPACE
spec:
  sourceType: helm
  # Since this is for a namespace repository, the format is unstructured
  sourceFormat: unstructured
  helm:
    repo: NAMESPACE_REPOSITORY
    chart: HELM_CHART_NAME
    version: HELM_CHART_VERSION
    releaseName: HELM_RELEASE_NAME
    namespace: HELM_RELEASE_NAMESPACE
    values:
      foo:
        bar: VALUE_1
      baz:
      - qux: VALUE_2
        xyz: VALUE_3
    includeCRDs: HELM_INCLUDE_CRDS
    auth: NAMESPACE_AUTH_TYPE
      gcpServiceAccountEmail: NAMESPACE_EMAIL
      secretRef:
        name: NAMESPACE_SECRET_NAME
    caCertSecretRef:
      name: NAMESPACE_CA_CERT_SECRET_NAME
```
Remplacez les éléments suivants :
- REPO_SYNC_NAME : ajoutez le nom de votre objet RepoSync. Le nom doit être unique dans l'espace de noms.
- NAMESPACE : ajoutez le nom de votre espace de noms.
- NAMESPACE_REPOSITORY : URL du dépôt Helm à utiliser comme dépôt racine. Vous pouvez saisir des URL à l'aide du protocole HTTPS ou SSH. Par exemple, https://github.com/GoogleCloudPlatform/anthos-config-management-samples utilise le protocole HTTPS. Ce champ est obligatoire.
- HELM_CHART_NAME : ajoutez le nom de votre chart Helm. Ce champ est obligatoire.
- HELM_CHART_VERSION : version de votre chart. Ce champ est facultatif. Si aucune valeur n'est spécifiée, la dernière version est utilisée.
- HELM_RELEASE_NAME : nom de la version de Helm. Ce champ est facultatif.
- HELM_RELEASE_NAMESPACE : espace de noms cible d'une version. Il ne définit un espace de noms que pour les ressources dont les modèles contiennent namespace: {{ .Release.Namespace }}. Ce champ est facultatif. Si aucune valeur n'est spécifiée, l'espace de noms par défaut config-management-system est utilisé.
- HELM_INCLUDE_CRDS : définissez cette valeur sur true si vous souhaitez que le modèle Helm génère également un objet CustomResourceDefinition. Ce champ est facultatif. Si aucune valeur n'est spécifiée, la valeur par défaut est false et aucun objet CRD n'est généré.
- VALUE : valeurs à utiliser à la place des valeurs par défaut qui accompagnent le chart Helm. Mettez en forme ce champ de la même manière que le fichier values.yaml du chart Helm. Ce champ est facultatif.
- ROOT_AUTH_TYPE : ajoutez l'un des types d'authentification suivants :
  - none : n'utiliser aucune authentification
  - token : utilisez un nom d'utilisateur et un mot de passe pour accéder à un dépôt Helm privé.
  - gcenode : utilisez le compte de service Compute Engine par défaut pour accéder à une image dans Artifact Registry. Ne sélectionnez cette option que si Workload Identity Federation for GKE n'est pas activé dans votre cluster.
  - gcpserviceaccount : utilisez un compte de service Google pour accéder à une image.
  Ce champ est obligatoire.
- NAMESPACE_EMAIL : si vous avez ajouté gcpserviceaccount comme ROOT_AUTH_TYPE, ajoutez l'adresse e-mail de votre compte de service Google. Par exemple, acm@PROJECT_ID.iam.gserviceaccount.com.
- NAMESPACE_SECRET_NAME : ajoutez le nom de votre secret si token est le ROOT_AUTH_TYPE. Ce champ est facultatif.
- NAMESPACE_CA_CERT_SECRET_NAME : ajoutez le nom de votre secret. Si ce champ est défini, votre fournisseur Helm doit utiliser un certificat émis par cette autorité de certification (CA). Le secret doit contenir le certificat de l'autorité de certification sous une clé nommée cert. Ce champ est facultatif.
  
  Pour en savoir plus sur la configuration de l'objet Secret du certificat CA, consultez la section Configurer l'autorité de certification.
Pour obtenir une explication des champs et une liste complète des champs que vous pouvez ajouter au champ spec, consultez la section Champs RootSync.
Si vous utilisez gcpserviceaccount comme type d'authentification et que la fédération d'identité de charge de travail pour GKE n'est pas activée, vous devez créer une liaison de stratégie IAM entre le compte de service Kubernetes pour chaque espace de noms et le compte de service Google. Pour savoir comment créer cette liaison, consultez Accorder l'accès à Git.
Dans la source racine, déclarez une configuration RoleBinding qui accorde au compte de service SERVICE_ACCOUNT_NAME l'autorisation de gérer des objets dans l'espace de noms. Config Sync crée automatiquement le compte de service SERVICE_ACCOUNT_NAME lorsque la configuration RepoSync est synchronisée avec le cluster.

Un RoleBinding peut faire référence à une Role dans le même espace de noms. Un RoleBinding peut également référencer un ClusterRole et lier ce ClusterRole à l'espace de noms de RoleBinding. Bien que vous deviez respecter le principe du moindre privilège en accordant des autorisations précises à une ressource Role définie par l'utilisateur, vous pouvez définir un ClusterRole ou utiliser des rôles d'utilisateur, et référencer le même ClusterRole dans plusieurs RoleBindings dans différents espaces de noms.

Remarque : Un RoleBinding référençant un ClusterRole ne vous donne accès qu'à l'espace de noms du RoleBinding, mais pas à l'accès à l'échelle du cluster.
Objets ClusterRole par défaut
Vous pouvez déclarer un RoleBinding en faisant référence à un ClusterRole par défaut, par exemple admin ou edit. Pour en savoir plus, consultez la section Rôles pour les utilisateurs.
```
# ROOT_REPO/namespaces/NAMESPACE/sync-rolebinding.yaml
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: syncs-repo
  namespace: NAMESPACE
subjects:
- kind: ServiceAccount
  name: SERVICE_ACCOUNT_NAME
  namespace: config-management-system
roleRef:
  kind: ClusterRole
  name: CLUSTERROLE_NAME
  apiGroup: rbac.authorization.k8s.io
```
Remplacez les éléments suivants :
- NAMESPACE : ajoutez le nom de votre espace de noms.
- SERVICE_ACCOUNT_NAME : ajoutez le nom du compte de service du rapprochement. Si le nom RepoSync est repo-sync, SERVICE_ACCOUNT_NAME est ns-reconciler-NAMESPACE. Sinon, il est défini sur ns-reconciler-NAMESPACE-REPO_SYNC_NAME-REPO_SYNC_NAME_LENGTH. Par exemple, si le nom de votre objet RepoSync est prod, le champ SERVICE_ACCOUNT_NAME serait ns-reconciler-NAMESPACE-prod-4. L'entier 4 est utilisé, car prod contient quatre caractères.
- CLUSTERROLE_NAME : ajoutez le nom du ClusterRole par défaut.
Rôles définis par l'utilisateur
Vous pouvez déclarer un objet ClusterRole ou Role en accordant une liste d'autorisations à chaque ressource gérée par l'objet RepoSync. Cela permet des autorisations précises. Pour en savoir plus, consultez la section Référencer des ressources.

Par exemple, l'élément ClusterRole ou Role suivant accorde des autorisations pour gérer les objets Deployment et ServiceAccount.
```
# ROOT_REPO/namespaces/NAMESPACE/sync-role.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: ROLE_KIND
metadata:
  namespace: NAMESPACE # only set this field for a 'Role'
  name: RECONCILER_ROLE
rules:
# Update 'apiGroups' and 'resources' to reference actual resources managed by 'RepoSync'.
- apiGroups: ["apps"]
  resources: ["deployments"]
  verbs: ["*"]
- apiGroups: [""]
  resources: ["serviceaccounts"]
  verbs: ["*"]
```
Pour déclarer un RoleBinding faisant référence à ClusterRole ou Role, créez l'objet suivant. Le rôle RoleBinding accorde des autorisations supplémentaires pour permettre à Config Sync de gérer les ressources à l'échelle de l'espace de noms pour une ressource RepoSync.
```
# ROOT_REPO/namespaces/NAMESPACE/sync-rolebinding.yaml
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: syncs-repo
  namespace: NAMESPACE
subjects:
- kind: ServiceAccount
  name: SERVICE_ACCOUNT_NAME
  namespace: config-management-system
roleRef:
  kind: ROLE_KIND
  name: RECONCILER_ROLE
  apiGroup: rbac.authorization.k8s.io
```
Remplacez les éléments suivants :
- ROLE_KIND : définissez ClusterRole ou Role.
- NAMESPACE : ajoutez le nom de votre espace de noms.
- SERVICE_ACCOUNT_NAME : ajoutez le nom du compte de service du rapprochement. Si le nom RepoSync est repo-sync, SERVICE_ACCOUNT_NAME est ns-reconciler-NAMESPACE. Sinon, il est défini sur ns-reconciler-NAMESPACE-REPO_SYNC_NAME-REPO_SYNC_NAME_LENGTH. Par exemple, si le nom de votre objet RepoSync est prod, le champ SERVICE_ACCOUNT_NAME serait ns-reconciler-NAMESPACE-prod-4. L'entier 4 est utilisé, car prod contient quatre caractères.
- RECONCILER_ROLE : ajoutez le nom de l'objet ClusterRole ou Role.

Effectuez un commit des modifications dans la source de vérité racine :

 git add .
 git commit -m 'Setting up a new namespace-scoped source of truth.'
 git push

Si nécessaire, créez un secret basé sur la méthode d'authentification de votre choix. Si vous avez utilisé none comme type d'authentification, vous pouvez ignorer cette étape.

Le Secret doit répondre aux exigences suivantes :
- Créez le Secret dans le même espace de noms que l'objet RepoSync.
- Le nom du Secret doit correspondre au nom spec.git.secretRef que vous avez défini dans repo-sync.yaml.
- Vous devez ajouter la clé publique du Secret au fournisseur Git.
Pour vérifier la configuration, utilisez kubectl get sur l'un des objets de la source d'espaces de noms. Exemple :
```
kubectl get rolebindings -n NAMESPACE
```
Vous pouvez répéter les étapes ci-dessus si vous devez configurer plusieurs sources à l'échelle d'un espace de noms.

Contrôler les sources à l'échelle d'un espace de noms dans une source à l'échelle d'un espace de noms

Config Sync accepte la synchronisation à partir de plusieurs sources de vérité à l'échelle d'un espace de noms par espace de noms. Les sources de vérité à l'échelle d'un espace de noms peuvent être gérées dans une source de vérité à l'échelle d'un espace de noms dans le même espace de noms.

Pour utiliser cette méthode, effectuez les tâches suivantes :

Dans la source de vérité à l'échelle de l'espace de noms, créez l'un des objets RepoSync suivants dans le même espace de noms. Utilisez le fichier manifeste correspondant au type de source pour vos configurations :
Git
```
#ROOT_SOURCE/namespaces/NAMESPACE/repo-sync.yaml
apiVersion: configsync.gke.io/v1beta1
kind: RepoSync
metadata:
  name: REPO_SYNC_NAME
  namespace: NAMESPACE
spec:
  sourceType: git
  # Since this is for a namespace repository, the format is unstructured
  sourceFormat: unstructured
  git:
    repo: NAMESPACE_REPOSITORY
    revision: NAMESPACE_REVISION
    branch: NAMESPACE_BRANCH
    dir: "NAMESPACE_DIRECTORY"
    auth: NAMESPACE_AUTH_TYPE
    gcpServiceAccountEmail: NAMESPACE_EMAIL
    secretRef:
      name: NAMESPACE_SECRET_NAME
    noSSLVerify: NAMESPACE_NO_SSL_VERIFY
    caCertSecretRef:
      name: NAMESPACE_CA_CERT_SECRET_NAME
```
Remplacez les éléments suivants :
- REPO_SYNC_NAME : ajoutez le nom de votre objet RepoSync. Le nom doit être unique dans l'espace de noms.
- NAMESPACE : ajoutez le nom de votre espace de noms.
- NAMESPACE_REPOSITORY : ajoutez l'URL du dépôt Git à utiliser comme dépôt de l'espace de noms. Vous pouvez saisir des URL à l'aide du protocole HTTPS ou SSH. Par exemple, https://github.com/GoogleCloudPlatform/anthos-config-management-samples utilise le protocole HTTPS. Si vous ne saisissez pas de protocole, l'URL est traitée comme une URL HTTPS. Ce champ est obligatoire.
- NAMESPACE_REVISION : ajoutez la révision Git (tag ou valeur de hachage) à partir de laquelle la synchronisation doit être effectuée. Ce champ est facultatif et la valeur par défaut est HEAD. À partir de la version 1.17.0 de Config Sync, vous pouvez également spécifier un nom de branche dans le champ revision. Lorsque vous utilisez un hachage dans la version 1.17.0 ou ultérieure, il doit s'agir d'un hachage complet et non d'une forme abrégée.
- NAMESPACE_BRANCH : ajoutez la branche du dépôt à partir de laquelle la synchronisation doit être effectuée. Ce champ est facultatif et la valeur par défaut est master. À partir de la version 1.17.0 de Config Sync, il est recommandé d'utiliser le champ revision afin de spécifier un nom de branche pour plus de simplicité. Si les champs revision et branch sont spécifiés, revision est prioritaire sur branch.
- NAMESPACE_AUTH_TYPE : ajoutez l'un des types d'authentification suivants :
  - none : n'utiliser aucune authentification
  - ssh : utiliser une paire de clés SSH
  - cookiefile : utiliser un cookiefile
  - token : utiliser un jeton
  - gcpserviceaccount : utiliser un compte de service Google pour accéder à un dépôt dans Cloud Source Repositories
  - gcenode : utiliser un compte de service Google pour accéder à un dépôt dans Cloud Source Repositories. Ne sélectionnez cette option que Workload Identity Federation for GKE n'est pas activé dans votre cluster.
    
    Pour en savoir plus sur ces types d'authentification, consultez la page Accorder à Config Sync un accès en lecture seule à Git.
  Ce champ est obligatoire.
- NAMESPACE_EMAIL : si vous avez ajouté gcpserviceaccount comme NAMESPACE_AUTH_TYPE, ajoutez l'adresse e-mail de votre compte de service Google. Par exemple, acm@PROJECT_ID.iam.gserviceaccount.com.
- NAMESPACE_SECRET_NAME : ajoutez le nom que vous souhaitez donner à votre Secret. Ce champ est facultatif.
- NAMESPACE_NO_SSL_VERIFY : pour désactiver la validation du certificat SSL, définissez ce champ sur true. La valeur par défaut est false.
- NAMESPACE_CA_CERT_SECRET_NAME : ajoutez le nom de votre secret. Si ce champ est défini, votre fournisseur Git doit utiliser un certificat émis par cette autorité de certification (CA). Le secret doit contenir le certificat de l'autorité de certification sous une clé nommée cert. Ce champ est facultatif.
  
  Pour en savoir plus sur la configuration de l'objet Secret du certificat CA, consultez la section Configurer l'autorité de certification.
Pour obtenir une explication des champs et une liste complète des champs que vous pouvez ajouter au champ spec, consultez la section Champs RepoSync.
OCI
```
# ROOT_SOURCE/namespaces/NAMESPACE/repo-sync.yaml
apiVersion: configsync.gke.io/v1beta1
kind: RepoSync
metadata:
  name: REPO_SYNC_NAME
  namespace: NAMESPACE
spec:
  sourceType: oci
  # Since this is for a namespace repository, the format is unstructured
  sourceFormat: unstructured
  oci:
    image: NAMESPACE_IMAGE
    dir: NAMESPACE_DIRECTORY
    auth: NAMESPACE_AUTH_TYPE
    gcpServiceAccountEmail: NAMESPACE_EMAIL
    caCertSecretRef:
      name: NAMESPACE_CA_CERT_SECRET_NAME
```
Remplacez les éléments suivants :
- REPO_SYNC_NAME : ajoutez le nom de votre objet RepoSync. Le nom doit être unique dans l'espace de noms.
- NAMESPACE : ajoutez le nom de votre espace de noms.
- NAMESPACE_IMAGE : URL de l'image OCI à utiliser comme source d'espace de noms, par exemple LOCATION-docker.pkg.dev/PROJECT_ID/REPOSITORY_NAME/PACKAGE_NAME. Par défaut, l'image est extraite du tag latest, mais vous pouvez récupérer les images par TAG ou DIGEST à la place. Spécifiez TAG ou DIGEST dans PACKAGE_NAME :
  - Pour extraire par TAG : LOCATION-docker.pkg.dev/PROJECT_ID/REPOSITORY_NAME/PACKAGE_NAME:TAG
  - Pour extraire par DIGEST : LOCATION-docker.pkg.dev/PROJECT_ID/REPOSITORY_NAME/PACKAGE_NAME@sha256:DIGEST
  Attention : Config Sync nécessite que la couche OCI soit compressée dans le fichier tar ou tar+gzip. Les autres formats (par exemple, tar+bz2) ne seront pas reconnus par Config Sync. Le passage d'un dépôt valide à une image OCI avec un format non compatible entraînera l'élimination des ressources gérées sans erreur.
- NAMESPACE_DIRECTORY : ajoutez le chemin d'accès dans la source au répertoire racine contenant la configuration que vous souhaitez synchroniser. Ce champ est facultatif et le paramètre par défaut est le répertoire racine (/) de la source.
- NAMESPACE_AUTH_TYPE : ajoutez l'un des types d'authentification suivants :
  - none : n'utiliser aucune authentification
  - gcenode : utilisez le compte de service Compute Engine par défaut pour accéder à une image dans Artifact Registry. Ne sélectionnez cette option que si Workload Identity Federation for GKE n'est pas activé dans votre cluster.
  - gcpserviceaccount : utilisez un compte de service Google pour accéder à une image.
  Ce champ est obligatoire.
- NAMESPACE_EMAIL : si vous avez ajouté gcpserviceaccount comme ROOT_AUTH_TYPE, ajoutez l'adresse e-mail de votre compte de service Google. Par exemple, acm@PROJECT_ID.iam.gserviceaccount.com.
- NAMESPACE_CA_CERT_SECRET_NAME : ajoutez le nom de votre secret. Si ce champ est défini, votre fournisseur OCI doit utiliser un certificat émis par cette autorité de certification (CA). Le secret doit contenir le certificat de l'autorité de certification sous une clé nommée cert. Ce champ est facultatif.
  
  Pour en savoir plus sur la configuration de l'objet Secret du certificat CA, consultez la section Configurer l'autorité de certification.
Pour obtenir une explication des champs et une liste complète des champs que vous pouvez ajouter au champ spec, consultez la section Champs RootSync.
Helm
```
# ROOT_SOURCE/namespaces/NAMESPACE/repo-sync.yaml
apiVersion: configsync.gke.io/v1beta1
kind: RepoSync
metadata:
  name: REPO_SYNC_NAME
  namespace: NAMESPACE
spec:
  sourceType: helm
  # Since this is for a namespace repository, the format is unstructured
  sourceFormat: unstructured
  helm:
    repo: NAMESPACE_REPOSITORY
    chart: HELM_CHART_NAME
    version: HELM_CHART_VERSION
    releaseName: HELM_RELEASE_NAME
    namespace: HELM_RELEASE_NAMESPACE
    values:
      foo:
        bar: VALUE_1
      baz:
      - qux: VALUE_2
        xyz: VALUE_3
    includeCRDs: HELM_INCLUDE_CRDS
    auth: NAMESPACE_AUTH_TYPE
      gcpServiceAccountEmail: NAMESPACE_EMAIL
      secretRef:
        name: NAMESPACE_SECRET_NAME
    caCertSecretRef:
      name: NAMESPACE_CA_CERT_SECRET_NAME
```
Remplacez les éléments suivants :
- REPO_SYNC_NAME : ajoutez le nom de votre objet RepoSync. Le nom doit être unique dans l'espace de noms.
- NAMESPACE : ajoutez le nom de votre espace de noms.
- NAMESPACE_REPOSITORY : URL du dépôt Helm à utiliser comme dépôt racine. Vous pouvez saisir des URL à l'aide du protocole HTTPS ou SSH. Par exemple, https://github.com/GoogleCloudPlatform/anthos-config-management-samples utilise le protocole HTTPS. Ce champ est obligatoire.
- HELM_CHART_NAME : ajoutez le nom de votre chart Helm. Ce champ est obligatoire.
- HELM_CHART_VERSION : version de votre chart. Ce champ est facultatif. Si aucune valeur n'est spécifiée, la dernière version est utilisée.
- HELM_RELEASE_NAME : nom de la version de Helm. Ce champ est facultatif.
- HELM_RELEASE_NAMESPACE : espace de noms cible d'une version. Il ne définit un espace de noms que pour les ressources dont les modèles contiennent namespace: {{ .Release.Namespace }}. Ce champ est facultatif. Si aucune valeur n'est spécifiée, l'espace de noms par défaut config-management-system est utilisé.
- HELM_INCLUDE_CRDS : définissez cette valeur sur true si vous souhaitez que le modèle Helm génère également un objet CustomResourceDefinition. Ce champ est facultatif. Si aucune valeur n'est spécifiée, la valeur par défaut est false et aucun objet CRD n'est généré.
- VALUE : valeurs à utiliser à la place des valeurs par défaut qui accompagnent le chart Helm. Mettez en forme ce champ de la même manière que le fichier values.yaml du chart Helm. Ce champ est facultatif.
- ROOT_AUTH_TYPE : ajoutez l'un des types d'authentification suivants :
  - none : n'utiliser aucune authentification
  - token : utilisez un nom d'utilisateur et un mot de passe pour accéder à un dépôt Helm privé.
  - gcenode : utilisez le compte de service Compute Engine par défaut pour accéder à une image dans Artifact Registry. Ne sélectionnez cette option que si Workload Identity Federation for GKE n'est pas activé dans votre cluster.
  - gcpserviceaccount : utilisez un compte de service Google pour accéder à une image.
  Ce champ est obligatoire.
- NAMESPACE_EMAIL : si vous avez ajouté gcpserviceaccount comme ROOT_AUTH_TYPE, ajoutez l'adresse e-mail de votre compte de service Google. Par exemple, acm@PROJECT_ID.iam.gserviceaccount.com.
- NAMESPACE_SECRET_NAME : ajoutez le nom de votre secret si token est le ROOT_AUTH_TYPE. Ce champ est facultatif.
- NAMESPACE_CA_CERT_SECRET_NAME : ajoutez le nom de votre secret. Si ce champ est défini, votre fournisseur Helm doit utiliser un certificat émis par cette autorité de certification (CA). Le secret doit contenir le certificat de l'autorité de certification sous une clé nommée cert. Ce champ est facultatif.
  
  Pour en savoir plus sur la configuration de l'objet Secret du certificat CA, consultez la section Configurer l'autorité de certification.
Pour obtenir une explication des champs et une liste complète des champs que vous pouvez ajouter au champ spec, consultez la section Champs RootSync.
Si vous utilisez gcpserviceaccount comme type d'authentification et que la fédération d'identité de charge de travail pour GKE n'est pas activée, vous devez créer une liaison de stratégie IAM entre le compte de service Kubernetes pour chaque espace de noms et le compte de service Google. Pour savoir comment créer cette liaison, consultez Accorder l'accès à Git.
Dans la source racine, déclarez une configuration RoleBinding qui accorde au compte de service SERVICE_ACCOUNT_NAME l'autorisation de gérer des objets dans l'espace de noms. Config Sync crée automatiquement le compte de service SERVICE_ACCOUNT_NAME lorsque la configuration RepoSync est synchronisée avec le cluster.

Un RoleBinding peut faire référence à une Role dans le même espace de noms. Un RoleBinding peut également référencer un ClusterRole et lier ce ClusterRole à l'espace de noms de RoleBinding. Bien que vous deviez respecter le principe du moindre privilège en accordant des autorisations précises à une ressource Role définie par l'utilisateur, vous pouvez définir un ClusterRole ou utiliser des rôles d'utilisateur, et référencer le même ClusterRole dans plusieurs RoleBindings dans différents espaces de noms.

Remarque : Un RoleBinding référençant un ClusterRole ne vous donne accès qu'à l'espace de noms du RoleBinding, mais pas à l'accès à l'échelle du cluster.
Objets ClusterRole par défaut
Vous pouvez déclarer un RoleBinding en faisant référence à un ClusterRole par défaut, par exemple admin ou edit. Pour en savoir plus, consultez la section Rôles pour les utilisateurs.
```
# ROOT_REPO/namespaces/NAMESPACE/sync-rolebinding.yaml
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: syncs-repo
  namespace: NAMESPACE
subjects:
- kind: ServiceAccount
  name: SERVICE_ACCOUNT_NAME
  namespace: config-management-system
roleRef:
  kind: ClusterRole
  name: CLUSTERROLE_NAME
  apiGroup: rbac.authorization.k8s.io
```
Remplacez les éléments suivants :
- NAMESPACE : ajoutez le nom de votre espace de noms.
- SERVICE_ACCOUNT_NAME : ajoutez le nom du compte de service du rapprochement. Si le nom RepoSync est repo-sync, SERVICE_ACCOUNT_NAME est ns-reconciler-NAMESPACE. Sinon, il est défini sur ns-reconciler-NAMESPACE-REPO_SYNC_NAME-REPO_SYNC_NAME_LENGTH. Par exemple, si le nom de votre objet RepoSync est prod, le champ SERVICE_ACCOUNT_NAME serait ns-reconciler-NAMESPACE-prod-4. L'entier 4 est utilisé, car prod contient quatre caractères.
- CLUSTERROLE_NAME : ajoutez le nom du ClusterRole par défaut.
Rôles définis par l'utilisateur
Vous pouvez déclarer un objet ClusterRole ou Role en accordant une liste d'autorisations à chaque ressource gérée par l'objet RepoSync. Cela permet des autorisations précises. Pour en savoir plus, consultez la section Référencer des ressources.

Par exemple, l'élément ClusterRole ou Role suivant accorde des autorisations pour gérer les objets Deployment et ServiceAccount.
```
# ROOT_REPO/namespaces/NAMESPACE/sync-role.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: ROLE_KIND
metadata:
  namespace: NAMESPACE # only set this field for a 'Role'
  name: RECONCILER_ROLE
rules:
# Update 'apiGroups' and 'resources' to reference actual resources managed by 'RepoSync'.
- apiGroups: ["apps"]
  resources: ["deployments"]
  verbs: ["*"]
- apiGroups: [""]
  resources: ["serviceaccounts"]
  verbs: ["*"]
```
Pour déclarer un RoleBinding faisant référence à ClusterRole ou Role, créez l'objet suivant. Le rôle RoleBinding accorde des autorisations supplémentaires pour permettre à Config Sync de gérer les ressources à l'échelle de l'espace de noms pour une ressource RepoSync.
```
# ROOT_REPO/namespaces/NAMESPACE/sync-rolebinding.yaml
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: syncs-repo
  namespace: NAMESPACE
subjects:
- kind: ServiceAccount
  name: SERVICE_ACCOUNT_NAME
  namespace: config-management-system
roleRef:
  kind: ROLE_KIND
  name: RECONCILER_ROLE
  apiGroup: rbac.authorization.k8s.io
```
Remplacez les éléments suivants :
- ROLE_KIND : définissez ClusterRole ou Role.
- NAMESPACE : ajoutez le nom de votre espace de noms.
- SERVICE_ACCOUNT_NAME : ajoutez le nom du compte de service du rapprochement. Si le nom RepoSync est repo-sync, SERVICE_ACCOUNT_NAME est ns-reconciler-NAMESPACE. Sinon, il est défini sur ns-reconciler-NAMESPACE-REPO_SYNC_NAME-REPO_SYNC_NAME_LENGTH. Par exemple, si le nom de votre objet RepoSync est prod, le champ SERVICE_ACCOUNT_NAME serait ns-reconciler-NAMESPACE-prod-4. L'entier 4 est utilisé, car prod contient quatre caractères.
- RECONCILER_ROLE : ajoutez le nom de l'objet ClusterRole ou Role.

Effectuez un commit des modifications dans la source de vérité racine :

 git add .
 git commit -m 'Setting up a new namespace-scoped source of truth.'
 git push

Si nécessaire, créez un secret basé sur la méthode d'authentification de votre choix. Si vous avez utilisé none comme type d'authentification, vous pouvez ignorer cette étape.

Le Secret doit répondre aux exigences suivantes :
- Créez le Secret dans le même espace de noms que l'objet RepoSync.
- Le nom du Secret doit correspondre au nom spec.git.secretRef que vous avez défini dans repo-sync.yaml.
- Vous devez ajouter la clé publique du Secret au fournisseur Git.
Pour vérifier la configuration, utilisez kubectl get sur l'un des objets de la source de vérité à l'échelle d'un espace de noms. Exemple :
```
kubectl get rolebindings -n NAMESPACE
```
Vous pouvez répéter les étapes ci-dessus si vous devez configurer plusieurs sources à l'échelle d'un espace de noms.

Contrôler une source de vérité avec l'API Kubernetes

Dans cette méthode, l'administrateur central délègue la déclaration des autres objets RootSync à d'autres administrateurs. Pour les objets RepoSync, l'administrateur central ne déclare que l'espace de noms dans la source de vérité racine et délègue la déclaration de l'objet RepoSync à l'opérateur d'application.

Contrôler plusieurs sources de vérité racines

Les autres administrateurs peuvent contrôler une source de vérité racine en effectuant les tâches suivantes :

Enregistrez l'un des fichiers manifestes suivants sous le nom root-sync.yaml. Utilisez la version du fichier manifeste correspondant au type de source de vos configurations.
Git
```
# root-sync.yaml
apiVersion: configsync.gke.io/v1beta1
kind: RootSync
metadata:
  name: ROOT_SYNC_NAME
  namespace: config-management-system
spec:
  sourceType: git
  sourceFormat: ROOT_FORMAT
  git:
    repo: ROOT_REPOSITORY
    revision: ROOT_REVISION
    branch: ROOT_BRANCH
    dir: ROOT_DIRECTORY
    auth: ROOT_AUTH_TYPE
    gcpServiceAccountEmail: ROOT_EMAIL
    secretRef:
      name: ROOT_SECRET_NAME
    noSSLVerify: ROOT_NO_SSL_VERIFY
    caCertSecretRef:
      name: ROOT_CA_CERT_SECRET_NAME
```
Remplacez les éléments suivants :
- ROOT_SYNC_NAME : ajoutez le nom de votre objet RootSync.
- ROOT_FORMAT : ajoutez unstructured pour utiliser un dépôt non structuré ou hierarchy pour utiliser un dépôt hiérarchique. Ces valeurs sont sensibles à la casse. Ce champ est facultatif et la valeur par défaut est hierarchy. Nous vous recommandons d'ajouter la valeur unstructured, car ce format vous permet d'organiser vos configurations de la manière la plus adaptée à vos besoins.
- ROOT_REPOSITORY : ajoutez l'URL du dépôt Git à utiliser comme dépôt racine. Vous pouvez saisir des URL à l'aide du protocole HTTPS ou SSH. Par exemple, https://github.com/GoogleCloudPlatform/anthos-config-management-samples utilise le protocole HTTPS. Ce champ est obligatoire.
- ROOT_REVISION : ajoutez la révision Git (tag ou valeur de hachage) à partir de laquelle la synchronisation doit être effectuée. Ce champ est facultatif et la valeur par défaut est HEAD. À partir de la version 1.17.0 de Config Sync, vous pouvez également spécifier un nom de branche dans le champ revision. Lorsque vous utilisez un hachage dans la version 1.17.0 ou ultérieure, il doit s'agir d'un hachage complet et non d'une forme abrégée.
- ROOT_BRANCH : ajoutez la branche du dépôt à partir de laquelle la synchronisation doit être effectuée. Ce champ est facultatif et la valeur par défaut est master. À partir de la version 1.17.0 de Config Sync, il est recommandé d'utiliser le champ revision afin de spécifier un nom de branche pour plus de simplicité. Si les champs revision et branch sont spécifiés, revision est prioritaire sur branch.
- ROOT_DIRECTORY : ajoutez le chemin d'accès dans le dépôt Git au répertoire racine contenant la configuration que vous souhaitez synchroniser. Ce champ est facultatif et le paramètre par défaut est le répertoire racine (/) du dépôt.
- ROOT_AUTH_TYPE : ajoutez l'un des types d'authentification suivants :
  - none : n'utiliser aucune authentification
  - ssh : utiliser une paire de clés SSH
  - cookiefile : utiliser un cookiefile
  - token : utiliser un jeton
  - gcpserviceaccount : utilisez un compte de service Google pour accéder à Cloud Source Repositories.
  - gcenode : utilisez un compte de service Google pour accéder à Cloud Source Repositories. Ne sélectionnez cette option que Workload Identity Federation for GKE n'est pas activé dans votre cluster.
  Pour en savoir plus sur ces types d'authentification, consultez la page Accorder à Config Sync un accès en lecture seule à Git.
  
  Ce champ est obligatoire.
- ROOT_EMAIL : si vous avez ajouté gcpserviceaccount comme ROOT_AUTH_TYPE, ajoutez l'adresse e-mail de votre compte de service Google. Par exemple, acm@PROJECT_ID.iam.gserviceaccount.com.
- ROOT_SECRET_NAME : ajoutez le nom de votre secret. Si ce champ est défini, vous devez ajouter la clé publique du secret au fournisseur Git. Ce champ est facultatif.
- ROOT_NO_SSL_VERIFY : pour désactiver la validation du certificat SSL, définissez ce champ sur true. La valeur par défaut est false.
- ROOT_CA_CERT_SECRET_NAME : ajoutez le nom de votre secret. Si ce champ est défini, votre fournisseur Git doit utiliser un certificat émis par cette autorité de certification (CA). Le secret doit contenir le certificat de l'autorité de certification sous une clé nommée cert. Ce champ est facultatif.
  
  Pour en savoir plus sur la configuration de l'objet Secret du certificat CA, consultez la section Configurer l'autorité de certification.
Pour obtenir une explication des champs et une liste complète des champs que vous pouvez ajouter au champ spec, consultez la section Champs RootSync.

Ce fichier manifeste crée un objet RootSync qui utilise Git comme source.
OCI
```
# root-sync.yaml
apiVersion: configsync.gke.io/v1beta1
kind: RootSync
metadata:
  name: ROOT_SYNC_NAME
  namespace: config-management-system
spec:
  sourceType: oci
  sourceFormat: ROOT_FORMAT
  oci:
    image: ROOT_IMAGE
    dir: ROOT_DIRECTORY
    auth: ROOT_AUTH_TYPE
    gcpServiceAccountEmail: ROOT_EMAIL
    caCertSecretRef:
      name: ROOT_CA_CERT_SECRET_NAME
```
Remplacez les éléments suivants :
- ROOT_SYNC_NAME : ajoutez le nom de votre objet RootSync.
- ROOT_FORMAT : ajoutez unstructured pour utiliser un dépôt non structuré ou hierarchy pour utiliser un dépôt hiérarchique. Ces valeurs sont sensibles à la casse. Ce champ est facultatif et la valeur par défaut est hierarchy. Nous vous recommandons d'ajouter la valeur unstructured, car ce format vous permet d'organiser vos configurations de la manière la plus adaptée à vos besoins.
- ROOT_IMAGE : URL de l'image OCI à utiliser comme dépôt racine, par exemple LOCATION-docker.pkg.dev/PROJECT_ID/REPOSITORY_NAME/PACKAGE_NAME. Par défaut, l'image est extraite du tag latest, mais vous pouvez récupérer les images par TAG ou DIGEST à la place. Spécifiez TAG ou DIGEST dans PACKAGE_NAME :
  - Pour extraire par TAG : LOCATION-docker.pkg.dev/PROJECT_ID/REPOSITORY_NAME/PACKAGE_NAME:TAG
  - Pour extraire par DIGEST : LOCATION-docker.pkg.dev/PROJECT_ID/REPOSITORY_NAME/PACKAGE_NAME@sha256:DIGEST
Attention : Config Sync nécessite que la couche OCI soit compressée dans le fichier tar ou tar+gzip. Les autres formats (par exemple, tar+bz2) ne seront pas reconnus par Config Sync. Le passage d'un dépôt valide à une image OCI avec un format non compatible entraînera l'élimination des ressources gérées sans erreur.
- ROOT_DIRECTORY : ajoutez le chemin d'accès dans le dépôt au répertoire racine contenant la configuration que vous souhaitez synchroniser. Ce champ est facultatif et le paramètre par défaut est le répertoire racine (/) du dépôt.
- ROOT_AUTH_TYPE : ajoutez l'un des types d'authentification suivants :
  - none : n'utiliser aucune authentification
  - gcenode : utilisez le compte de service Compute Engine par défaut pour accéder à une image dans Artifact Registry. Ne sélectionnez cette option que si Workload Identity Federation for GKE n'est pas activé dans votre cluster.
  - gcpserviceaccount : utilisez un compte de service Google pour accéder à une image.
  Ce champ est obligatoire.
- ROOT_EMAIL : si vous avez ajouté gcpserviceaccount comme ROOT_AUTH_TYPE, ajoutez l'adresse e-mail de votre compte de service Google. Par exemple, acm@PROJECT_ID.iam.gserviceaccount.com.
- ROOT_CA_CERT_SECRET_NAME : ajoutez le nom de votre secret. Si ce champ est défini, votre fournisseur OCI doit utiliser un certificat émis par cette autorité de certification (CA). Le secret doit contenir le certificat de l'autorité de certification sous une clé nommée cert. Ce champ est facultatif.
Pour en savoir plus sur la configuration de l'objet Secret du certificat CA, consultez la section Configurer l'autorité de certification.

Pour obtenir une explication des champs et une liste complète des champs que vous pouvez ajouter au champ spec, consultez la section Champs RootSync.

Ce fichier manifeste crée un objet RootSync qui utilise une image OCI comme source.
Helm
```
# root-sync.yaml
apiVersion: configsync.gke.io/v1beta1
kind: RootSync
metadata:
  name: ROOT_SYNC_NAME
  namespace: config-management-system
spec:
  sourceType: helm
  sourceFormat: ROOT_FORMAT
  helm:
    repo: ROOT_HELM_REPOSITORY
    chart: HELM_CHART_NAME
    version: HELM_CHART_VERSION
    releaseName: HELM_RELEASE_NAME
    namespace: HELM_RELEASE_NAMESPACE
    values:
      foo:
        bar: VALUE_1
      baz:
      - qux: VALUE_2
        xyz: VALUE_3
    includeCRDs: HELM_INCLUDE_CRDS
    auth: ROOT_AUTH_TYPE
      gcpServiceAccountEmail: ROOT_EMAIL
      secretRef:
        name: ROOT_SECRET_NAME
    caCertSecretRef:
      name: ROOT_CA_CERT_SECRET_NAME
```
Remplacez les éléments suivants :
- ROOT_SYNC_NAME : ajoutez le nom de votre objet RootSync.
- ROOT_FORMAT : ajoutez unstructured pour utiliser un dépôt non structuré ou hierarchy pour utiliser un dépôt hiérarchique. Ces valeurs sont sensibles à la casse. Ce champ est facultatif et la valeur par défaut est hierarchy. Nous vous recommandons d'ajouter la valeur unstructured, car ce format vous permet d'organiser vos configurations de la manière la plus adaptée à vos besoins.
- ROOT_HELM_REPOSITORY : URL du dépôt Helm à utiliser comme dépôt racine. Vous pouvez saisir des URL à l'aide du protocole HTTPS ou SSH. Par exemple, https://github.com/GoogleCloudPlatform/anthos-config-management-samples utilise le protocole HTTPS. Ce champ est obligatoire.
- HELM_CHART_NAME : ajoutez le nom de votre chart Helm. Ce champ est obligatoire.
- HELM_CHART_VERSION : version de votre chart. Ce champ est facultatif. Si aucune valeur n'est spécifiée, la dernière version est utilisée.
- HELM_RELEASE_NAME : nom de la version de Helm. Ce champ est facultatif.
- HELM_RELEASE_NAMESPACE : espace de noms cible d'une version. Il ne définit un espace de noms que pour les ressources dont les modèles contiennent namespace: {{ .Release.Namespace }}. Ce champ est facultatif. Si aucune valeur n'est spécifiée, l'espace de noms par défaut config-management-system est utilisé.
- HELM_INCLUDE_CRDS : définissez cette valeur sur true si vous souhaitez que le modèle Helm génère également un objet CustomResourceDefinition. Ce champ est facultatif. Si aucune valeur n'est spécifiée, la valeur par défaut est false et aucun objet CRD n'est généré.
- VALUE : valeurs à utiliser à la place des valeurs par défaut qui accompagnent le chart Helm. Mettez en forme ce champ de la même manière que le fichier values.yaml du chart Helm. Ce champ est facultatif.
- ROOT_AUTH_TYPE : ajoutez l'un des types d'authentification suivants :
  - none : n'utiliser aucune authentification
  - token : utilisez un nom d'utilisateur et un mot de passe pour accéder à un dépôt Helm privé.
  - gcenode : utilisez le compte de service Compute Engine par défaut pour accéder à une image dans Artifact Registry. Ne sélectionnez cette option que si Workload Identity Federation for GKE n'est pas activé dans votre cluster.
  - gcpserviceaccount : utilisez un compte de service Google pour accéder à une image.
  Ce champ est obligatoire.
- ROOT_EMAIL : si vous avez ajouté gcpserviceaccount comme ROOT_AUTH_TYPE, ajoutez l'adresse e-mail de votre compte de service Google. Par exemple, acm@PROJECT_ID.iam.gserviceaccount.com.
- ROOT_SECRET_NAME : ajoutez le nom de votre secret si token est le ROOT_AUTH_TYPE. Ce champ est facultatif.
- ROOT_CA_CERT_SECRET_NAME : ajoutez le nom de votre secret. Si ce champ est défini, votre fournisseur Helm doit utiliser un certificat émis par cette autorité de certification (CA). Le secret doit contenir le certificat de l'autorité de certification sous une clé nommée cert. Ce champ est facultatif.
Pour en savoir plus sur la configuration de l'objet Secret du certificat CA, consultez la section Configurer l'autorité de certification.

Pour obtenir une explication des champs et une liste complète des champs que vous pouvez ajouter au champ spec, consultez la section Champs RootSync.

Ce fichier manifeste crée un objet RootSync qui utilise Helm comme source.
Appliquez les modifications :
```
kubectl apply -f root-sync.yaml
```
Vous pouvez répéter les étapes ci-dessus si vous devez configurer plusieurs sources de vérité.

Contrôler les sources de vérité à l'échelle de l'espace de noms

Tâches administratives centrales

L'administrateur central effectue les tâches suivantes :

Dans la source de vérité racine, déclarez une configuration namespace pour les sources à l'échelle d'un espace de noms.
```
# ROOT_REPO/namespaces/NAMESPACE/namespace.yaml
 apiVersion: v1
 kind: Namespace
 metadata:
   name: NAMESPACE
```
Remplacez NAMESPACE par le nom de votre espace de noms.
Dans la source de vérité racine, déclarez un RoleBinding pour accorder les autorisations aux opérateurs d'application. Utilisez la prévention de l'élévation RBAC pour vous assurer que l'opérateur d'application ne pourra pas appliquer ultérieurement une liaison de rôle avec des autorisations non accordées par cette liaison de rôle.

Pour déclarer l'objet RoleBinding, créez le fichier manifeste suivant :
```
# ROOT_REPO/namespaces/NAMESPACE/operator-rolebinding.yaml
 kind: RoleBinding
 # Add RBAC escalation prevention
 apiVersion: rbac.authorization.k8s.io/v1
 metadata:
   name: operator
   namespace: NAMESPACE
 subjects:
 - kind: User
   name: USERNAME
   apiGroup: rbac.authorization.k8s.io
 roleRef:
   kind: ClusterRole
   name: OPERATOR_ROLE
   apiGroup: rbac.authorization.k8s.io
```
Remplacez les éléments suivants :
- NAMESPACE : ajoutez l'espace de noms que vous avez créé dans la source de vérité racine.
- USERNAME : ajoutez le nom d'utilisateur de l'opérateur d'application.
- OPERATOR_ROLE : en tant qu'administrateur central, vous pouvez définir OPERATOR_ROLE pour appliquer les types de configuration pouvant être synchronisés à partir de la source d'espaces de noms. Vous pouvez choisir l'un des rôles suivants :
  - Un ClusterRole par défaut :
    - admin
    - edit
    Pour en savoir plus, consultez la section Rôles pour les utilisateurs.
  - Un objet ClusterRole ou Role défini par l'utilisateur déclaré dans la source de vérité racine. Ce rôle permet des autorisations précises.

Effectuez un commit des modifications dans la source de vérité racine :

 git add .
 git commit -m 'Setting up new namespace-scoped source of truth.'
 git push

Tâches de l'opérateur d'application

L'opérateur d'application peut contrôler les sources de portée d'espace de noms en effectuant les tâches suivantes :

Déclarez une configuration RoleBinding qui accorde au compte de service SERVICE_ACCOUNT_NAME provisionné automatiquement l'autorisation de gérer les objets de l'espace de noms. Config Sync crée automatiquement le compte de service SERVICE_ACCOUNT_NAME lorsque la configuration RepoSync est synchronisée avec le cluster.

Pour déclarer l'objet RoleBinding, créez le fichier manifeste suivant :
```
# sync-rolebinding.yaml
kind: RoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:
  name: syncs-repo
  namespace: NAMESPACE
subjects:
- kind: ServiceAccount
  name: SERVICE_ACCOUNT_NAME
  namespace: config-management-system
roleRef:
  kind: ClusterRole
  name: RECONCILER_ROLE
  apiGroup: rbac.authorization.k8s.io
```
Remplacez les éléments suivants :
- NAMESPACE : ajoutez l'espace de noms que vous avez créé dans la source de vérité racine.
- SERVICE_ACCOUNT_NAME : ajoutez le nom du compte de service du rapprochement. Si le nom RepoSync est repo-sync, SERVICE_ACCOUNT_NAME est ns-reconciler-NAMESPACE. Sinon, il est défini sur ns-reconciler-NAMESPACE-REPO_SYNC_NAME.
- RECONCILER_ROLE : en tant qu'opérateur d'application, vous pouvez définir RECONCILER_ROLE pour appliquer les types de configuration pouvant être synchronisés à partir de la source d'espaces de noms. Vous ne pouvez restreindre davantage l'ensemble d'autorisations que l'administrateur central vous a accordées. Par conséquent, ce rôle ne peut pas être plus permissif que OPERATOR_ROLE que l'administrateur central a déclaré dans la section précédente.
Appliquez la configuration RoleBinding :
```
kubectl apply -f sync-rolebinding.yaml
```
Si nécessaire, créez un secret basé sur la méthode d'authentification de votre choix. Si vous avez utilisé none comme type d'authentification, vous pouvez ignorer cette étape.

Le Secret doit répondre aux exigences suivantes :
- Créez le Secret dans le même espace de noms que l'objet RepoSync.
- Le nom du Secret doit correspondre au nom spec.git.secretRef que vous avez défini dans root-sync.yaml.
- Vous devez ajouter la clé publique du Secret au fournisseur Git.
Déclarez une configuration RepoSync :
Git
```
#ROOT_SOURCE/namespaces/NAMESPACE/repo-sync.yaml
apiVersion: configsync.gke.io/v1beta1
kind: RepoSync
metadata:
  name: REPO_SYNC_NAME
  namespace: NAMESPACE
spec:
  sourceType: git
  # Since this is for a namespace repository, the format is unstructured
  sourceFormat: unstructured
  git:
    repo: NAMESPACE_REPOSITORY
    revision: NAMESPACE_REVISION
    branch: NAMESPACE_BRANCH
    dir: "NAMESPACE_DIRECTORY"
    auth: NAMESPACE_AUTH_TYPE
    gcpServiceAccountEmail: NAMESPACE_EMAIL
    secretRef:
      name: NAMESPACE_SECRET_NAME
    noSSLVerify: NAMESPACE_NO_SSL_VERIFY
    caCertSecretRef:
      name: NAMESPACE_CA_CERT_SECRET_NAME
```
Remplacez les éléments suivants :
- REPO_SYNC_NAME : ajoutez le nom de votre objet RepoSync. Le nom doit être unique dans l'espace de noms.
- NAMESPACE : ajoutez le nom de votre espace de noms.
- NAMESPACE_REPOSITORY : ajoutez l'URL du dépôt Git à utiliser comme dépôt de l'espace de noms. Vous pouvez saisir des URL à l'aide du protocole HTTPS ou SSH. Par exemple, https://github.com/GoogleCloudPlatform/anthos-config-management-samples utilise le protocole HTTPS. Si vous ne saisissez pas de protocole, l'URL est traitée comme une URL HTTPS. Ce champ est obligatoire.
- NAMESPACE_REVISION : ajoutez la révision Git (tag ou valeur de hachage) à partir de laquelle la synchronisation doit être effectuée. Ce champ est facultatif et la valeur par défaut est HEAD. À partir de la version 1.17.0 de Config Sync, vous pouvez également spécifier un nom de branche dans le champ revision. Lorsque vous utilisez un hachage dans la version 1.17.0 ou ultérieure, il doit s'agir d'un hachage complet et non d'une forme abrégée.
- NAMESPACE_BRANCH : ajoutez la branche du dépôt à partir de laquelle la synchronisation doit être effectuée. Ce champ est facultatif et la valeur par défaut est master. À partir de la version 1.17.0 de Config Sync, il est recommandé d'utiliser le champ revision afin de spécifier un nom de branche pour plus de simplicité. Si les champs revision et branch sont spécifiés, revision est prioritaire sur branch.
- NAMESPACE_AUTH_TYPE : ajoutez l'un des types d'authentification suivants :
  - none : n'utiliser aucune authentification
  - ssh : utiliser une paire de clés SSH
  - cookiefile : utiliser un cookiefile
  - token : utiliser un jeton
  - gcpserviceaccount : utiliser un compte de service Google pour accéder à un dépôt dans Cloud Source Repositories
  - gcenode : utiliser un compte de service Google pour accéder à un dépôt dans Cloud Source Repositories. Ne sélectionnez cette option que Workload Identity Federation for GKE n'est pas activé dans votre cluster.
    
    Pour en savoir plus sur ces types d'authentification, consultez la page Accorder à Config Sync un accès en lecture seule à Git.
  Ce champ est obligatoire.
- NAMESPACE_EMAIL : si vous avez ajouté gcpserviceaccount comme NAMESPACE_AUTH_TYPE, ajoutez l'adresse e-mail de votre compte de service Google. Par exemple, acm@PROJECT_ID.iam.gserviceaccount.com.
- NAMESPACE_SECRET_NAME : ajoutez le nom que vous souhaitez donner à votre Secret. Ce champ est facultatif.
- NAMESPACE_NO_SSL_VERIFY : pour désactiver la validation du certificat SSL, définissez ce champ sur true. La valeur par défaut est false.
- NAMESPACE_CA_CERT_SECRET_NAME : ajoutez le nom de votre secret. Si ce champ est défini, votre fournisseur Git doit utiliser un certificat émis par cette autorité de certification (CA). Le secret doit contenir le certificat de l'autorité de certification sous une clé nommée cert. Ce champ est facultatif.
  
  Pour en savoir plus sur la configuration de l'objet Secret du certificat CA, consultez la section Configurer l'autorité de certification.
Pour obtenir une explication des champs et une liste complète des champs que vous pouvez ajouter au champ spec, consultez la section Champs RepoSync.
OCI
```
# ROOT_SOURCE/namespaces/NAMESPACE/repo-sync.yaml
apiVersion: configsync.gke.io/v1beta1
kind: RepoSync
metadata:
  name: REPO_SYNC_NAME
  namespace: NAMESPACE
spec:
  sourceType: oci
  # Since this is for a namespace repository, the format is unstructured
  sourceFormat: unstructured
  oci:
    image: NAMESPACE_IMAGE
    dir: NAMESPACE_DIRECTORY
    auth: NAMESPACE_AUTH_TYPE
    gcpServiceAccountEmail: NAMESPACE_EMAIL
    caCertSecretRef:
      name: NAMESPACE_CA_CERT_SECRET_NAME
```
Remplacez les éléments suivants :
- REPO_SYNC_NAME : ajoutez le nom de votre objet RepoSync. Le nom doit être unique dans l'espace de noms.
- NAMESPACE : ajoutez le nom de votre espace de noms.
- NAMESPACE_IMAGE : URL de l'image OCI à utiliser comme source d'espace de noms, par exemple LOCATION-docker.pkg.dev/PROJECT_ID/REPOSITORY_NAME/PACKAGE_NAME. Par défaut, l'image est extraite du tag latest, mais vous pouvez récupérer les images par TAG ou DIGEST à la place. Spécifiez TAG ou DIGEST dans PACKAGE_NAME :
  - Pour extraire par TAG : LOCATION-docker.pkg.dev/PROJECT_ID/REPOSITORY_NAME/PACKAGE_NAME:TAG
  - Pour extraire par DIGEST : LOCATION-docker.pkg.dev/PROJECT_ID/REPOSITORY_NAME/PACKAGE_NAME@sha256:DIGEST
  Attention : Config Sync nécessite que la couche OCI soit compressée dans le fichier tar ou tar+gzip. Les autres formats (par exemple, tar+bz2) ne seront pas reconnus par Config Sync. Le passage d'un dépôt valide à une image OCI avec un format non compatible entraînera l'élimination des ressources gérées sans erreur.
- NAMESPACE_DIRECTORY : ajoutez le chemin d'accès dans la source au répertoire racine contenant la configuration que vous souhaitez synchroniser. Ce champ est facultatif et le paramètre par défaut est le répertoire racine (/) de la source.
- NAMESPACE_AUTH_TYPE : ajoutez l'un des types d'authentification suivants :
  - none : n'utiliser aucune authentification
  - gcenode : utilisez le compte de service Compute Engine par défaut pour accéder à une image dans Artifact Registry. Ne sélectionnez cette option que si Workload Identity Federation for GKE n'est pas activé dans votre cluster.
  - gcpserviceaccount : utilisez un compte de service Google pour accéder à une image.
  Ce champ est obligatoire.
- NAMESPACE_EMAIL : si vous avez ajouté gcpserviceaccount comme ROOT_AUTH_TYPE, ajoutez l'adresse e-mail de votre compte de service Google. Par exemple, acm@PROJECT_ID.iam.gserviceaccount.com.
- NAMESPACE_CA_CERT_SECRET_NAME : ajoutez le nom de votre secret. Si ce champ est défini, votre fournisseur OCI doit utiliser un certificat émis par cette autorité de certification (CA). Le secret doit contenir le certificat de l'autorité de certification sous une clé nommée cert. Ce champ est facultatif.
  
  Pour en savoir plus sur la configuration de l'objet Secret du certificat CA, consultez la section Configurer l'autorité de certification.
Pour obtenir une explication des champs et une liste complète des champs que vous pouvez ajouter au champ spec, consultez la section Champs RootSync.
Helm
```
# ROOT_SOURCE/namespaces/NAMESPACE/repo-sync.yaml
apiVersion: configsync.gke.io/v1beta1
kind: RepoSync
metadata:
  name: REPO_SYNC_NAME
  namespace: NAMESPACE
spec:
  sourceType: helm
  # Since this is for a namespace repository, the format is unstructured
  sourceFormat: unstructured
  helm:
    repo: NAMESPACE_REPOSITORY
    chart: HELM_CHART_NAME
    version: HELM_CHART_VERSION
    releaseName: HELM_RELEASE_NAME
    namespace: HELM_RELEASE_NAMESPACE
    values:
      foo:
        bar: VALUE_1
      baz:
      - qux: VALUE_2
        xyz: VALUE_3
    includeCRDs: HELM_INCLUDE_CRDS
    auth: NAMESPACE_AUTH_TYPE
      gcpServiceAccountEmail: NAMESPACE_EMAIL
      secretRef:
        name: NAMESPACE_SECRET_NAME
    caCertSecretRef:
      name: NAMESPACE_CA_CERT_SECRET_NAME
```
Remplacez les éléments suivants :
- REPO_SYNC_NAME : ajoutez le nom de votre objet RepoSync. Le nom doit être unique dans l'espace de noms.
- NAMESPACE : ajoutez le nom de votre espace de noms.
- NAMESPACE_REPOSITORY : URL du dépôt Helm à utiliser comme dépôt racine. Vous pouvez saisir des URL à l'aide du protocole HTTPS ou SSH. Par exemple, https://github.com/GoogleCloudPlatform/anthos-config-management-samples utilise le protocole HTTPS. Ce champ est obligatoire.
- HELM_CHART_NAME : ajoutez le nom de votre chart Helm. Ce champ est obligatoire.
- HELM_CHART_VERSION : version de votre chart. Ce champ est facultatif. Si aucune valeur n'est spécifiée, la dernière version est utilisée.
- HELM_RELEASE_NAME : nom de la version de Helm. Ce champ est facultatif.
- HELM_RELEASE_NAMESPACE : espace de noms cible d'une version. Il ne définit un espace de noms que pour les ressources dont les modèles contiennent namespace: {{ .Release.Namespace }}. Ce champ est facultatif. Si aucune valeur n'est spécifiée, l'espace de noms par défaut config-management-system est utilisé.
- HELM_INCLUDE_CRDS : définissez cette valeur sur true si vous souhaitez que le modèle Helm génère également un objet CustomResourceDefinition. Ce champ est facultatif. Si aucune valeur n'est spécifiée, la valeur par défaut est false et aucun objet CRD n'est généré.
- VALUE : valeurs à utiliser à la place des valeurs par défaut qui accompagnent le chart Helm. Mettez en forme ce champ de la même manière que le fichier values.yaml du chart Helm. Ce champ est facultatif.
- ROOT_AUTH_TYPE : ajoutez l'un des types d'authentification suivants :
  - none : n'utiliser aucune authentification
  - token : utilisez un nom d'utilisateur et un mot de passe pour accéder à un dépôt Helm privé.
  - gcenode : utilisez le compte de service Compute Engine par défaut pour accéder à une image dans Artifact Registry. Ne sélectionnez cette option que si Workload Identity Federation for GKE n'est pas activé dans votre cluster.
  - gcpserviceaccount : utilisez un compte de service Google pour accéder à une image.
  Ce champ est obligatoire.
- NAMESPACE_EMAIL : si vous avez ajouté gcpserviceaccount comme ROOT_AUTH_TYPE, ajoutez l'adresse e-mail de votre compte de service Google. Par exemple, acm@PROJECT_ID.iam.gserviceaccount.com.
- NAMESPACE_SECRET_NAME : ajoutez le nom de votre secret si token est le ROOT_AUTH_TYPE. Ce champ est facultatif.
- NAMESPACE_CA_CERT_SECRET_NAME : ajoutez le nom de votre secret. Si ce champ est défini, votre fournisseur Helm doit utiliser un certificat émis par cette autorité de certification (CA). Le secret doit contenir le certificat de l'autorité de certification sous une clé nommée cert. Ce champ est facultatif.
  
  Pour en savoir plus sur la configuration de l'objet Secret du certificat CA, consultez la section Configurer l'autorité de certification.
Pour obtenir une explication des champs et une liste complète des champs que vous pouvez ajouter au champ spec, consultez la section Champs RootSync.
Appliquez la configuration RepoSync :
```
kubectl apply -f repo-sync.yaml
```
Pour vérifier la configuration, utilisez kubectl get sur l'un des objets de la source à l'échelle d'un espace de noms. Exemple :
```
kubectl get rolebindings -n NAMESPACE
```
Vous pouvez répéter les étapes ci-dessus si vous devez configurer plusieurs sources de vérité à l'échelle d'un espace de noms.

Vérifier l'état de synchronisation de la source de vérité

Vous pouvez utiliser la commande nomos status pour inspecter l'état de synchronisation de la source de vérité :

nomos status

Un résultat semblable aux lignes suivantes doit s'afficher :

my_managed_cluster-1
  --------------------
  <root>   git@github.com:foo-corp/acme/admin@main
  SYNCED   f52a11e4
  --------------------
  bookstore  git@github.com:foo-corp/acme/bookstore@v1
  SYNCED     34d1a8c8

Dans cet exemple de résultat, la source à l'échelle d'un espace de noms, dans le cas présent un dépôt Git, est configurée pour un espace de noms nommé bookstore.

Vérifier l'installation de RootSync

Lorsque vous créez un objet RootSync, Config Sync crée un rapprochement avec le préfixe root-reconciler. Un rapprochement est un pod qui est déployé en tant que déploiement. Il synchronise les fichiers manifestes d'une source de vérité avec un cluster.

Vous pouvez vérifier que l'objet RootSync fonctionne correctement en vérifiant l'état du déploiement du rapprochement racine :

kubectl get -n config-management-system deployment \
    -l configsync.gke.io/sync-name=ROOT_SYNC_NAME

Remplacez ROOT_SYNC_NAME par le nom de RootSync.

Un résultat semblable aux lignes suivantes doit s'afficher :

NAME              READY   UP-TO-DATE   AVAILABLE   AGE
root-reconciler   1/1     1            1           3h42m

Pour découvrir d'autres moyens d'explorer l'état de votre objet RootSync, consultez la page Surveiller les objets RootSync et RepoSync.

Vérifier l'installation de RepoSync

Lorsque vous créez un objet RepoSync, Config Sync crée un rapprochement avec le préfixe ns-reconciler-NAMESPACE, où NAMESPACE est l'espace de noms dans lequel vous avez créé votre objet RepoSync.

Vous pouvez vérifier que l'objet RepoSync fonctionne correctement en vérifiant l'état du déploiement du rapprochement de l'espace de noms :

kubectl get -n config-management-system deployment \
  -l configsync.gke.io/sync-name=REPO_SYNC_NAME \
  -l configsync.gke.io/sync-namespace=NAMESPACE

Remplacez REPO_SYNC_NAME par le nom de RepoSync et remplacez NAMESPACE par l'espace de noms dans lequel vous avez créé votre source de vérité à l'échelle de l'espace de noms.

Pour analyser plus en détail l'état de votre objet RepoSync, consultez la section Explorer les objets RootSync et RepoSync.

Supprimer une source de vérité

Sélectionnez l'onglet Méthode de contrôle centralisé ou Méthode de l'API Kubernetes pour afficher les instructions correspondantes.

Méthode de contrôle centralisé

Si vous avez utilisé la méthode Contrôler les sources de vérité dans une source de vérité racine, un administrateur central peut suivre les deux étapes suivantes pour supprimer une source de vérité :

Décidez si vous souhaitez supprimer ou conserver les ressources gérées via vos objets RootSync et RepoSync.
- Pour supprimer toutes les ressources gérées par vos objets RootSync ou RepoSync, synchronisez votre objet RootSync ou RepoSync avec une source vide. Par exemple, un dépôt GitHub sans configuration. Si votre objet RootSync ou RepoSync contient un autre objet RootSync ou RepoSync, l'objet RootSync ou le RepoSync interne doit d'abord être synchronisé avec un dépôt Git vide.
- Si vous avez activé le webhook et que vous souhaitez conserver vos ressources, désactivez la protection contre les dérives pour les ressources abandonnées. Si vous n'avez pas activé le webhook, vous n'avez pas besoin d'effectuer des étapes supplémentaires pour conserver vos ressources.
Supprimez l'objet RootSync ou RepoSync de la source de vérité.

Méthode de l'API Kubernetes

Si vous avez utilisé la méthode Contrôler les sources de vérité à l'échelle d'un espace de noms avec l'API Kubernetes, les opérateurs d'application peuvent procéder comme suit pour supprimer une source de vérité à l'échelle de l'espace de noms :

Décidez si vous souhaitez supprimer ou conserver les ressources gérées via vos objets RootSync et RepoSync.
- Pour supprimer toutes les ressources gérées par vos objets RootSync ou RepoSync, synchronisez votre objet RootSync ou RepoSync avec une source vide. Par exemple, un dépôt GitHub sans configuration. Si votre objet RootSync ou RepoSync contient un autre objet RootSync ou RepoSync, l'objet RootSync ou le RepoSync interne doit d'abord être synchronisé avec un dépôt Git vide.
- Si vous avez activé le webhook et que vous souhaitez conserver vos ressources, désactivez la protection contre les dérives pour les ressources abandonnées. Si vous n'avez pas activé le webhook, vous n'avez pas besoin d'effectuer des étapes supplémentaires pour conserver vos ressources.
Supprimez l'objet RootSync ou RepoSync en exécutant la commande suivante :
```
kubectl delete -f FILE_NAME
```
Remplacez FILE_NAME par le nom de votre fichier de configuration RootSync ou RepoSync. Exemple :root-sync.yaml

Étapes suivantes

Découvrez comment empêcher les dérives de configuration dans les sources de vérité à l'échelle de l'espace de noms.
Découvrez comment surveiller vos objets RootSync et RepoSync.
Découvrez comment scinder une source de vérité en plusieurs sources de vérités.

Configurer la synchronisation à partir de plusieurs sources de vérité

Avant de commencer

Limites

Choisir la méthode de configuration appropriée

Contrôler les sources dans une source de vérité racine

Contrôler les sources racines dans une source de vérité racine

Git

OCI

Helm

Contrôler des objets à l'échelle d'un espace de noms dans une source de vérité racine

Git

OCI

Helm

Objets ClusterRole par défaut

Rôles définis par l'utilisateur

Contrôler les sources à l'échelle d'un espace de noms dans une source à l'échelle d'un espace de noms

Git

OCI

Helm

Objets ClusterRole par défaut

Rôles définis par l'utilisateur

Contrôler une source de vérité avec l'API Kubernetes

Contrôler plusieurs sources de vérité racines

Git

OCI

Helm

Contrôler les sources de vérité à l'échelle de l'espace de noms

Tâches administratives centrales

Tâches de l'opérateur d'application

Git

OCI

Helm

Vérifier l'état de synchronisation de la source de vérité

Vérifier l'installation de RootSync

Vérifier l'installation de RepoSync

Supprimer une source de vérité

Méthode de contrôle centralisé

Méthode de l'API Kubernetes

Étapes suivantes