Aperçu

Dans cet atelier, vous allez apprendre à utiliser Policy Controller, un contrôleur d'admission dynamique Kubernetes qui vérifie, audite et applique la conformité de vos clusters aux règles liées à la sécurité, aux réglementations ou aux règles métier.

Policy Controller applique la conformité de vos clusters aux règles appelées "contraintes". Dans cet atelier, vous allez utiliser la bibliothèque de contraintes, un ensemble de modèles pouvant être facilement configurés pour appliquer et auditer des règles de sécurité et de conformité. Par exemple, vous pouvez exiger que les espaces de noms disposent d'au moins un libellé afin que vous puissiez utiliser la mesure de l'utilisation de GKE et allouer les coûts aux différentes équipes. Vous pouvez également appliquer les mêmes exigences que celles fournies par PodSecurityPolicies, mais avec la possibilité de les auditer avant de perturber un déploiement avec des mesures d'application.

En plus d'utiliser les modèles de contraintes de plate-forme fournis, vous allez apprendre à créer les vôtres. Grâce aux modèles de contraintes, une équipe centralisée peut définir le fonctionnement d'une contrainte et déléguer la définition des spécificités de la contrainte à un individu ou à un groupe doté de l'expertise en la matière.

Conçu à partir du projet Open Source Gatekeeper, Policy Controller est intégré à Anthos Config Management version 1.1+.

Objectifs

Cet atelier va vous apprendre à effectuer les tâches suivantes :

• Installer Anthos Policy Controller

• Créer et appliquer des contraintes à l'aide de la bibliothèque de modèles fournie par Google

• Auditer les cas de non-respect des contraintes

• Écrire votre propre modèle de contraintes pour créer les règles de conformité personnalisées dont votre entreprise a besoin

Tâche 0 : Mettre en place l'atelier

Dans cette tâche, vous allez utiliser Qwiklabs pour procéder à l'initialisation de votre atelier.

Accéder à Qwiklabs

Pour chaque atelier, nous vous attribuons un nouveau projet Google Cloud et un nouvel ensemble de ressources pour une durée déterminée, sans frais.

1. Connectez-vous à Qwiklabs dans une fenêtre de navigation privée.

2. Vérifiez le temps imparti pour l'atelier (par exemple : 01:15:00) : vous devez pouvoir le terminer dans ce délai.
   Une fois l'atelier lancé, vous ne pouvez pas le mettre en pause. Si nécessaire, vous pourrez le redémarrer, mais vous devrez tout reprendre depuis le début.

3. Lorsque vous êtes prêt, cliquez sur Démarrer l'atelier.

4. Notez vos identifiants pour l'atelier (Nom d'utilisateur et Mot de passe). Ils vous serviront à vous connecter à Google Cloud Console.

5. Cliquez sur Ouvrir la console Google.

6. Cliquez sur Utiliser un autre compte, puis copiez-collez les identifiants de cet atelier lorsque vous y êtes invité.
   Si vous utilisez d'autres identifiants, des messages d'erreur s'afficheront ou des frais seront appliqués.

7. Acceptez les conditions d'utilisation et ignorez la page concernant les ressources de récupération des données.

Une fois la connexion initiale effectuée, le tableau de bord du projet s'affiche.

Cliquez sur Select a project (Sélectionner un projet), puis sur l'ID de votre projet GCP. Enfin, cliquez sur OPEN (Ouvrir).

Activer Google Cloud Shell

Google Cloud Shell est une machine virtuelle qui contient de nombreux outils pour les développeurs. Elle comprend un répertoire d'accueil persistant de 5 Go et s'exécute sur Google Cloud.

Google Cloud Shell vous permet d'accéder à vos ressources Google Cloud grâce à une ligne de commande.

1. Dans la barre d'outils située en haut à droite dans la console Cloud, cliquez sur le bouton "Ouvrir Cloud Shell".

   

2. Cliquez sur Continuer.

Le provisionnement et la connexion à l'environnement prennent quelques instants. Une fois connecté, vous êtes en principe authentifié et le projet est défini sur votre ID_PROJET. Par exemple :

