Configurer pour les clusters sur site

Ce document explique comment configurer l'autorisation binaire pour les clusters sur site créés dans le cadre de Google Distributed Cloud. Il vous explique ensuite comment configurer un exemple de stratégie d'autorisation binaire.

Avant de commencer

Assurez-vous que vos clusters disposent d'une version compatible de Google Distributed Cloud. L'autorisation binaire est compatible avec les environnements suivants.

Bare Metal
Google Distributed Cloud 1.14 ou 1.15 Pour la version 1.16 ou ultérieure, l'autorisation binaire peut être configurée lors de la création ou de la mise à jour du cluster.

VMware
Distributed Cloud pour VMware (Google Distributed Cloud) 1.4 ou version ultérieure.
Le service d'autorisation binaire utilise une adresse IP externe, accessible via une connexion Internet standard. Configurez vos règles de pare-feu pour HTTPS afin de permettre au cluster d'utilisateur d'accéder au point de terminaison binaryauthorization.googleapis.com.

Bare Metal
Configurez les règles de pare-feu Google Distributed Cloud.

VMware
Configurez les règles de pare-feu Google Distributed Cloud.
Si vous souhaitez utiliser des journaux d'audit Cloud centralisés pour afficher les entrées des journaux d'audit, y compris celles de l'autorisation binaire pour les clusters en dehors de Google Cloud, vous devez configurer Cloud Audit Logs dans la configuration de votre cluster.

Bare Metal
Configurez Cloud Audit Logs dans Google Distributed Cloud.

VMware
Configurez Cloud Audit Logs dans Google Distributed Cloud.
Vous devez activer l'API d'autorisation binaire comme suit :
1. Accédez à Google Cloud Console.
  
  Activer les API
2. Dans la liste déroulante des projets, sélectionnez votre projet hôte du parc. Vous pouvez le trouver dans la section gkeConnect de votre fichier de configuration de cluster d'utilisateur. Il s'agit du projet Google Cloud qui connecte votre cluster d'utilisateur à Google Cloud.

Configurer l'autorisation binaire

Dans cette section, vous allez configurer l'autorisation binaire dans votre cluster sur site.

Spécifier les variables d'environnement d'installation

Pour spécifier les variables d'environnement, procédez comme suit :

Utiliser Workload Identity

Spécifiez votre projet hôte du parc :
```
export PROJECT_ID=PROJECT_ID
```
Définissez l'ID de membre du parc sur l'ID de votre cluster :

L'ID de membre est indiqué dans la colonne NAME lorsque vous exécutez la commande gcloud container fleet memberships list.
```
export MEMBERSHIP_ID=CLUSTER_NAME
```

Utiliser une clé de compte de service

Spécifiez votre projet hôte du parc :
```
export PROJECT_ID=PROJECT_ID
```
Remplacez PROJECT_ID par le projet Cloud dans la section gkeConnect du fichier de configuration de votre cluster d'utilisateur.
Spécifiez le chemin d'accès au fichier kubeconfig du cluster d'utilisateur :
```
export KUBECONFIG=PATH
```
Remplacez PATH par le chemin d'accès du fichier kubeconfig de votre cluster d'utilisateur.
Choisissez un nom pour le compte de service d'accès à l'API d'autorisation binaire :
```
export SA_NAME=SERVICE_ACCOUNT_NAME
```
Remplacez SERVICE_ACCOUNT_NAME par le nom de compte de service de votre choix. Le module d'autorisation binaire utilise ce compte de service pour accéder à l'API d'autorisation binaire.
Spécifiez le chemin d'accès au fichier de clé de compte de service que vous allez télécharger plus loin dans ce guide :
```
export SA_JSON_PATH=SA_KEY_FILE_PATH
```
Remplacez SA_KEY_FILE_PATH par le chemin du fichier de clé JSON pour le compte de service.

Installer le module d'autorisation binaire dans votre cluster d'utilisateur

