Premiers pas avec la console Google Cloud (GKE)

Ce tutoriel explique comment configurer et tester une stratégie d'autorisation binaire exigeant des attestations. Ce type de stratégie sécurise votre chaîne d'approvisionnement logicielle basée sur des conteneurs en définissant qui est autorisé à déployer des images de conteneurs sur Google Kubernetes Engine (GKE) et quelles images de conteneurs peuvent être déployées sur GKE.

Au moment du déploiement, l'autorisation binaire utilise des certificateurs pour valider les signatures numériques figurant dans les attestations. Les attestations sont créées par des signataires dans le cadre du processus de compilation.

Dans ce tutoriel, le cluster GKE, les attestations et les certificateurs se trouvent tous dans le même projet. L'intérêt d'une configuration à projet unique est principalement de tester et réaliser des expériences avec le service. Pour obtenir un exemple plus concret, consultez la page Configuration multiprojets.

Les étapes ci-dessous décrivent les tâches que vous effectuez dans la console Google Cloud, ainsi que certaines tâches réalisées à l'aide des commandes gcloud. Pour effectuer ces étapes avec gcloud, consultez la page Premiers pas avec Google Cloud CLI.

Objectifs

Dans ce tutoriel, vous allez apprendre à effectuer les opérations suivantes :

  • Créer un cluster (GKE) avec l'autorisation binaire activée
  • Créer un certificateur utilisé par l'outil d'application de l'autorisation binaire pour valider la signature d'une attestation
  • Configurer une stratégie exigeant une attestation
  • Créer une paire de clés cryptographiques pour signer les attestations puis les valider
  • Signer un condensé d'image de conteneur pour générer une signature
  • Créer une attestation à l'aide de la signature
  • Tester la stratégie en déployant une image de conteneur sur GKE

Coûts

Dans ce document, vous utilisez les composants facturables suivants de Google Cloud :

Obtenez une estimation des coûts en fonction de votre utilisation prévue à l'aide du simulateur de coût. Les nouveaux utilisateurs de Google Cloud peuvent bénéficier d'un essai gratuit.

Avant de commencer

  1. Sign in to your Google Cloud account. If you're new to Google Cloud, create an account to evaluate how our products perform in real-world scenarios. New customers also get $300 in free credits to run, test, and deploy workloads.

  2. In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

    Go to project selector

  3. Make sure that billing is enabled for your Google Cloud project.

  4. Enable the Container Registry, Artifact Analysis and Binary Authorization APIs.

    Enable the APIs

  5. Install the Google Cloud CLI.

  6. To initialize the gcloud CLI, run the following command: 

    gcloud init

  7. In the Google Cloud console, on the project selector page, select or create a Google Cloud project.

    Go to project selector

  8. Make sure that billing is enabled for your Google Cloud project.

  9. Enable the Container Registry, Artifact Analysis and Binary Authorization APIs.

    Enable the APIs

  10. Install the Google Cloud CLI.

  11. To initialize the gcloud CLI, run the following command: 

    gcloud init
  12. Installez kubectl.

Définir le projet par défaut

Pour faciliter les commandes suivantes, enregistrez votre ID de projet Google Cloud dans une variable d'environnement comme suit :

PROJECT_ID=PROJECT_ID

où PROJECT_ID est le nom de votre projet.

Si le projet par défaut n'est pas sélectionné, définissez-le maintenant :

gcloud config set project ${PROJECT_ID}

Créer un cluster avec l'autorisation binaire activée

Créer le cluster

Vous pouvez maintenant créer un cluster GKE sur lequel l'autorisation binaire est activée. Ici, vous créez un cluster nommé test-cluster dans la zone GKE us-central1-a.

