GSP1183

Présentation

L'autorisation binaire est un contrôle de sécurité intervenant au moment du déploiement qui garantit que seules des images de conteneur fiables sont déployées sur Google Kubernetes Engine (GKE) ou Cloud Run. Avec l'autorisation binaire, vous pouvez exiger que toutes les images soient signées par des autorités de confiance lors du processus de développement, puis appliquer la validation de signature lors du déploiement. Grâce à cette validation, vous pouvez exercer un contrôle plus strict sur votre environnement de conteneurs en vous assurant que seules les images validées sont intégrées au processus de compilation et de déploiement.

Le schéma suivant présente les composants utilisés dans une configuration d'autorisation binaire avec Cloud Build :

Pipeline Cloud Build qui crée une attestation d'autorisation binaire.

Dans ce pipeline :

1. Le code permettant de créer l'image de conteneur est transféré vers un dépôt source, tel que Cloud Source Repositories.
2. Un outil d'intégration continue (CI), tel que Cloud Build, compile et teste le conteneur.
3. La compilation envoie l'image du conteneur à Container Registry ou à un autre registre qui stocke les images compilées.
4. Cloud Key Management Service, qui assure la gestion des clés pour la paire de clés cryptographiques, signe l'image du conteneur. La signature résultante est ensuite stockée dans une attestation créée pour l'occasion.
5. Au moment du déploiement, le certificateur valide l'attestation en utilisant la clé publique de la paire de clés. L'autorisation binaire applique la stratégie en exigeant des attestations signées pour déployer l'image de conteneur.

Dans cet atelier, vous allez découvrir les outils et les techniques permettant de sécuriser les artefacts déployés. Cet atelier se concentre sur les artefacts (conteneurs) après leur création, avant qu'ils ne soient déployés dans un environnement spécifique.

Points abordés

• Signature d'image
• Stratégies de contrôle d'admission
• Signature des images numérisées
• Autorisation des images signées
• Images non signées bloquées

Préparation

Avant de cliquer sur le bouton "Démarrer l'atelier"

Lisez ces instructions. Les ateliers sont minutés, et vous ne pouvez pas les mettre en pause. Le minuteur, qui démarre lorsque vous cliquez sur Démarrer l'atelier, indique combien de temps les ressources Google Cloud resteront accessibles.

Cet atelier pratique vous permet de suivre vous-même les activités dans un véritable environnement cloud, et non dans un environnement de simulation ou de démonstration. Nous vous fournissons des identifiants temporaires pour vous connecter à Google Cloud le temps de l'atelier.

Pour réaliser cet atelier :