gcloud est l'outil de ligne de commande pour Google Cloud. Il est préinstallé sur Cloud Shell et permet la complétion par tabulation.

• Vous pouvez lister les noms des comptes actifs à l'aide de cette commande :

gcloud auth list

Résultat :

Credentialed accounts: - @.com (active)

Exemple de résultat :

Credentialed accounts: - google1623327_student@qwiklabs.net

• Vous pouvez lister les ID de projet à l'aide de cette commande :

gcloud config list project

Résultat :

[core] project =

Exemple de résultat :

[core] project = qwiklabs-gcp-44776a13dea667a6 Remarque : Pour consulter la documentation complète sur gcloud, accédez au guide de présentation de la gcloud CLI.

Tâche 1 : Terminer et vérifier la configuration de l'atelier

L'environnement de l'atelier a déjà été partiellement configuré.

• Un cluster GKE nommé gke a été créé et enregistré.

1. Configurez l'environnement Cloud Shell pour un accès en ligne de commande à votre cluster :

   export CLUSTER_NAME=gke export ZONE=us-central1-b export PROJECT_ID=$(gcloud config get-value project) export PROJECT_NUMBER=$(gcloud projects describe ${PROJECT_ID} \ --format="value(projectNumber)") gcloud container clusters get-credentials gke --zone $ZONE --project $PROJECT_ID

2. Activez les API nécessaires :

   gcloud alpha container hub config-management enable

Tâche 2 : Installer Anthos Policy Controller

1. Créez le fichier de configuration Anthos Policy Controller :

   cat <<EOF > config-management.yaml apiVersion: configmanagement.gke.io/v1 kind: ConfigManagement metadata: name: config-management applySpecVersion: 1 spec: # Set to true to install and enable Policy Controller policyController: enabled: true # Uncomment to prevent the template library from being installed # templateLibraryInstalled: false # Uncomment to enable support for referential constraints # referentialRulesEnabled: true # Uncomment to disable audit, adjust value to set audit interval # auditIntervalSeconds: 0 # Uncomment to log all denies and dryrun failures # logDeniesEnabled: true # Uncomment to exempt namespaces # exemptableNamespaces: ["namespace-name"] # ...other fields... EOF

2. Installez Anthos Policy Controller :

   gcloud alpha container hub config-management apply \ --membership=${CLUSTER_NAME}-connect \ --config=config-management.yaml \ --project=$PROJECT_ID

3. Interrogez le service Config Management pour vérifier qu'Anthos Policy Controller a bien été installé :

   watch gcloud alpha container hub config-management status \ --project=$PROJECT_ID

   Lorsque le résultat est mis à jour pour correspondre à ce qui est affiché ci-dessous, vous pouvez appuyer sur <CTRL>+C pour quitter l'interrogation et continuer. L'installation du contrôleur peut prendre quatre à cinq minutes (mais pas plus). Parfois, l'état et/ou Hierachy_Controller reste à l'état "PENDING" (En attente). Ignorez cette indication et poursuivez en passant aux étapes suivantes.

   Résultat, ne pas copier

   Name Status Policy_Controller gke-connect SYNCED INSTALLED

4. Vérifier l'installation de la bibliothèque de modèles de contraintes

   kubectl get constrainttemplates

   Résultat souhaité, ne pas copier

   NAME AGE k8sallowedrepos 84s k8scontainerlimits 84s k8spspallowprivilegeescalationcontainer 84s ...[OUTPUT TRUNCATED]...

Tâche 3 : Créer une contrainte à partir des modèles de la bibliothèque

1. Essayons l'une des contraintes de la bibliothèque. Spécifions que les nouveaux espaces de noms doivent comporter le libellé geo avant de pouvoir être créés :

   cat <<EOF > ns-must-have-geo.yaml apiVersion: constraints.gatekeeper.sh/v1beta1 kind: K8sRequiredLabels metadata: name: ns-must-have-geo spec: match: kinds: - apiGroups: [""] kinds: ["Namespace"] parameters: labels: - key: "geo" EOF

2. Appliquez la contrainte à l'aide de la commande kubectl :

   kubectl apply -f ns-must-have-geo.yaml