Pour installer le module d'autorisation binaire, procédez comme suit :

Utiliser Workload Identity

Fleet Workload Identity permet aux charges de travail de votre cluster de s'authentifier auprès de Google sans que vous ayez besoin de télécharger, d'alterner manuellement ni de gérer les clés des comptes de service Google Cloud. Pour en savoir plus sur le fonctionnement de Workload Identity pour parc et les avantages liés à son utilisation, consultez la page Utiliser Workload Identity de parc.

Attribuez le rôle binaryauthorization.policyEvaluator au compte de service Kubernetes sur votre projet hôte de parc :

gcloud projects add-iam-policy-binding ${PROJECT_ID} \
    --member="serviceAccount:${PROJECT_ID}.svc.id.goog[binauthz-system/binauthz-admin]" \
    --role="roles/binaryauthorization.policyEvaluator"

Créez un répertoire de travail :
1. Créez un répertoire appelé binauthz.
2. Accédez au répertoire.

Téléchargez le fichier manifest-wi-0.2.6.yaml.tmpl que vous utilisez pour installer le module d'autorisation binaire dans votre cluster d'utilisateur :

Bare Metal

gcloud storage cp gs://anthos-baremetal-release/binauthz/manifest-wi-0.2.6.yaml.tmpl .

VMware

gcloud storage cp gs://gke-on-prem-release/binauthz/manifest-wi-0.2.6.yaml.tmpl .

Remplacez les variables d'environnement dans le modèle :

envsubst < manifest-wi-0.2.6.yaml.tmpl > manifest-0.2.6.yaml

Installez le module d'autorisation binaire dans votre cluster d'utilisateur :
```
kubectl apply -f manifest-0.2.6.yaml
```

Vérifiez que le déploiement a bien été créé :

kubectl get pod --namespace binauthz-system

Le pod binauthz-module-deployment-* est répertorié avec Status de Running et 1/1 Pods prêt, semblable à ce résultat :

NAME                                          READY   STATUS    RESTARTS   AGE
binauthz-module-deployment-5fddf9594f-qjprz   1/1     Running   0          11s

Utiliser une clé de compte de service

Définissez le projet par défaut pour la Google Cloud CLI :
```
gcloud config set project ${PROJECT_ID}
```
Créez un compte de service d'accès à l'API d'autorisation binaire :
```
gcloud iam service-accounts create ${SA_NAME}
```

Attribuez le rôle binaryauthorization.policyEvaluator au compte de service d'accès de l'API d'autorisation binaire sur votre projet hôte de parc :

gcloud projects add-iam-policy-binding ${PROJECT_ID}\
    --member="serviceAccount:${SA_NAME}@${PROJECT_ID}.iam.gserviceaccount.com" \
    --role="roles/binaryauthorization.policyEvaluator"

Créez un répertoire de travail :
1. Créez un répertoire appelé binauthz.
2. Accédez au répertoire.

Téléchargez le fichier manifest-0.2.6.yaml que vous utilisez pour installer le module d'autorisation binaire dans votre cluster d'utilisateur :

Bare Metal

gcloud storage cp gs://anthos-baremetal-release/binauthz/manifest-0.2.6.yaml .

VMware

gcloud storage cp gs://gke-on-prem-release/binauthz/manifest-0.2.6.yaml .

Créez un fichier YAML pour l'espace de noms binauthz-system.

Copiez le fichier suivant dans un fichier nommé namespace.yaml :

apiVersion: v1
kind: Namespace
metadata:
  labels:
    control-plane: binauthz-controller
  name: binauthz-system

Créez l'espace de noms dans votre cluster d'utilisateur :
```
kubectl apply -f namespace.yaml
```
Vous obtenez un résultat semblable à celui-ci :
```
namespace/binauthz-system created
```

Téléchargez un fichier de clé JSON associé à votre compte de service :