• Vous devez avoir accès à un navigateur Internet standard (nous vous recommandons d'utiliser Chrome).

Remarque : Ouvrez une fenêtre de navigateur en mode navigation privée pour effectuer cet atelier. Vous éviterez ainsi les conflits entre votre compte personnel et le compte temporaire de participant, qui pourraient entraîner des frais supplémentaires facturés sur votre compte personnel.

• Vous disposez d'un temps limité. N'oubliez pas qu'une fois l'atelier commencé, vous ne pouvez pas le mettre en pause.

Remarque : Si vous possédez déjà votre propre compte ou projet Google Cloud, veillez à ne pas l'utiliser pour réaliser cet atelier afin d'éviter que des frais supplémentaires ne vous soient facturés.

Démarrer l'atelier et se connecter à la console Google Cloud

1. Cliquez sur le bouton Démarrer l'atelier. Si l'atelier est payant, un pop-up s'affiche pour vous permettre de sélectionner un mode de paiement. Sur la gauche, vous trouverez le panneau Détails concernant l'atelier, qui contient les éléments suivants :

   • Le bouton Ouvrir la console Google Cloud
   • Le temps restant
   • Les identifiants temporaires que vous devez utiliser pour cet atelier
   • Des informations complémentaires vous permettant d'effectuer l'atelier

2. Cliquez sur Ouvrir la console Google Cloud (ou effectuez un clic droit et sélectionnez Ouvrir le lien dans la fenêtre de navigation privée si vous utilisez le navigateur Chrome).

   L'atelier lance les ressources, puis ouvre la page Se connecter dans un nouvel onglet.

   Conseil : Réorganisez les onglets dans des fenêtres distinctes, placées côte à côte.

   Remarque : Si la boîte de dialogue Sélectionner un compte s'affiche, cliquez sur Utiliser un autre compte.

3. Si nécessaire, copiez le nom d'utilisateur ci-dessous et collez-le dans la boîte de dialogue Se connecter.

   {{{user_0.username | "Username"}}}

   Vous trouverez également le nom d'utilisateur dans le panneau Détails concernant l'atelier.

4. Cliquez sur Suivant.

5. Copiez le mot de passe ci-dessous et collez-le dans la boîte de dialogue Bienvenue.

   {{{user_0.password | "Password"}}}

   Vous trouverez également le mot de passe dans le panneau Détails concernant l'atelier.

6. Cliquez sur Suivant.

   Important : Vous devez utiliser les identifiants fournis pour l'atelier. N'utilisez pas les identifiants de votre compte Google Cloud. Remarque : Si vous utilisez votre propre compte Google Cloud pour cet atelier, des frais supplémentaires peuvent vous être facturés.

7. Procédez tel qu'indiqué ci-dessous sur les pages suivantes :

   • Acceptez les conditions d'utilisation.
   • N'ajoutez pas d'options de récupération ni d'authentification à deux facteurs (ce compte est temporaire).
   • Ne vous inscrivez pas à des essais sans frais.

Après quelques instants, la console Cloud s'ouvre dans cet onglet.

Remarque : Pour afficher un menu contenant la liste des produits et services Google Cloud, cliquez sur le menu de navigation en haut à gauche.

Activer Cloud Shell

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. Cloud Shell vous permet d'accéder via une ligne de commande à vos ressources Google Cloud.

1. Cliquez sur Activer Cloud Shell  en haut de la console Google Cloud.

Une fois connecté, vous êtes en principe authentifié et le projet est défini sur votre ID_PROJET : . Le résultat contient une ligne qui déclare l'ID_PROJET pour cette session :

Your Cloud Platform project in this session is set to {{{project_0.project_id | "PROJECT_ID"}}}

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.

2. (Facultatif) Vous pouvez lister les noms des comptes actifs à l'aide de cette commande :

gcloud auth list

3. Cliquez sur Autoriser.

Résultat :

ACTIVE: * ACCOUNT: {{{user_0.username | "ACCOUNT"}}} To set the active account, run: $ gcloud config set account `ACCOUNT`

4. (Facultatif) Vous pouvez lister les ID de projet à l'aide de cette commande :

gcloud config list project

Résultat :

[core] project = {{{project_0.project_id | "PROJECT_ID"}}} Remarque : Pour consulter la documentation complète sur gcloud, dans Google Cloud, accédez au guide de présentation de la gcloud CLI.

Configuration de l'environnement

Dans Cloud Shell, définissez l'ID et le numéro de votre projet. Enregistrez-les en tant que variables PROJECT_ID et PROJECT_NUMBER.

export PROJECT_ID=$(gcloud config get-value project) export PROJECT_NUMBER=$(gcloud projects describe $PROJECT_ID \ --format='value(projectNumber)')

Activer les services

Activez tous les services nécessaires :

gcloud services enable \ cloudkms.googleapis.com \ cloudbuild.googleapis.com \ container.googleapis.com \ containerregistry.googleapis.com \ artifactregistry.googleapis.com \ containerscanning.googleapis.com \ ondemandscanning.googleapis.com \ binaryauthorization.googleapis.com

Tâche 1 : Créer un dépôt Artifact Registry

Dans cet atelier, vous allez utiliser Artifact Registry pour stocker et analyser vos images.

1. Créez le dépôt à l'aide de la commande suivante :

gcloud artifacts repositories create artifact-scanning-repo \ --repository-format=docker \ --location={{{ project_0.default_region | "REGION" }}} \ --description="Docker repository"

2. Configurez Docker pour qu'il utilise vos identifiants gcloud lorsque vous accédez à Artifact Registry :

gcloud auth configure-docker {{{ project_0.default_region | "REGION" }}}-docker.pkg.dev

3. Créez un répertoire de travail et accédez-y :

mkdir vuln-scan && cd vuln-scan

4. Définissez ensuite un exemple d'image. Créez un fichier nommé Dockerfile avec les contenus suivants :

cat > ./Dockerfile << EOF FROM python:3.8-alpine # App WORKDIR /app COPY . ./ RUN pip3 install Flask==2.1.0 RUN pip3 install gunicorn==20.1.0 RUN pip3 install Werkzeug==2.2.2 CMD exec gunicorn --bind :\$PORT --workers 1 --threads 8 main:app EOF

5. Créez un fichier nommé main.py avec les contenus suivants :

cat > ./main.py << EOF import os from flask import Flask app = Flask(__name__) @app.route("/") def hello_world(): name = os.environ.get("NAME", "Worlds") return "Hello {}!".format(name) if __name__ == "__main__": app.run(debug=True, host="0.0.0.0", port=int(os.environ.get("PORT", 8080))) EOF

6. Utilisez Cloud Build pour créer et transférer automatiquement votre conteneur vers Artifact Registry.

gcloud builds submit . -t {{{ project_0.default_region | "REGION" }}}-docker.pkg.dev/${PROJECT_ID}/artifact-scanning-repo/sample-image

Cliquez sur Vérifier ma progression pour valider l'objectif. Créer un dépôt Artifact Registry

Tâche 2 : Signature d'image

Qu'est-ce qu'un certificateur ?

• Cette personne/ce processus est responsable d'un maillon de la chaîne de confiance du système.
• Le certificateur dispose d'une clé cryptographique et peut signer une image si cette dernière est approuvée après contrôle.
• Alors que le créateur de stratégie définit les règles de manière abstraite et générale, le certificateur est responsable de l'application concrète de certains aspects de la stratégie.
• Il peut s'agir d'une personne réelle, comme un testeur QA ou un responsable, ou d'un robot dans un système d'intégration continue.
• La sécurité du système dépend de sa fiabilité. Il est donc important que les clés privées soient sécurisées.

Chacun de ces rôles peut correspondre à une personne ou à une équipe de votre organisation. Dans un environnement de production, ces rôles seraient probablement gérés par des projets Google Cloud Platform distincts, et l'accès aux ressources serait partagé entre eux de manière limitée à l'aide de Cloud IAM.

L'implémentation des certificateurs dans l'autorisation binaire s'appuie sur l'API Cloud Container Analysis. Il est donc important de décrire son fonctionnement avant de continuer. L'API Container Analysis a été conçue pour vous permettre d'associer des métadonnées à des images de conteneurs spécifiques.

Par exemple, vous pouvez créer une note pour suivre la faille Heartbleed. Ensuite, les fournisseurs de sécurité créeront des outils d'analyse pour rechercher la faille dans les images de conteneurs, puis ils créeront une occurrence associée à chaque conteneur compromis.

En plus du suivi des failles, Container Analysis a été conçu comme une API de métadonnées générique. L'autorisation binaire utilise Container Analysis pour associer des signatures aux images de conteneurs qu'elles valident. Une note Container Analysis permet de représenter un seul certificateur. Des occurrences sont créées et associées à chaque conteneur approuvé par ce certificateur.

L'API d'autorisation binaire utilise les concepts de "certificateurs" et d'"attestations", mais ceux-ci sont implémentés à l'aide des notes et des occurrences correspondantes dans l'API Container Analysis.

Créer une note "Certificateur"

Une note "Certificateur" est simplement une petite quantité de données qui sert de libellé pour le type de signature appliqué. Par exemple, une note peut indiquer une analyse des failles, tandis qu'une autre peut être utilisée pour la validation QA. La note sera mentionnée lors du processus de signature.

1. Créer une note

cat > ./vulnz_note.json << EOM { "attestation": { "hint": { "human_readable_name": "Container Vulnerabilities attestation authority" } } } EOM

2. Stocker la note

NOTE_ID=vulnz_note curl -vvv -X POST \ -H "Content-Type: application/json" \ -H "Authorization: Bearer $(gcloud auth print-access-token)" \ --data-binary @./vulnz_note.json \ "https://containeranalysis.googleapis.com/v1/projects/${PROJECT_ID}/notes/?noteId=${NOTE_ID}"

3. Valider la note

curl -vvv \ -H "Authorization: Bearer $(gcloud auth print-access-token)" \ "https://containeranalysis.googleapis.com/v1/projects/${PROJECT_ID}/notes/${NOTE_ID}"

Votre note est désormais enregistrée dans l'API Container Analysis.

4. Créer un certificateur

Les certificateurs permettent d'effectuer le processus de signature d'image proprement dit. Ils associent une occurrence de la note à l'image pour une validation ultérieure. Pour utiliser votre certificateur, vous devez également enregistrer la note avec l'autorisation binaire :

5. Créer un certificateur

ATTESTOR_ID=vulnz-attestor gcloud container binauthz attestors create $ATTESTOR_ID \ --attestation-authority-note=$NOTE_ID \ --attestation-authority-note-project=${PROJECT_ID}

6. Valider le certificateur

gcloud container binauthz attestors list

La dernière ligne indique NUM_PUBLIC_KEYS: 0. Vous fournirez les clés lors d'une étape ultérieure.

Cloud Build crée automatiquement le certificateur built-by-cloud-build dans votre projet lorsque vous exécutez une compilation qui génère des images. La commande ci-dessus renvoie donc deux certificateurs : vulnz-attestor et built-by-cloud-build. Une fois les images compilées, Cloud Build signe et crée automatiquement des attestations pour celles-ci.

7. Le compte de service d'autorisation binaire devra disposer des droits nécessaires pour afficher les notes d'attestation. Fournissez l'accès au rôle IAM avec l'appel d'API suivant :

PROJECT_NUMBER=$(gcloud projects describe "${PROJECT_ID}" --format="value(projectNumber)") BINAUTHZ_SA_EMAIL="service-${PROJECT_NUMBER}@gcp-sa-binaryauthorization.iam.gserviceaccount.com" cat > ./iam_request.json << EOM { 'resource': 'projects/${PROJECT_ID}/notes/${NOTE_ID}', 'policy': { 'bindings': [ { 'role': 'roles/containeranalysis.notes.occurrences.viewer', 'members': [ 'serviceAccount:${BINAUTHZ_SA_EMAIL}' ] } ] } } EOM

8. Créez la stratégie IAM à l'aide du fichier :

curl -X POST \ -H "Content-Type: application/json" \ -H "Authorization: Bearer $(gcloud auth print-access-token)" \ --data-binary @./iam_request.json \ "https://containeranalysis.googleapis.com/v1/projects/${PROJECT_ID}/notes/${NOTE_ID}:setIamPolicy"

Cliquez sur Vérifier ma progression pour valider l'objectif. Créer un certificateur

Tâche 3 : Ajouter une clé KMS

Avant de pouvoir utiliser ce certificateur, votre autorité doit créer une paire de clés cryptographiques permettant de signer des images de conteneurs. Vous pouvez le faire via Google Cloud Key Management Service (KMS).

1. Tout d'abord, ajoutez des variables d'environnement pour décrire la nouvelle clé :

KEY_LOCATION=global KEYRING=binauthz-keys KEY_NAME=codelab-key KEY_VERSION=1

2. Créez un trousseau pour stocker un ensemble de clés :

gcloud kms keyrings create "${KEYRING}" --location="${KEY_LOCATION}"

3. Créez une paire de clés de signature asymétriques pour le certificateur :

gcloud kms keys create "${KEY_NAME}" \ --keyring="${KEYRING}" --location="${KEY_LOCATION}" \ --purpose asymmetric-signing \ --default-algorithm="ec-sign-p256-sha256"

Votre clé doit s'afficher sur la page KMS de la console Cloud.

4. Associez maintenant la clé à votre certificateur à l'aide de la commande gcloud binauthz :

gcloud beta container binauthz attestors public-keys add \ --attestor="${ATTESTOR_ID}" \ --keyversion-project="${PROJECT_ID}" \ --keyversion-location="${KEY_LOCATION}" \ --keyversion-keyring="${KEYRING}" \ --keyversion-key="${KEY_NAME}" \ --keyversion="${KEY_VERSION}"

5. Si vous imprimez à nouveau la liste des autorités, vous devez désormais voir une clé enregistrée :

gcloud container binauthz attestors list

Cliquez sur Vérifier ma progression pour valider l'objectif. Ajouter une clé KMS

Tâche 4 : Créer une attestation signée

À ce stade, vous avez configuré les fonctionnalités qui vous permettent de signer des images. Signez l'image de conteneur sur laquelle vous avez travaillé à l'aide du certificateur que vous avez créé précédemment.

Une attestation doit inclure une signature cryptographique pour indiquer que le certificateur a validé une image de conteneur spécifique et que vous pouvez l'exécuter de manière sécurisée sur votre cluster.

1. Pour spécifier l'image de conteneur à attester, exécutez la commande suivante afin de déterminer son condensé :

CONTAINER_PATH={{{ project_0.default_region | "REGION" }}}-docker.pkg.dev/${PROJECT_ID}/artifact-scanning-repo/sample-image DIGEST=$(gcloud container images describe ${CONTAINER_PATH}:latest \ --format='get(image_summary.digest)')

2. Vous pouvez désormais vous servir de gcloud pour créer votre attestation. La commande prend en compte les détails de la clé à utiliser pour la signature ainsi que l'image de conteneur spécifique à approuver :

gcloud beta container binauthz attestations sign-and-create \ --artifact-url="${CONTAINER_PATH}@${DIGEST}" \ --attestor="${ATTESTOR_ID}" \ --attestor-project="${PROJECT_ID}" \ --keyversion-project="${PROJECT_ID}" \ --keyversion-location="${KEY_LOCATION}" \ --keyversion-keyring="${KEYRING}" \ --keyversion-key="${KEY_NAME}" \ --keyversion="${KEY_VERSION}"

Concernant Container Analysis, cela créera une occurrence et l'associera à la note de votre certificateur.

3. Pour vous assurer que tout a fonctionné comme prévu, exécutez la commande suivante pour lister vos attestations :

gcloud container binauthz attestations list \ --attestor=$ATTESTOR_ID --attestor-project=${PROJECT_ID}

Tâche 5 : Stratégies de contrôle d'admission

L'autorisation binaire est une fonctionnalité de GKE et Cloud Run qui permet de valider des règles avant qu'une image de conteneur ne soit autorisée à être exécutée. La validation s'exécute sur toute requête d'exécution d'une image, qu'elle provienne d'un pipeline CI/CD fiable ou d'un utilisateur qui tente manuellement de déployer une image. Cette fonctionnalité vous permet de sécuriser vos environnements d'exécution plus efficacement que les vérifications de pipeline CI/CD seules.

Pour comprendre cette fonctionnalité, vous allez modifier la stratégie GKE par défaut afin d'appliquer une règle d'autorisation stricte.

1. Créez un cluster GKE avec l'autorisation binaire activée :

gcloud beta container clusters create binauthz \ --zone {{{ project_0.default_zone | "ZONE" }}} \ --binauthz-evaluation-mode=PROJECT_SINGLETON_POLICY_ENFORCE

2. Autorisez Cloud Build à effectuer des déploiements sur ce cluster :

gcloud projects add-iam-policy-binding ${PROJECT_ID} \ --member="serviceAccount:${PROJECT_NUMBER}@cloudbuild.gserviceaccount.com" \ --role="roles/container.developer"

Stratégie "Tout autoriser"

Vérifiez d'abord l'état de la stratégie par défaut et votre capacité à déployer n'importe quelle image.

1. Examinez la stratégie existante :

gcloud container binauthz policy export

2. Notez que la règle d'application est définie sur ALWAYS_ALLOW.

evaluationMode: ALWAYS_ALLOW

3. Déployez un exemple pour vérifier que vous pouvez déployer n'importe quoi :

kubectl run hello-server --image gcr.io/google-samples/hello-app:1.0 --port 8080

4. Vérifiez que le déploiement a fonctionné :

kubectl get pods

La sortie suivante s'affiche :

5. Supprimez le déploiement :

kubectl delete pod hello-server

Stratégie "Tout refuser"

Mettez à jour la stratégie pour interdire toutes les images.

1. Exportez la stratégie actuelle dans un fichier modifiable :

gcloud container binauthz policy export > policy.yaml

2. Dans un éditeur de texte, ouvrez le fichier policy.yaml et remplacez ALWAYS_ALLOW par ALWAYS_DENY pour evaluationMode :

edit policy.yaml

Assurez-vous que le fichier YAML de stratégie modifié se présente comme suit :

globalPolicyEvaluationMode: ENABLE defaultAdmissionRule: evaluationMode: ALWAYS_DENY enforcementMode: ENFORCED_BLOCK_AND_AUDIT_LOG name: projects/PROJECT_ID/policy

Cette stratégie est relativement simple. La ligne globalPolicyEvaluationMode déclare que cette stratégie étend la stratégie globale définie par Google. Cela permet à tous les conteneurs GKE officiels de s'exécuter par défaut. De plus, la stratégie déclare une règle defaultAdmissionRule selon laquelle tous les autres pods seront refusés. La règle d'admission inclut une ligne enforcementMode, qui indique que tous les pods non conformes à cette règle ne doivent pas pouvoir être exécutés sur le cluster.

Pour savoir comment créer des stratégies plus complexes, consultez la documentation sur l'autorisation binaire.

3. Dans Cloud Shell, exécutez la commande suivante pour appliquer la nouvelle stratégie :

gcloud container binauthz policy import policy.yaml

Attendez quelques secondes que la modification soit appliquée.

4. Essayez de déployer un exemple de charge de travail :

kubectl run hello-server --image gcr.io/google-samples/hello-app:1.0 --port 8080

5. Le déploiement échoue, et le message suivant s'affiche :

Error from server (VIOLATES_POLICY): admission webhook "imagepolicywebhook.image-policy.k8s.io" denied the request: Image gcr.io/google-samples/hello-app:1.0 denied by Binary Authorization default admission rule. Denied by always_deny admission rule

Rétablir la stratégie "Tout autoriser"

Avant de passer à la section suivante, annulez les modifications apportées à la stratégie.

1. Dans un éditeur de texte, remplacez ALWAYS_DENY par ALWAYS_ALLOW pour evaluationMode.

edit policy.yaml

Le fichier YAML de stratégie modifié doit ressembler à ceci :

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

2. Appliquez la stratégie rétablie :

gcloud container binauthz policy import policy.yaml

Cliquez sur Vérifier ma progression pour valider l'objectif. Créer un cluster GKE et mettre à jour les stratégies

Tâche 6 : Signer automatiquement des images

Vous avez activé la signature d'image et utilisé manuellement le certificateur pour signer votre exemple d'image. En pratique, vous devrez appliquer des attestations lors de processus automatisés tels que les pipelines CI/CD.

Dans cette section, vous allez configurer Cloud Build pour attester automatiquement des images.

Rôles requis

1. Attribuez le rôle "Lecteur des attesteurs de l'autorisation binaire" au compte de service Cloud Build :

gcloud projects add-iam-policy-binding ${PROJECT_ID} \ --member serviceAccount:${PROJECT_NUMBER}@cloudbuild.gserviceaccount.com \ --role roles/binaryauthorization.attestorsViewer

2. Attribuez le rôle "Signataire/Validateur de CryptoKeys Cloud KMS" au compte de service Cloud Build (signature basée sur KMS) :

gcloud projects add-iam-policy-binding ${PROJECT_ID} \ --member serviceAccount:${PROJECT_NUMBER}@cloudbuild.gserviceaccount.com \ --role roles/cloudkms.signerVerifier gcloud projects add-iam-policy-binding ${PROJECT_ID} \ --member serviceAccount:${PROJECT_NUMBER}-compute@developer.gserviceaccount.com \ --role roles/cloudkms.signerVerifier

3. Attribuez le rôle "Agent d'association de notes Container Analysis" au compte de service Cloud Build :

gcloud projects add-iam-policy-binding ${PROJECT_ID} \ --member serviceAccount:${PROJECT_NUMBER}@cloudbuild.gserviceaccount.com \ --role roles/containeranalysis.notes.attacher

Configurer l'accès pour le compte de service Cloud Build

Cloud Build aura besoin d'autorisations pour accéder à l'API On-Demand Scanning.

• Accordez l'accès à l'aide des commandes suivantes :

gcloud projects add-iam-policy-binding ${PROJECT_ID} \ --member="serviceAccount:${PROJECT_NUMBER}@cloudbuild.gserviceaccount.com" \ --role="roles/iam.serviceAccountUser" gcloud projects add-iam-policy-binding ${PROJECT_ID} \ --member="serviceAccount:${PROJECT_NUMBER}@cloudbuild.gserviceaccount.com" \ --role="roles/ondemandscanning.admin"

Préparer l'étape de compilation personnalisée Cloud Build

Vous allez utiliser une étape de compilation personnalisée dans Cloud Build pour simplifier le processus d'attestation. Google fournit cette étape de compilation personnalisée qui contient des fonctions d'assistance pour simplifier le processus. Avant toute utilisation, le code de l'étape de compilation personnalisée doit être intégré à un conteneur et transféré vers Cloud Build.

• Pour ce faire, exécutez les commandes suivantes :

git clone https://github.com/GoogleCloudPlatform/cloud-builders-community.git cd cloud-builders-community/binauthz-attestation gcloud builds submit . --config cloudbuild.yaml cd ../.. rm -rf cloud-builders-community

Ajouter une étape de signature à votre fichier cloudbuild.yaml

Ajoutez l'étape d'attestation à votre pipeline Cloud Build.

1. Consultez l'étape de signature ci-dessous.

Pour examen uniquement. Ne pas copier.

#Ne signer l'image qu'en cas de réussite de la précédente vérification du niveau de gravité - id: 'create-attestation' name: 'gcr.io/${PROJECT_ID}/binauthz-attestation:latest' args: - '--artifact-url' - '{{{ project_0.default_region | "REGION" }}}-docker.pkg.dev/${PROJECT_ID}/artifact-scanning-repo/sample-image' - '--attestor' - 'projects/${PROJECT_ID}/attestors/$ATTESTOR_ID' - '--keyversion' - 'projects/${PROJECT_ID}/locations/$KEY_LOCATION/keyRings/$KEYRING/cryptoKeys/$KEY_NAME/cryptoKeyVersions/$KEY_VERSION'

2. Écrivez un fichier cloudbuild.yaml avec le pipeline complet ci-dessous :

cat > ./cloudbuild.yaml << EOF steps: # compiler - id: "build" name: 'gcr.io/cloud-builders/docker' args: ['build', '-t', '{{{ project_0.default_region | "REGION" }}}-docker.pkg.dev/${PROJECT_ID}/artifact-scanning-repo/sample-image', '.'] waitFor: ['-'] # vérifications CICD supplémentaires (non affichées) #Retaguer - id: "retag" name: 'gcr.io/cloud-builders/docker' args: ['tag', '{{{ project_0.default_region | "REGION" }}}-docker.pkg.dev/${PROJECT_ID}/artifact-scanning-repo/sample-image', '{{{ project_0.default_region | "REGION" }}}-docker.pkg.dev/${PROJECT_ID}/artifact-scanning-repo/sample-image:good'] #transférer vers Artifact Registry - id: "push" name: 'gcr.io/cloud-builders/docker' args: ['push', '{{{ project_0.default_region | "REGION" }}}-docker.pkg.dev/${PROJECT_ID}/artifact-scanning-repo/sample-image:good'] #Ne signer l'image qu'en cas de réussite de la précédente vérification du niveau de gravité - id: 'create-attestation' name: 'gcr.io/${PROJECT_ID}/binauthz-attestation:latest' args: - '--artifact-url' - '{{{ project_0.default_region | "REGION" }}}-docker.pkg.dev/${PROJECT_ID}/artifact-scanning-repo/sample-image:good' - '--attestor' - 'projects/${PROJECT_ID}/attestors/$ATTESTOR_ID' - '--keyversion' - 'projects/${PROJECT_ID}/locations/$KEY_LOCATION/keyRings/$KEYRING/cryptoKeys/$KEY_NAME/cryptoKeyVersions/$KEY_VERSION' images: - {{{ project_0.default_region | "REGION" }}}-docker.pkg.dev/${PROJECT_ID}/artifact-scanning-repo/sample-image:good EOF

3. Exécutez la compilation :

gcloud builds submit

Examiner la compilation dans l'historique Cloud Build

Dans la console Cloud, accédez à Cloud Build > page Historique de compilation. Ensuite, vérifiez la dernière compilation et la bonne exécution des étapes de compilation.

Cliquez sur Vérifier ma progression pour valider l'objectif. Ajouter une étape de signature

Tâche 7 : Autoriser des images signées

Vous allez maintenant mettre à jour GKE pour qu'il utilise l'autorisation binaire afin de valider que l'image a une signature à partir de l'analyse des failles avant d'autoriser son exécution.

Mettre à jour la stratégie GKE pour exiger l'attestation

Exigez que les images soient signées par votre certificateur en ajoutant "clusterAdmissionRules" à votre stratégie d'autorisation binaire GKE.

Actuellement, votre cluster exécute une stratégie avec une règle qui autorise les conteneurs provenant de dépôts officiels et refuse tous les autres.

1. Écrasez la stratégie avec la configuration mise à jour à l'aide de la commande ci-dessous :

COMPUTE_ZONE={{{ project_0.default_region | "REGION" }}} cat > binauth_policy.yaml << EOM defaultAdmissionRule: enforcementMode: ENFORCED_BLOCK_AND_AUDIT_LOG evaluationMode: REQUIRE_ATTESTATION requireAttestationsBy: - projects/${PROJECT_ID}/attestors/vulnz-attestor globalPolicyEvaluationMode: ENABLE clusterAdmissionRules: ${COMPUTE_ZONE}.binauthz: evaluationMode: REQUIRE_ATTESTATION enforcementMode: ENFORCED_BLOCK_AND_AUDIT_LOG requireAttestationsBy: - projects/${PROJECT_ID}/attestors/vulnz-attestor EOM

2. Votre disque doit désormais comporter un nouveau fichier appelé updated_policy.yaml. À présent, au lieu de rejeter toutes les images par défaut, la règle vérifie d'abord les validations de votre certificateur.

3. Importez la nouvelle stratégie dans l'autorisation binaire :

gcloud beta container binauthz policy import binauth_policy.yaml

Déployer une image signée

1. Récupérez le condensé pour la bonne image :

CONTAINER_PATH={{{ project_0.default_region | "REGION" }}}-docker.pkg.dev/${PROJECT_ID}/artifact-scanning-repo/sample-image DIGEST=$(gcloud container images describe ${CONTAINER_PATH}:good \ --format='get(image_summary.digest)')

2. Utilisez le condensé dans la configuration Kubernetes :

cat > deploy.yaml << EOM apiVersion: v1 kind: Service metadata: name: deb-httpd spec: selector: app: deb-httpd ports: - protocol: TCP port: 80 targetPort: 8080 --- apiVersion: apps/v1 kind: Deployment metadata: name: deb-httpd spec: replicas: 1 selector: matchLabels: app: deb-httpd template: metadata: labels: app: deb-httpd spec: containers: - name: deb-httpd image: ${CONTAINER_PATH}@${DIGEST} ports: - containerPort: 8080 env: - name: PORT value: "8080" EOM

3. Déployer l'application sur GKE

kubectl apply -f deploy.yaml

Dans la console Cloud, accédez à Kubernetes Engine > Charges de travail. Ensuite, vérifiez que l'image a bien été déployée.

Cliquez sur Vérifier ma progression pour valider l'objectif. Déployer une image signée

Tâche 8 : Images non signées bloquées

Créer une image

1. Utilisez Docker en local pour créer l'image dans votre cache local :

docker build -t {{{ project_0.default_region | "REGION" }}}-docker.pkg.dev/${PROJECT_ID}/artifact-scanning-repo/sample-image:bad .

2. Transférez l'image non signée dans le dépôt :

docker push {{{ project_0.default_region | "REGION" }}}-docker.pkg.dev/${PROJECT_ID}/artifact-scanning-repo/sample-image:bad

3. Récupérez le condensé pour la mauvaise image :

CONTAINER_PATH={{{ project_0.default_region | "REGION" }}}-docker.pkg.dev/${PROJECT_ID}/artifact-scanning-repo/sample-image DIGEST=$(gcloud container images describe ${CONTAINER_PATH}:bad \ --format='get(image_summary.digest)')

4. Utilisez le condensé dans la configuration Kubernetes :

cat > deploy.yaml << EOM apiVersion: v1 kind: Service metadata: name: deb-httpd spec: selector: app: deb-httpd ports: - protocol: TCP port: 80 targetPort: 8080 --- apiVersion: apps/v1 kind: Deployment metadata: name: deb-httpd spec: replicas: 1 selector: matchLabels: app: deb-httpd template: metadata: labels: app: deb-httpd spec: containers: - name: deb-httpd image: ${CONTAINER_PATH}@${DIGEST} ports: - containerPort: 8080 env: - name: PORT value: "8080" EOM

5. Essayez de déployer l'application sur GKE :

kubectl apply -f deploy.yaml

Examinez la charge de travail dans la console et notez l'erreur indiquant que le déploiement a été refusé :

No attestations found that were valid and signed by a key trusted by the attestor

Cliquez sur Vérifier ma progression pour valider l'objectif. Déployer une image non signée

Félicitations !

Vous avez appris à créer un certificateur pour signer des images afin de valider des règles avant qu'une image de conteneur ne soit autorisée à être exécutée. Vous avez appris à écrire une stratégie pour indiquer à Cloud Build d'autoriser ou de refuser l'accès au cluster GKE. Vous avez également utilisé l'autorisation binaire avec Google Cloud KMS pour valider les signatures d'image et empêcher l'accès des images non signées au cluster Kubernetes.

Étapes suivantes et informations supplémentaires

• Sécuriser les déploiements d'images sur Cloud Run et Google Kubernetes Engine | Documentation Cloud Build
• Guide de démarrage rapide : configurer une stratégie d'autorisation binaire avec GKE | Google Cloud

Formations et certifications Google Cloud

Les formations et certifications Google Cloud vous aident à tirer pleinement parti des technologies Google Cloud. Nos cours portent sur les compétences techniques et les bonnes pratiques à suivre pour être rapidement opérationnel et poursuivre votre apprentissage. Nous proposons des formations pour tous les niveaux, à la demande, en salle et à distance, pour nous adapter aux emplois du temps de chacun. Les certifications vous permettent de valider et de démontrer vos compétences et votre expérience en matière de technologies Google Cloud.

Dernière mise à jour du manuel : 10 septembre 2024

Dernier test de l'atelier : 11 juillet 2024

Copyright 2024 Google LLC Tous droits réservés. Google et le logo Google sont des marques de Google LLC. Tous les autres noms de société et de produit peuvent être des marques des sociétés auxquelles ils sont associés.