Contrôler les déploiements avec l'authentification binaire

1. Introduction

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 d'attestation par l'autorisation binaire avec Cloud Build. **Figure 1.**Pipeline Cloud Build qui crée une attestation d'autorisation binaire.

Dans ce pipeline :

Le code permettant de créer l'image de conteneur est transféré vers un dépôt source, tel que Cloud Source Repositories.
Un outil d'intégration continue (CI), tel que Cloud Build, compile et teste le conteneur.
La compilation envoie l'image du conteneur à Container Registry ou à un autre registre qui stocke les images compilées.
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.
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 vous concentrer sur 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

2. Préparation

Configuration de l'environnement d'auto-formation

Connectez-vous à la console Google Cloud, puis créez un projet ou réutilisez un projet existant. (Si vous ne possédez pas encore de compte Gmail ou Google Workspace, vous devez en créer un.)

Le nom du projet est le nom à afficher pour les participants au projet. Il s'agit d'une chaîne de caractères non utilisée par les API Google. Vous pouvez le modifier à tout moment.
L'ID du projet est unique parmi tous les projets Google Cloud et non modifiable une fois défini. La console Cloud génère automatiquement une chaîne unique (en général, vous n'y accordez d'importance particulière). Dans la plupart des ateliers de programmation, vous devrez indiquer l'ID du projet (généralement identifié par PROJECT_ID). Si l'ID généré ne vous convient pas, vous pouvez en générer un autre de manière aléatoire. Vous pouvez également en spécifier un et voir s'il est disponible. Après cette étape, l'ID n'est plus modifiable et restera donc le même pour toute la durée du projet.
Pour information, il existe une troisième valeur (le numéro de projet) que certaines API utilisent. Pour en savoir plus sur ces trois valeurs, consultez la documentation.

Vous devez ensuite activer la facturation dans la console Cloud pour utiliser les ressources/API Cloud. L'exécution de cet atelier de programmation est très peu coûteuse, voire sans frais. Pour désactiver les ressources et éviter ainsi que des frais ne vous soient facturés après ce tutoriel, vous pouvez supprimer le projet ou les ressources que vous avez créées. Les nouveaux utilisateurs de Google Cloud peuvent participer au programme d'essai sans frais pour bénéficier d'un crédit de 300$.

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_ID.

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

Créer un dépôt Artifact Registry

Dans cet atelier, vous allez utiliser Artifact Registry pour stocker et analyser vos images. Créez le dépôt à l'aide de la commande suivante.

gcloud artifacts repositories create artifact-scanning-repo \
  --repository-format=docker \
  --location=us-central1 \
  --description="Docker repository"

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

gcloud auth configure-docker us-central1-docker.pkg.dev

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

mkdir vuln-scan && cd vuln-scan

Définir un exemple d'image

Créez un fichier nommé Dockerfile avec le contenu suivant.

cat > ./Dockerfile << EOF
from python:3.8-slim  

# App
WORKDIR /app
COPY . ./

RUN pip3 install Flask==2.1.0
RUN pip3 install gunicorn==20.1.0

CMD exec gunicorn --bind :\$PORT --workers 1 --threads 8 main:app

EOF

Créez un fichier nommé main.py avec le contenu suivant :

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

Créer et transférer l'image vers AR

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

gcloud builds submit . -t us-central1-docker.pkg.dev/${PROJECT_ID}/artifact-scanning-repo/sample-image

3. Signature d'image

Qu'est-ce qu'un certificateur ?

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 (GCP) 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.

Créer une note

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

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}"

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.

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 :

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}

Valider le certificateur

gcloud container binauthz attestors list

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

Notez également que 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.

Ajouter un rôle IAM

Le compte de service d'autorisation binaire devra disposer des droits nécessaires pour afficher les notes d'attestation. Fournissez l'accès 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

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"

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).

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

Créer un trousseau pour stocker un ensemble de clés

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

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 Google Cloud.

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}"

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

gcloud container binauthz attestors list

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. Pour spécifier l'image de conteneur à attester, vous devez déterminer son condensé.

CONTAINER_PATH=us-central1-docker.pkg.dev/${PROJECT_ID}/artifact-scanning-repo/sample-image

DIGEST=$(gcloud container images describe ${CONTAINER_PATH}:latest \
    --format='get(image_summary.digest)')

Vous pouvez désormais vous servir de gcloud pour créer votre attestation. La commande prend simplement 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. Pour vous assurer que tout a fonctionné comme prévu, vous pouvez lister vos attestations.

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

4. 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.

Créer le cluster GKE

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

gcloud beta container clusters create binauthz \
    --zone us-central1-a  \
    --binauthz-evaluation-mode=PROJECT_SINGLETON_POLICY_ENFORCE

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.

Examiner la stratégie existante

gcloud container binauthz policy export

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

evaluationMode: ALWAYS_ALLOW

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

Vérifier que le déploiement a fonctionné

kubectl get pods

Le résultat suivant s'affiche :

Supprimer le déploiement

kubectl delete pod hello-server

Stratégie "Tout refuser"

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

Exporter la stratégie actuelle dans un fichier modifiable

gcloud container binauthz policy export  > policy.yaml