gcloud iam service-accounts keys create ${SA_JSON_PATH} --iam-account ${SA_NAME}@${PROJECT_ID}.iam.gserviceaccount.com

Enregistrez la clé du compte de service en tant que secret Kubernetes dans votre cluster d'utilisateur :

kubectl --namespace binauthz-system create secret generic binauthz-sa --from-file=key.json=${SA_JSON_PATH}

Installez le module d'autorisation binaire dans votre cluster d'utilisateur :
```
kubectl apply -f manifest-0.2.6.yaml
```

Vérifiez que le déploiement a bien été créé :

kubectl get pod --namespace binauthz-system

Le pod binauthz-module-deployment-* est répertorié avec Status de Running et 1/1 Pods prêt, semblable à ce résultat :

NAME                                          READY   STATUS    RESTARTS   AGE
binauthz-module-deployment-5fddf9594f-qjprz   1/1     Running   0          11s

Configurer et utiliser des stratégies d'autorisation binaire

Cette section vous explique comment configurer et utiliser des stratégies d'autorisation binaire pour les clusters sur site.

Dans chaque exemple, vous configurez la règle, puis la testez en essayant de déployer une image de conteneur dans votre cluster.

Tout autoriser

Cette section décrit un cas de réussite. Vous configurez la stratégie d'autorisation binaire de sorte qu'une image de conteneur respecte la stratégie et soit déployée.

Dans Google Cloud, procédez comme suit :

Console

Dans Google Cloud Console, accédez à la page "Autorisation binaire".

Accéder à la page "Autorisation binaire"
Veillez à sélectionner l'ID de votre projet hôte de parc.
Cliquez sur Modifier la stratégie.
Sous Règle par défaut du projet, sélectionnez Autoriser toutes les images.
Cliquez sur Save Policy (Enregistrer la stratégie).

gcloud

Définissez PROJECT_ID pour votre projet hôte de parc. Vous pouvez trouver cet ID de projet dans le champ gkeConnect de votre fichier de configuration de cluster d'utilisateur.
```
export PROJECT_ID=PROJECT_ID
```
Définissez le projet Google Cloud par défaut.
```
gcloud config set project ${PROJECT_ID}
```

Exportez le fichier YAML de stratégie vers votre système local :

gcloud container binauthz policy export  > policy.yaml

Votre fichier YAML se présente comme suit :

defaultAdmissionRule:
  enforcementMode: ENFORCED_BLOCK_AND_AUDIT_LOG
  evaluationMode: ALWAYS_ALLOW
globalPolicyEvaluationMode: ENABLE
name: projects/<var>PROJECT_ID</var>/policy

Modifier policy.yaml.
Définissez evaluationMode sur ALWAYS_ALLOW.
Si le fichier contient un bloc requireAttestationsBy, supprimez ce bloc.
Enregistrez le fichier.

Importez policy.yaml comme suit :

gcloud container binauthz policy import policy.yaml

Pour ajouter une image exclue à la liste d'autorisation, ajoutez le code suivant au fichier de règles :

admissionWhitelistPatterns:
  - namePattern: EXEMPT_IMAGE_PATH

Remplacez EXEMPT_IMAGE_PATH par le chemin d'accès à l'image que vous souhaitez exclure. Pour exclure des images supplémentaires, ajoutez d'autres entrées - namePattern. En savoir plus sur admissionWhitelistPatterns.

Sur votre poste de travail administrateur, procédez comme suit :

Créez un fichier manifeste pour un pod.

Enregistrez le fichier suivant dans un fichier nommé pod.yaml :

apiVersion: v1
kind: Pod
metadata:
  name: test-pod
spec:
  containers:
  - name: test-container
    image: gcr.io/google-samples/hello-app@sha256:c62ead5b8c15c231f9e786250b07909daf6c266d0fcddd93fea882eb722c3be4