Pour créer le cluster, procédez comme suit :

  1. Accédez au menu GKE dans la console Google Cloud.

    Accéder à la page GKE

  2. Cliquez sur Create Cluster (Créer le cluster).

  3. Saisissez test-cluster dans le champ Nom.

  4. Sélectionnez Zonal dans les options Type d'emplacement.

  5. Sélectionnez us-central1-a dans la liste déroulante Zone.

  6. Cliquez sur Availability, Networking, Security, and Additional Features (Disponibilité, mise en réseau, sécurité et autres fonctionnalités).

  7. Dans la section Security (Sécurité), sélectionnez Enable Binary Authorization (Activer l'autorisation binaire).

  8. Sélectionnez Appliquer uniquement.

  9. Cliquez sur Créer.

Configurer kubectl

Vous devez également mettre à jour le fichier kubeconfig local pour votre installation kubectl. Cela fournit les identifiants et les informations de point de terminaison requis pour accéder au cluster dans GKE.

Pour mettre à jour le fichier kubeconfig local, exécutez la commande suivante :

gcloud container clusters get-credentials \
    --zone us-central1-a \
    test-cluster

Afficher la stratégie par défaut

Dans l'autorisation binaire, une stratégie est un ensemble de règles régissant le déploiement d'une ou plusieurs images de conteneurs. Vous pouvez définir une stratégie par projet. Par défaut, la stratégie est configurée pour autoriser le déploiement de toutes les images de conteneurs.

Pour afficher la stratégie par défaut, procédez comme suit :

  1. Accédez à la page "Autorisation binaire" dans Google Cloud Console.

    Accéder à la page "Autorisation binaire"

  2. Cliquez sur Modifier la règle.

  3. Dans Règle par défaut du projet, l'option Allow All Images (Autoriser toutes les images) est affichée.

  4. Cliquez sur Enregistrer la règle.

Créer un certificateur

Un certificateur est l'autorité de validation utilisée par l'outil d'application de l'autorisation binaire au moment du déploiement pour décider d'autoriser ou non GKE à déployer l'image de conteneur signée correspondante. Le certificateur contient la clé publique et, en règle générale, il est géré par les personnes responsables de la sécurité de la chaîne d'approvisionnement logicielle.

Pour créer un certificateur, vous devez effectuer les actions suivantes :

  • Créer le certificat proprement dit dans l'autorisation binaire
  • Générer automatiquement une note de certificateur associée dans Artifact Analysis, pour y stocker les métadonnées d'attestation de confiance utilisées dans le cadre du processus d'autorisation.

Pour ce tutoriel, vous disposez d'un certificateur nommé test-attestor. Dans un scénario réel, vous pouvez avoir un nombre illimité de certificateurs, chacun représentant une partie prenante du processus d'autorisation de l'image.

Générer une paire de clés

L'autorisation binaire utilise des clés cryptographiques pour vérifier de manière sécurisée l'identité des signataires. Cela garantit que seules les images de conteneur autorisées peuvent être déployées. La paire de clés comprend une clé privée et une clé publique. Le signataire utilise la clé privée pour signer le condensé de l'image de conteneur, produisant ainsi une signature qui est ensuite stockée dans une attestation. La clé publique est stockée dans le certificateur. Au moment du déploiement, l'outil d'application de l'autorisation binaire utilise la clé publique du certificateur pour valider la signature figurant dans l'attestation, avant d'autoriser le déploiement du conteneur.

Dans ce tutoriel, vous allez utiliser le format d'infrastructure à clé publique (X.509) (PKIX) pour les clés cryptographiques. Ce tutoriel utilise l'algorithme de signature numérique à courbe elliptique (ECDSA) recommandé pour générer une paire de clés PKIX. Vous pouvez également utiliser des clés RSA ou PGP pour la signature. Consultez la page Objectifs et algorithmes des clés pour plus d'informations sur les algorithmes de signature.

Les clés générées et stockées par le service Cloud Key Management Service (Cloud KMS) sont compatibles avec PKIX. Consultez la page Créer des certificateurs à l'aide de la CLI pour plus d'informations sur l'utilisation des clés PKIX et de Cloud KMS.

Pour générer une paire de clés PKIX, procédez comme suit :

  1. Créez la clé privée :

    PRIVATE_KEY_FILE="/tmp/ec_private.pem"
openssl ecparam -genkey -name prime256v1 -noout -out ${PRIVATE_KEY_FILE}

  2. Extrayez la clé publique de la clé privée :

    PUBLIC_KEY_FILE="/tmp/ec_public.pem"
openssl ec -in ${PRIVATE_KEY_FILE} -pubout -out ${PUBLIC_KEY_FILE}

Créer le certificateur

Vous pouvez maintenant créer le certificateur proprement dit dans l'autorisation binaire et lui associer la clé publique que vous avez créée.

Pour créer le certificateur, procédez comme suit :

  1. Revenez à la page "Autorisation binaire" dans la console Google Cloud.

    Revenir à l'autorisation binaire

  2. Dans l'onglet Attestors (Certificateurs), cliquez sur Create (Créer).

    Capture d'écran de l'onglet Policy (Stratégie) affichant la règle par défaut

  3. Renseignez les champs comme suit :

    1. Saisissez test-attestor dans le champ Nom du certificateur.

    2. Vérifiez que la case Automatically create a Artifact Analysis note (Créer automatiquement une note Container Analysis) est cochée.

    3. Cliquez sur Ajouter une clé publique PKIX.

    4. Ouvrez /tmp/ec_public.pem dans un éditeur de texte. Il s'agit du fichier de clé publique que vous avez créé à l'étape précédente. Copiez le contenu du fichier dans la zone de texte Matériel de clé publique.

    5. Cliquez sur Elliptic Curve P-256 - SHA256 Digest dans le menu déroulant Algorithme de signature.

    6. Cliquez sur OK.

  4. Cliquez sur Créer pour créer le certificateur.

  5. Stockez l'ID de la clé publique.

    Pour afficher l'ID de clé publique de votre certificateur après son ajout, utilisez la commande gcloud container binauthz attestors describe ${ATTESTOR_NAME} : Pour créer une variable d'environnement permettant de stocker l'ID de clé publique, exécutez la commande suivante :

    ATTESTOR_NAME=test-attestor
PUBLIC_KEY_ID=$(gcloud container binauthz attestors describe ${ATTESTOR_NAME}\
  --format='value(userOwnedGrafeasNote.publicKeys[0].id)')

Configurer la stratégie

Vous pouvez maintenant configurer votre stratégie :

  1. Revenez à la page "Autorisation binaire" dans la console Google Cloud.

  2. Dans l'onglet Règles, cliquez sur Modifier la règle.

  3. Sélectionnez Autoriser uniquement les images qui ont été approuvées par tous les attesteurs suivants.

  4. Cliquez sur Ajouter des certificateurs.

  5. Cliquez sur Ajouter par projet et nom de certificateur.

  6. Saisissez PROJECT_ID dans le champ Nom du projet.

  7. Saisissez test-attestor dans le champ Nom du certificateur.

  8. Cliquez sur Add 1 Attestor (Ajouter un certificateur).

  9. Cliquez sur Save Policy (Enregistrer la stratégie).

Pour en savoir plus, consultez la page Configurer une stratégie à l'aide de la console.

Tester la stratégie

Vous pouvez tester la stratégie que vous avez configurée ci-dessus en essayant de déployer un exemple d'image de conteneur sur le cluster. La stratégie va bloquer le déploiement, car l'attestation requise n'a pas été réalisée.

Pour ce tutoriel, vous pouvez utiliser des exemples d'images de Container Registry et d'Artifact Registry. L'image de Container Registry se trouve dans le chemin gcr.io/google-samples/hello-app:1.0. L'image d'Artifact Registry se trouve dans le chemin us-docker.pkg.dev/google-samples/containers/gke/hello-app:1.0. Les deux chemins d'accès contiennent une image publique créée par Google et contenant un exemple d'application "Hello, World!".

Pour essayer de déployer l'image, exécutez la commande suivante :

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

Maintenant, vérifiez que le déploiement a été bloqué par l'autorisation binaire.

kubectl get pods

La commande affiche le message suivant, qui indique que l'image n'a pas été déployée :

No resources found.

Vous pouvez obtenir plus de détails sur le déploiement avec la commande suivante :

kubectl get event --template \
'{{range.items}}{{"\033[0;36m"}}{{.reason}}:{{"\033[0m"}}\{{.message}}{{"\n"}}{{end}}'

Une réponse semblable à celle-ci s'affiche :

FailedCreate: Error creating: pods POD_NAME is forbidden: admission webhook "imagepolicywebhook.image-policy.k8s.io" denied the request: Image IMAGE_NAME denied by Binary Authorization default admission rule. Image IMAGE_NAME denied by ATTESTOR_NAME: No attestations found

Dans ce résultat :

  • POD_NAME : nom du pod.
  • IMAGE_NAME : nom de l'image.
  • ATTESTOR_NAME : nom du certificateur.

Veillez à supprimer le déploiement pour pouvoir passer à l'étape suivante :

kubectl delete deployment hello-server

Créez un certificat

Une attestation est un document numérique créé par un signataire certifiant que GKE est autorisé à déployer l'image de conteneur associée. Le processus de création d'une attestation est parfois appelé "signature d'une image".

Dans ce tutoriel, vous allez créer une attestation pour des exemples d'images provenant de Container Registry et d'Artifact Registry.

Pour créer une attestation, procédez comme suit :

  1. Définissez les variables qui stockent le chemin d'accès au registre et le condensé de l'image, ainsi que le nom du certificateur :

    Container Registry 

    IMAGE_PATH="gcr.io/google-samples/hello-app"
IMAGE_DIGEST="sha256:c62ead5b8c15c231f9e786250b07909daf6c266d0fcddd93fea882eb722c3be4"
ATTESTOR="test-attestor"
IMAGE_TO_ATTEST=${IMAGE_PATH}@${IMAGE_DIGEST}

    Artifact Registry 

    IMAGE_PATH="us-docker.pkg.dev/google-samples/containers/gke/hello-app"
IMAGE_DIGEST="sha256:37e5287945774f27b418ce567cd77f4bbc9ef44a1bcd1a2312369f31f9cce567"
ATTESTOR="test-attestor"
IMAGE_TO_ATTEST=${IMAGE_PATH}@${IMAGE_DIGEST}

  2. Générez la charge utile de l'attestation :

    Container Registry 

    gcloud container binauthz create-signature-payload \
--artifact-url=${IMAGE_PATH}@${IMAGE_DIGEST} > /tmp/generated_payload.json

    Le contenu du fichier JSON de charge utile obtenu est le suivant :

    {
"critical": {
  "identity": {
    "docker-reference": "gcr.io/google-samples/hello-app"
  },
  "image": {
    "docker-manifest-digest": "sha256:c62ead5b8c15c231f9e786250b07909daf6c266d0fcddd93fea
882eb722c3be4"
  },
  "type": "Google cloud binauthz container signature"
}
}

    Artifact Registry 

    gcloud container binauthz create-signature-payload \
--artifact-url=${IMAGE_PATH}@${IMAGE_DIGEST} > /tmp/generated_payload.json

    Le contenu du fichier JSON de charge utile obtenu est le suivant :

    {
"critical": {
  "identity": {
    "docker-reference": "us-docker.pkg.dev/google-samples/containers/gke/hello-app"
  },
  "image": {
    "docker-manifest-digest": "sha256:37e5287945774f27b418ce567cd77f4bbc9ef44a1bcd1a2312369f31f9cce567"
  },
  "type": "Google cloud binauthz container signature"
}
}

  3. Signez le fichier de charge utile à l'aide de votre clé privée PKIX et générez un fichier de signature :

    openssl dgst -sha256 -sign ${PRIVATE_KEY_FILE} /tmp/generated_payload.json > /tmp/ec_signature

    Le fichier de signature est une version signée numériquement du fichier JSON de charge utile que vous avez créé ci-dessus.

  4. Créez et validez l'attestation :

    gcloud container binauthz attestations create \
    --project="${PROJECT_ID}" \
    --artifact-url="${IMAGE_TO_ATTEST}" \
    --attestor="projects/${PROJECT_ID}/attestors/${ATTESTOR_NAME}" \
    --signature-file=/tmp/ec_signature \
    --public-key-id="${PUBLIC_KEY_ID}" \
    --validate

    Où PUBLIC_KEY_ID correspond à l'ID de clé publique que vous avez déterminé à la section Générer une paire de clés PKIX ci-dessus.

    L'option validate vérifie que l'attestation peut être validée par le certificateur que vous avez configuré dans votre stratégie.

  5. Vérifiez que l'attestation a bien été créée :

    gcloud container binauthz attestations list \
    --attestor=$ATTESTOR_NAME --attestor-project=$PROJECT_ID

Pour en savoir plus sur la création d'attestations, consultez la page Créer des attestations.

Tester une nouvelle fois la stratégie

Testez une nouvelle fois la stratégie en déployant un exemple d'image de conteneur sur le cluster. Cette fois, vous devez déployer l'image à l'aide du condensé au lieu d'un tag tel que 1.0 ou latest, car l'autorisation binaire utilise le condensé pour rechercher les attestations. Ici, l'autorisation binaire permet le déploiement de l'image, car l'attestation requise a été réalisée.

Pour déployer le cluster, exécutez la commande suivante :

kubectl run hello-server --image ${IMAGE_PATH}@${IMAGE_DIGEST} --port 8080

Pour vérifier que l'image a été déployée, exécutez la commande suivante :

kubectl get pods

La commande imprime un message semblable à celui ci-dessous, indiquant que le déploiement a bien été effectué :

NAME                            READY     STATUS    RESTARTS   AGE
hello-server-579859fb5b-h2k8s   1/1       Running   0          1m

Exécutez la commande suivante pour supprimer le pod :

kubectl delete pod hello-server

Effectuer un nettoyage

Pour éviter que les ressources utilisées lors de ce tutoriel soient facturées sur votre compte Google Cloud, supprimez le projet contenant les ressources, ou conservez le projet et supprimez les ressources individuelles.

Supprimez le cluster que vous avez créé dans GKE :

gcloud container clusters delete \
    --zone=us-central1-a \
    test-cluster

Étape suivante