3. Essayez de créer un espace de noms sans la clé geo pour vérifier que cela ne fonctionne pas :

   kubectl create namespace test

   Vous devez obtenir les résultats suivants :

   Error from server ([denied by ns-must-have-geo] you must provide labels: {"geo"}): admission webhook "validation.gatekeeper.sh" denied the request: [denied by ns-must-have-geo] you must provide labels: {"geo"}

   Si, à la place, une erreur semblable à celle-ci s'affiche :

   Error from server (InternalError): Internal error occurred: failed calling webhook "check-ignore-label.gatekeeper.sh": Post https://gatekeeper-webhook-service.gatekeeper-system.svc:443/v1/admitlabel?timeout=3s: no endpoints available for service "gatekeeper-webhook-service"

   Patientez une minute ou deux, puis réessayez.

4. Essayez de créer le même espace de noms avec le libellé geo :

   cat <<EOF > test-namespace.yaml apiVersion: v1 kind: Namespace metadata: name: test labels: geo: eu-west1 EOF kubectl apply -f test-namespace.yaml

   Félicitations ! Vous avez réussi à configurer un modèle depuis la bibliothèque de contraintes, à le déployer et à vérifier qu'il empêche les utilisateurs d'installer des ressources non conformes.

Tâche 4 : Auditer les règles de contraintes

Les objets de contrainte Policy Controller vous permettent d'appliquer des règles à vos clusters Kubernetes. Pour tester vos règles, vous pouvez ajouter une action d'application à vos contraintes. Vous pouvez ensuite afficher les cas de non-respect dans les objets de contrainte et les journaux. Il existe deux actions d'application : deny et dryrun.

deny est l'action appliquée par défaut. Elle est automatiquement activée, même si vous n'ajoutez pas d'action d'application dans votre contrainte. Utilisez deny pour éviter qu'une opération de cluster donnée ne se produise en cas de non-respect.

L'action dryrun vous permet de surveiller les cas de non-respect des règles sans bloquer activement les transactions. Elle vous permet de vérifier que vos contraintes fonctionnent comme prévu, avant d'activer l'application active à l'aide de l'action deny. Tester les contraintes de cette manière peut éviter les perturbations causées par une contrainte mal configurée.

1. Auditez les cas de non-respect de contraintes à l'aide de la commande kubectl suivante :

   kubectl get K8sRequiredLabels ns-must-have-geo -o yaml

   Notez que le type de enforcementAction est deny, car vous n'avez pas modifié le comportement par défaut. Notez également qu'il existe au total neuf cas de non-respect. Il s'agit d'espaces de noms qui ne respectent pas la règle, mais qui ont été créés avant l'application de celle-ci.

2. Ouvrez la contrainte dans l'éditeur Cloud Shell. Remplacez la contrainte enforcementAction par dryrun. Vous pourrez ainsi valider les contraintes de règle avant de les appliquer. Assurez-vous que le fichier YAML se présente comme suit :

   apiVersion: constraints.gatekeeper.sh/v1beta1 kind: K8sRequiredLabels metadata: name: ns-must-have-geo spec: enforcementAction: dryrun match: kinds: - apiGroups: [""] kinds: ["Namespace"] parameters: labels: - key: "geo"

3. Exécutez kubectl apply pour déployer les modifications dans le cluster :

   kubectl apply -f ns-must-have-geo.yaml

4. Essayez de créer un autre espace de noms sans le libellé geo et observez comment la commande se termine cette fois :

   kubectl create namespace ns-with-violations

5. Vérifiez à nouveau les cas de non-respect des règles afin d'afficher une nouvelle infraction de type dryrun :

   kubectl get K8sRequiredLabels ns-must-have-geo -o yaml

Tâche 5 : Écrire un modèle de contrainte

Dans cette tâche, vous allez écrire un modèle de contrainte personnalisé et l'utiliser pour étendre les fonctionnalités de Policy Controller. C'est très utile lorsque vous ne trouvez pas de modèle de contrainte prédéfini adapté à vos besoins d'extension de Policy Controller.