Créez le pod :
```
kubectl apply -f pod.yaml
```
Vous constatez que le pod a bien été déployé.
Supprimez le pod :
```
kubectl delete -f pod.yaml
```

Refuser pour l'ensemble

Cette section présente un exemple d'échec. Dans cette section, vous allez configurer la stratégie par défaut pour interdire le déploiement de votre image de conteneur.

Dans Google Cloud, procédez comme suit :

Console

Dans Google Cloud Console, accédez à la page "Autorisation binaire".

Accéder à la page "Autorisation binaire"
Assurez-vous que votre projet hôte du parc est sélectionné.
Cliquez sur Modifier la stratégie.
Sous Règle par défaut du projet, sélectionnez Interdire toutes les images.
Cliquez sur Enregistrer la règle.

gcloud

Définissez PROJECT_ID sur l'ID de votre projet hôte de parc.
```
export PROJECT_ID=PROJECT_ID
```
Définissez le projet Google Cloud par défaut.
```
gcloud config set project ${PROJECT_ID}
```

Exportez le fichier YAML de stratégie :

gcloud container binauthz policy export  > policy.yaml

Modifier policy.yaml.
Définissez evaluationMode sur ALWAYS_DENY.
Si le fichier contient un bloc requireAttestationsBy, supprimez ce bloc.
Enregistrez le fichier.

Importez policy.yaml comme suit :

gcloud container binauthz policy import policy.yaml

Sur votre poste de travail administrateur, procédez comme suit :

Créez un fichier manifeste pour un pod.

Enregistrez le fichier suivant dans un fichier nommé pod.yaml :

apiVersion: v1
kind: Pod
metadata:
  name: test-pod
spec:
  containers:
  - name: test-container
    image: gcr.io/google-samples/hello-app@sha256:c62ead5b8c15c231f9e786250b07909daf6c266d0fcddd93fea882eb722c3be4

Créez le pod :

kubectl apply -f pod.yaml

Vous constatez que le déploiement du pod a été bloqué. La sortie ressemble à ceci :

Error from server (VIOLATES_POLICY): error when creating "pod.yaml": admission webhook "binaryauthorization.googleapis.com" denied the request: Denied by default admission rule. Overridden by evaluation mode

Obtenir l'ID de ressource du cluster d'utilisateur

Cette section explique comment composer l'ID de ressource du cluster pour votre cluster d'utilisateur. Dans votre stratégie d'autorisation binaire, vous pouvez créer des règles spécifiques à un cluster. Vous associez ces règles à un ID de ressource spécifique à un cluster, qui est basé sur votre ID de cluster.

Vous obtenez l'ID de ressource comme suit :

Console

Dans la console Google Cloud, accédez à la page Clusters GKE.

accéder aux clusters
Sélectionnez l'ID du projet hôte du parc pour vos clusters. Vous pouvez trouver cet ID de projet dans la section gkeConnect de votre fichier de configuration de cluster d'utilisateur.
Dans la liste des clusters, recherchez l'ID de votre cluster dans la colonne Nom.
Pour créer l'ID de ressource, ajoutez le préfixe global. à l'ID de cluster afin que l'ID de ressource ait le format suivant : global.CLUSTER_ID.

gcloud

Utilisez SSH pour vous connecter à votre poste de travail administrateur.
Sur le poste de travail administrateur, exécutez la commande suivante :
```
kubectl get membership -o yaml
```

Obtenez l'ID de cluster à partir du champ spec.owner.id du résultat. Exemple de résultat :

apiVersion: v1
items:
- apiVersion: hub.gke.io/v1
  kind: Membership
  ...
  spec:
    owner:
      id: //gkehub.googleapis.com/projects/PROJECT_NUMBER/locations/global/memberships/my-cluster-id

Dans l'exemple de résultat, l'ID de cluster est my-cluster-id.

Pour créer l'ID de ressource, ajoutez le préfixe global. à l'ID de cluster. Dans l'exemple, l'ID de ressource est global.my-cluster-id.

