Utiliser Policy Controller dans un pipeline CI

Cette page décrit comment intégrer Policy Controller à Cloud Build en créant un pipeline d'intégration continue (CI) qui vérifie les validations de stratégie synchronisées avec un dépôt Git.

Si vous êtes développeur et que vous souhaitez valider votre application par rapport aux règles de l'entreprise, consultez plutôt la section Valider votre application par rapporte aux règles de l'entreprise dans un pipeline d'intégration continue.

Présentation

La création d'un pipeline CI avec Policy Controller vous permet les actions suivantes :

  • Appliquer des configurations de stratégie définies et fournir des commentaires aux développeurs dès que possible. Les stratégies permettent aux administrateurs de plate-forme de verrouiller l'accès. Les équipes de développement doivent alors se conformer à ces stratégies plutôt que de les supprimer ou de les contourner.

  • Définir des champs par défaut sur vos objets Kubernetes qui doivent toujours être présents. Par exemple, vous pouvez ajouter automatiquement des libellés pour les propriétaires ou le centre de coûts.

Ce document porte plus particulièrement sur un pipeline Cloud Build CI utilisant un dépôt de configuration GitHub. Vous pouvez utiliser le même modèle pour configurer d'autres outils de CI ou d'autres systèmes de contrôle de version pris en charge par Anthos Config Management.

Ce pipeline est conçu à l'aide de fonctions KPT. Les fonctions KPT vous permettent de développer des images de conteneurs côté client pour valider, transformer ou générer des configurations Kubernetes.

Cette rubrique utilise des fonctions KPT prédéfinies issues du Catalogue de fonctions KPT. Un sous-ensemble de fonctions du Catalogue a été mis en miroir dans un Container Registry compatible avec Google et est disponible pour tous les projets.

Avant de commencer

  • Vous devez disposer des droits d'accès à Anthos pour installer Policy Controller à l'aide d'Anthos Config Management.

  • Vous avez besoin d'un cluster avec Anthos Config Management déjà installé.

  • Configurez Policy Controller.

  • Vous devez disposer de l'autorisation serviceusage.services.enable sur votre projet Google Cloud et de l'autorisation servicemanagement.services.bind sur l'API Cloud Build. Ces autorisations sont nécessaires pour activer le compte de service Cloud Build. Reportez-vous à la page Activation des API pour plus de détails.

  • Activez Cloud Build dans votre projet. Cela peut être fait via Google Cloud Console.

Utiliser un dépôt non structuré

Ce tutoriel inclut la possibilité d'utiliser un dépôt non structuré. Les dépôts non structurés ne nécessitent pas la structure de répertoire par défaut d'Anthos Config Management.

Configurer Cloud Build

Vous devez accorder le rôle "Développeur Kubernetes Engine" au compte de service Cloud Build dans chaque projet où vous configurez le pipeline.

  1. Accéder à la page Paramètres de Cloud Build

    La page Autorisations de compte de service s'affiche.

  2. Recherchez la ligne contenant Kubernetes Engine et définissez son État sur ACTIVÉ.

Pour plus d'informations, consultez la page Définir des autorisations de compte de service.

Configurer votre environnement

Pour configurer Policy Controller de sorte qu'il fonctionne avec Cloud Build, consultez l'exemple de dépôt Git.

Clonez le dépôt avec git.

git clone git@github.com:GoogleCloudPlatform/csp-config-management.git

Si vous utilisez un dépôt hiérarchique, vous devez modifier les fichiers de configuration dans ce dépôt après avoir configuré Cloud Build.

Structure des répertoires

Dans le dépôt csp-config-management, il existe deux répertoires qui contiennent des configurations pour un dépôt hiérarchique (ci-pipeline/) et un dépôt non structuré (ci-pipeline-unstructured/). Choisissez le répertoire approprié pour votre type de cluster.