Modifier les règles

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

edit policy.yaml

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

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.

Ouvrez le terminal, appliquez la nouvelle règle et attendez quelques secondes que la modification soit appliquée.

gcloud container binauthz policy import policy.yaml

Essayer de déployer un exemple de charge de travail

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

Le déploiement échoue avec le message suivant :

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, veillez à annuler les modifications apportées à la stratégie.

Modifier les règles

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

edit policy.yaml

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

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

Appliquer la stratégie rétablie

gcloud container binauthz policy import policy.yaml

5. Signature des images numérisées

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

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

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

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

À cette étape, vous allez ajouter l'étape d'attestation à votre pipeline Cloud Build.

Consultez l'étape de signature ci-dessous.

Pour examen uniquement. Ne pas copier

#Sign the image only if the previous severity check passes
- id: 'create-attestation'
  name: 'gcr.io/${PROJECT_ID}/binauthz-attestation:latest'
  args:
    - '--artifact-url'
    - 'us-central1-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'

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

cat > ./cloudbuild.yaml << EOF
steps:

# build
- id: "build"
  name: 'gcr.io/cloud-builders/docker'
  args: ['build', '-t', 'us-central1-docker.pkg.dev/${PROJECT_ID}/artifact-scanning-repo/sample-image', '.']
  waitFor: ['-']

#Run a vulnerability scan at _SECURITY level
- id: scan
  name: 'gcr.io/cloud-builders/gcloud'
  entrypoint: 'bash'
  args:
  - '-c'
  - |
    (gcloud artifacts docker images scan \
    us-central1-docker.pkg.dev/${PROJECT_ID}/artifact-scanning-repo/sample-image \
    --location us \
    --format="value(response.scan)") > /workspace/scan_id.txt

#Analyze the result of the scan
- id: severity check
  name: 'gcr.io/cloud-builders/gcloud'
  entrypoint: 'bash'
  args:
  - '-c'
  - |
      gcloud artifacts docker images list-vulnerabilities \$(cat /workspace/scan_id.txt) \
      --format="value(vulnerability.effectiveSeverity)" | if grep -Fxq CRITICAL; \
      then echo "Failed vulnerability check for CRITICAL level" && exit 1; else echo "No CRITICAL vulnerability found, congrats !" && exit 0; fi

#Retag
- id: "retag"
  name: 'gcr.io/cloud-builders/docker'
  args: ['tag',  'us-central1-docker.pkg.dev/${PROJECT_ID}/artifact-scanning-repo/sample-image', 'us-central1-docker.pkg.dev/${PROJECT_ID}/artifact-scanning-repo/sample-image:good']


#pushing to artifact registry
- id: "push"
  name: 'gcr.io/cloud-builders/docker'
  args: ['push',  'us-central1-docker.pkg.dev/${PROJECT_ID}/artifact-scanning-repo/sample-image:good']


#Sign the image only if the previous severity check passes
- id: 'create-attestation'
  name: 'gcr.io/${PROJECT_ID}/binauthz-attestation:latest'
  args:
    - '--artifact-url'
    - 'us-central1-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:
  - us-central1-docker.pkg.dev/${PROJECT_ID}/artifact-scanning-repo/sample-image:good
EOF

Exécuter le build

gcloud builds submit

Examiner la compilation dans l'historique Cloud Build

Ouvrez la page Historique Cloud Build dans la console Cloud. Ensuite, vérifiez la dernière compilation et la bonne exécution des étapes de compilation.

6. Autorisation des images signées

Dans cette section, vous allez 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.

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

COMPUTE_ZONE=us-central1-a

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

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.

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

gcloud beta container binauthz policy import binauth_policy.yaml

Déployer une image signée

Récupérez le condensé pour la bonne image

CONTAINER_PATH=us-central1-docker.pkg.dev/${PROJECT_ID}/artifact-scanning-repo/sample-image


DIGEST=$(gcloud container images describe ${CONTAINER_PATH}:good \
    --format='get(image_summary.digest)')

Utiliser 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

Déployer l'application sur GKE

kubectl apply -f deploy.yaml

Examinez la charge de travail dans la console et notez que l'image a bien été déployée.

7. Images non signées bloquées

Créer une image

Dans cette étape, vous allez utiliser Docker en local pour créer l'image dans votre cache local.

docker build -t us-central1-docker.pkg.dev/${PROJECT_ID}/artifact-scanning-repo/sample-image:bad .

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

docker push us-central1-docker.pkg.dev/${PROJECT_ID}/artifact-scanning-repo/sample-image:bad

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

CONTAINER_PATH=us-central1-docker.pkg.dev/${PROJECT_ID}/artifact-scanning-repo/sample-image


DIGEST=$(gcloud container images describe ${CONTAINER_PATH}:bad \
    --format='get(image_summary.digest)')

Utiliser 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

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

8. Félicitations !

Félicitations, vous avez terminé cet atelier de programmation.

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

Étapes suivantes :

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 chaque ressource individuellement.

Supprimer le projet

Le moyen le plus simple d'empêcher la facturation est de supprimer le projet que vous avez créé pour ce tutoriel.

—

Dernière mise à jour : 21/03/2023