Vous pouvez utiliser cet ID de ressource lorsque vous définissez des règles spécifiques à un cluster. Découvrez comment définir des règles spécifiques à un cluster à l'aide de la console Google Cloud ou de la CLI gcloud.

Mettre à jour la stratégie d'échec

Le webhook du module d'autorisation binaire peut être configuré en mode fail open ou fail closed.

Configuration fermée ("fail close")

Pour mettre à jour la stratégie d'échec, procédez comme suit :

Modifiez le fichier manifest-0.2.6.yaml et définissez la règle "failurePolicy" sur Fail.

Réactivez le webhook :

kubectl apply -f manifest-0.2.6.yaml

Vous obtenez un résultat semblable à celui-ci :

serviceaccount/binauthz-admin unchanged
role.rbac.authorization.k8s.io/binauthz-role configured
clusterrole.rbac.authorization.k8s.io/binauthz-role configured
rolebinding.rbac.authorization.k8s.io/binauthz-rolebinding unchanged
clusterrolebinding.rbac.authorization.k8s.io/binauthz-rolebinding unchanged
secret/binauthz-tls unchanged
service/binauthz unchanged
deployment.apps/binauthz-module-deployment unchanged
validatingwebhookconfiguration.admissionregistration.k8s.io/binauthz-validating-webhook-configuration configured

Configuration ouverte ("fail open")

Pour mettre à jour la stratégie d'échec, procédez comme suit :

Modifiez le fichier manifest-0.2.6.yaml et définissez la règle "failurePolicy" sur Ignore.

Réactivez le webhook :

kubectl apply -f manifest-0.2.6.yaml

Vous obtenez un résultat semblable à celui-ci :

serviceaccount/binauthz-admin unchanged
role.rbac.authorization.k8s.io/binauthz-role configured
clusterrole.rbac.authorization.k8s.io/binauthz-role configured
rolebinding.rbac.authorization.k8s.io/binauthz-rolebinding unchanged
clusterrolebinding.rbac.authorization.k8s.io/binauthz-rolebinding unchanged
secret/binauthz-tls unchanged
service/binauthz unchanged
deployment.apps/binauthz-module-deployment unchanged
validatingwebhookconfiguration.admissionregistration.k8s.io/binauthz-validating-webhook-configuration configured

Pour en savoir plus, consultez la page Stratégie d'échec des webhooks.

Effectuer un nettoyage

L'exemple de code suivant montre comment désactiver le webhook :

kubectl delete ValidatingWebhookConfiguration/binauthz-validating-webhook-configuration

L'exemple de code suivant montre comment réactiver le webhook :
```
kubectl apply -f manifest-0.2.6.yaml
```
L'exemple de code suivant montre comment supprimer toutes les ressources liées à l'autorisation binaire :
```
kubectl delete -f manifest-0.2.6.yaml
kubectl delete namespace binauthz-system
```

Étape suivante

Pour vérifier la conformité avec les règles au moment de la création du pod sans empêcher la création effective du pod, consultez la section Activer la simulation.
Pour forcer la création d'un pod que l'outil d'application de l'autorisation binaire bloquerait, consultez la section Utiliser le mode "bris de glace".
Utilisez le certificateur built-by-cloud-build pour déployer uniquement les images créées par Cloud Build.
Pour mettre en œuvre une stratégie d'autorisation binaire basée sur un certificateur, consultez les articles suivants :
- Configurez une stratégie à l'aide de Google Cloud Console ou de l'outil de ligne de commande. Définissez la règle par défaut ou spécifique au cluster pour exiger des attestations.
- Créez un certificateur à l'aide de Google Cloud Console ou de l'outil de ligne de commande.
- Créer une attestation.
Pour afficher les événements de journal liés à l'autorisation binaire pour Distributed Cloud, consultez la page Afficher les événements Cloud Audit Logs.
Surveiller les métriques