Les répertoires ci-pipeline/ et ci-pipeline-unstructured/ dans le dépôt utilisent la hiérarchie suivante :

  • config-root/ est la racine du dépôt et contient toutes les configurations de cet exemple.

  • config-root/.../*-constraint.yaml et *-template.yaml définissent les contraintes et les modèles de Policy Controller que toutes les configurations de config-root/ doivent transmettre.

    Exemple :

    • Le fichier ci-pipeline/config-root/cluster/required-labels-constraint.yaml nécessite que chaque espace de noms ait un libellé cost-center.

    • Le fichier ci-pipeline-unstructured/config-root/constraints/banned-key-constraint.yaml impose qu'aucun des objets ConfigMap ne contienne un champ nommé private-key.

    Pour plus d'informations, consultez la page Créer des contraintes.

  • cloudbuild.yaml est le fichier de configuration de Cloud Build qui définit les étapes de compilation. Ces étapes de compilation sont déclenchées par un commit dans le dépôt.

    En utilisant un dépôt hiérarchique, le pipeline compile les contenus de votre dépôt avec nomos hydrate, les concatène et les valide avec Policy Controller.

    Dans un dépôt non structuré, Policy Controller compile votre configuration sans utiliser nomos et sans se connecter à votre cluster.

    Pour plus d'informations sur les contenus d'un fichier de configuration, consultez la page Créer une configuration de base.

Configurer Cloud Build

Dans cette section, vous connectez Cloud Build à votre dépôt source afin que Cloud Build puisse compiler le code dans ce dépôt.

Créer un déclencheur de compilation

Cloud Build exécute des déclencheurs de compilation lors de l'exécution d'un commit sur la branche. Pour configurer un déclencheur de compilation dans Google Cloud Console, procédez comme suit.

  1. Ouvrez la page Déclencheurs dans Google Cloud Console.

    Ouvrir la page Déclencheurs

  2. Sélectionnez votre projet dans le menu déroulant du sélecteur de projet, en haut de la page.

  3. Cliquez sur Ouvrir.

  4. Cliquez sur Créer un déclencheur.

  5. Créez un Nom pour votre déclencheur.

  6. Pour Événement, sélectionnez Déployer sur une branche.

  7. Sélectionnez votre Dépôt. Si vous n'avez pas connecté votre dépôt, procédez comme suit :

    1. Cliquez sur Connecter un dépôt.

    2. Sélectionnez le dépôt hébergeant votre code source.

      Si vous sélectionnez GitHub (en miroir) ou Bitbucket (en miroir) comme dépôt source, Cloud Build met en miroir votre dépôt dans Cloud Source Repositories et utilise le dépôt mis en miroir.

    3. Cliquez sur Continuer.

    4. Authentifiez-vous auprès de votre dépôt source à l'aide de votre nom d'utilisateur et de votre mot de passe.

    5. Dans la liste des dépôts disponibles, sélectionnez le dépôt de votre choix, puis cliquez sur Connecter un dépôt.

  8. Dans la liste des dépôts disponibles, sélectionnez le dépôt csp-config-management.

  9. Sélectionnez votre Branche, master.

  10. Sous Configuration de compilation, définissez votre Fichier de configuration Cloud Build sur ci-pipeline/cloudbuild.yaml ou ci-pipeline-unstructured/cloudbuild.yaml.

  11. Cliquez sur Créer pour enregistrer le déclencheur de compilation.

Vous pouvez également créer des déclencheurs de compilation avec gcloud. Pour plus d'informations, consultez la page Créer et gérer des déclencheurs de compilation.

Configurer votre dépôt

Une fois Cloud Build configuré pour se connecter à votre dépôt, terminez votre configuration pour Anthos Config Management.

  1. Modifiez le fichier csp-config-management/CODEOWNERS et remplacez @OWNER par votre nom d'utilisateur GitHub ou l'alias d'adresse e-mail de l'équipe d'administration de la plate-forme. Pour en savoir plus sur la syntaxe CODEOWNERS, consultez la page À propos des propriétaires de code.

Indiquez ci-dessous si vous utilisez un dépôt hiérarchique (par défaut) ou non structuré.

  1. Modifiez le fichier de configuration

    Hiérarchique

    Modifiez le fichier csp-config-management/ci-pipeline/cloudbuild.yaml.

    Remplacez CLUSTER_NAME et ZONE par le nom et la zone d'un cluster GKE sur lequel Anthos Config Management et Policy Controller sont installés.

    Non structuré

    Aucun changement de configuration n'est nécessaire avec un dépôt non structuré dans cet exemple. Anthos Config Management et Policy Controller valident votre dépôt sans se connecter à votre cluster.

  2. Ajoutez et validez vos modifications dans le dépôt.

    Hiérarchique

    cd ci-pipeline
    git add .
    git commit -m "[COMMIT_MESSAGE]"

    Non structuré

    cd ci-pipeline-unstructured
    git add .
    git commit -m "[COMMIT_MESSAGE]"

    Après le commit, Cloud Build exécute une validation de stratégie sur le dépôt.

  3. Ouvrez votre historique de Cloud Build et cliquez sur la Compilation la plus récente.

    La page Informations sur la compilation apparaît.

  4. L'exemple dans le dépôt csp-config-management contient une erreur.

    Sélectionnez la compilation la plus récente en haut de la liste, qui comprend l'icône .

  5. La dernière étape exécutée par Cloud Build se termine avec une erreur. Elle se présente comme suit.

    Hiérarchique

    Error: Found 1 violations:
    [1] All namespaces must have a cost-center label that points to your division
    name: "shipping-prod"
    path: namespace_shipping-prod.yaml

    Non structuré

    Step #2: Error: Found 1 violations:
    [1] The following banned keys are being used in the config map: {"private_key"}
    name: "super-secret"
    path: configmap.yaml

  6. Ensuite, corrigez l'erreur en modifiant un fichier dans votre dépôt.

    Hiérarchique

    Modifiez le fichier /ci-pipeline/config-root/namespaces/online/shipping-app-backend/shipping-prod/namespace.yaml et définissez une valeur pour metadata.labels.cost-center. Votre fichier namespace.yaml devrait ressembler à ceci :

    apiVersion: v1
    kind: Namespace
    metadata:
      name: shipping-prod
      labels:
        env: prod
        cost-center: "shipping.foo-corp.com"
      annotations:
        audit: "true"
    

    Non structuré

    Modifiez le fichier /ci-pipeline-unstructured/config-root/configmap.yaml. Remplacez le champ nommé data.private_key par data.public_key. Votre fichier YAML modifié ressemble à ce qui suit.

    apiVersion: v1
    kind: ConfigMap
    metadata:
      name: super-secret
      namespace: default
    data:
      public_key: no secrets here
    

    Ensuite, procédez au commit et au transfert de vos modifications.

    git add .
    git commit -m "[COMMIT_MESSAGE]"
    git push origin [BRANCH]
  7. Ouvrez votre historique de Cloud Build et cliquez sur la Compilation la plus récente.

    La page Informations sur la compilation apparaît.

  8. Votre nouvelle compilation doit être Réussie.

Dépannage

Problème : Ma compilation Cloud Build échoue et l'historique inclut l'erreur suivante.

  [1] KNV1021: No CustomResourceDefinition is defined for the type "ConstraintTemplate.templates.gatekeeper.sh" in the cluster.
  Resource types that are not native Kubernetes objects must have a CustomResourceDefinition.

Solution : confirmez votre installation de Policy Controller.

Et ensuite ?