Les règles de Policy Controller sont décrites à l'aide du service OPA Contraint Framework et sont écrites dans Rego. Une règle peut évaluer n'importe quel champ d'un objet Kubernetes.

Écrire des règles à l'aide de Rego est une compétence spécialisée. Pour cette raison, une bibliothèque de modèles de contraintes courants est installée par défaut. La plupart des utilisateurs peuvent exploiter ces modèles de contraintes lors de la création de contraintes. Si vous avez des besoins spécifiques, vous pouvez créer vos propres modèles de contraintes.

Les modèles de contraintes vous permettent de séparer la logique d'une règle de ses exigences spécifiques, à des fins de réutilisation et de délégation. Vous pouvez créer des contraintes à l'aide de modèles de contraintes développés par des tiers, tels que des projets Open Source, des éditeurs de logiciels ou des experts en réglementation.

1. Créez le modèle de règle qui refuse toutes les ressources dont le nom correspond à une valeur fournie par le créateur de la contrainte :

   cat <<EOF > k8sdenyname-constraint-template.yaml apiVersion: templates.gatekeeper.sh/v1beta1 kind: ConstraintTemplate metadata: name: k8sdenyname spec: crd: spec: names: kind: K8sDenyName validation: openAPIV3Schema: properties: invalidName: type: string targets: - target: admission.k8s.gatekeeper.sh rego: | package k8sdenynames violation[{"msg": msg}] { input.review.object.metadata.name == input.parameters.invalidName msg := sprintf("The name %v is not allowed", [input.parameters.invalidName]) } EOF

2. Déployez le modèle dans le cluster Kubernetes :

   kubectl apply -f k8sdenyname-constraint-template.yaml

   Notez que si vous utilisez un dépôt structuré avec ACM Config Sync, Google vous recommande de créer vos contraintes dans le répertoire cluster/.

3. Une fois le modèle déployé, l'équipe peut y faire référence de la même manière qu'un modèle de la bibliothèque Google afin de créer une contrainte.

   cat <<EOF > k8sdenyname-constraint.yaml apiVersion: constraints.gatekeeper.sh/v1beta1 kind: K8sDenyName metadata: name: no-policy-violation spec: parameters: invalidName: "policy-violation" EOF

4. Déployez la contrainte dans le cluster Kubernetes :

   kubectl apply -f k8sdenyname-constraint.yaml

5. Essayez de créer une ressource nommée policy-violation pour vérifier que cela ne fonctionne pas :

   kubectl create namespace policy-violation

   Félicitations ! Vous avez créé et déployé votre propre modèle. Vous avez ensuite créé une contrainte et vérifié qu'elle empêche les utilisateurs d'installer des ressources non conformes.

Récapitulatif

Dans cet atelier, vous avez examiné l'outil Policy Controller d'ACM et exploré certaines de ses fonctionnalités utiles. Vous avez créé une contrainte à partir des modèles fournis et avez également créé vos propres modèles. Vous avez vérifié que les contraintes peuvent être utilisées pour appliquer des règles et pour auditer les cas de non-respect des règles avant de les appliquer dans un environnement de production.

Terminer l'atelier

Une fois l'atelier terminé, cliquez sur Terminer l'atelier. Google Cloud Skills Boost supprime les ressources que vous avez utilisées, puis efface le compte.

Si vous le souhaitez, vous pouvez noter l'atelier. Sélectionnez un nombre d'étoiles, saisissez un commentaire, puis cliquez sur Envoyer.

Le nombre d'étoiles correspond à votre degré de satisfaction :

• 1 étoile = très insatisfait(e)
• 2 étoiles = insatisfait(e)
• 3 étoiles = ni insatisfait(e), ni satisfait(e)
• 4 étoiles = satisfait(e)
• 5 étoiles = très satisfait(e)

Si vous ne souhaitez pas donner votre avis, vous pouvez fermer la boîte de dialogue.

Pour soumettre des commentaires, suggestions ou corrections, veuillez accéder à l'onglet Assistance.

Copyright 2020 Google LLC Tous droits réservés. Google et le logo Google sont des marques de Google LLC. Tous les autres noms d'entreprises et de produits peuvent être des marques des entreprises auxquelles ils sont associés.