Paramétrer une configuration multiprojet

Ce tutoriel explique comment utiliser l'autorisation binaire dans une configuration multiprojets. Pour simplifier la configuration d'un projet unique, consultez la page Premiers pas avec Google Cloud CLI (GKE).

Pour établir la séparation des tâches, vous pouvez configurer l'autorisation binaire dans une configuration comportant plusieurs projets. L'objectif de chaque projet est abordé plus loin dans ce tutoriel.

Objectifs

Dans ce tutoriel, vous allez réaliser les tâches suivantes :

Configurez un autre projet pour le déploiement (GKE), le certificateur et la gestion des attestations, afin de permettre la séparation des tâches.
Configurez la règle par défaut de votre stratégie d'autorisation binaire pour exiger des attestations.
Créez une paire de clés pour signer et valider ultérieurement l'attestation.
Créez un certificateur utilisé par l'outil d'application de l'autorisation binaire pour valider l'attestation.
Signez un exemple d'image en créant une attestation.
Testez la stratégie en déployant l'exemple d'image.

Vous devez configurer le contrôle d'accès approprié pour chaque projet via la gestion de l'authentification et des accès (IAM).

Pour plus de sécurité, vous pouvez utiliser VPC Service Controls pour protéger les ressources que vous créez dans ce tutoriel. Pour en savoir plus, consultez la page Sécuriser avec VPC Service Controls.

Coûts

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

Artifact Registry ou Container Registry
Autorisation binaire
GKE
Container Registry
Facultatif : Cloud Key Management Service

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

Connectez-vous à votre compte Google Cloud. Si vous débutez sur Google Cloud, créez un compte pour évaluer les performances de nos produits en conditions réelles. Les nouveaux clients bénéficient également de 300 $ de crédits gratuits pour exécuter, tester et déployer des charges de travail.

Dans Google Cloud Console, sur la page de sélection du projet, sélectionnez ou créez un projet Google Cloud.

Accéder au sélecteur de projet

Vérifiez que la facturation est activée pour votre projet Google Cloud.

Installez Google Cloud CLI.

Pour initialiser gcloudCLI, exécutez la commande suivante :

gcloud init

Dans Google Cloud Console, sur la page de sélection du projet, sélectionnez ou créez un projet Google Cloud.

Accéder au sélecteur de projet

Vérifiez que la facturation est activée pour votre projet Google Cloud.

Installez Google Cloud CLI.

Pour initialiser gcloudCLI, exécutez la commande suivante :

gcloud init

Installez kubectl pour interagir avec GKE.

Configurer le projet déployant

Le projet déployant gère les clusters Google Kubernetes Engine (GKE), sur lesquels vous déployez des images, ainsi que la stratégie d'autorisation binaire appliquée par l'autorisation binaire au moment du déploiement. Vous pouvez disposer de plusieurs projets déployant, en fonction de la taille, de la complexité et d'autres exigences de votre environnement.

Pour configurer le projet déployant, procédez comme suit :

Créez le projet et activez la facturation dans Google Cloud Console si vous ne l'avez pas déjà fait.
Remarque concernant la gestion de l'authentification et des accès : Le projet déployant contient votre cluster GKE. La configuration de la gestion de l'authentification et des accès de ce projet doit être établie en fonction.

Définissez les variables d'environnement pour stocker le projet et le numéro Google Cloud :

DEPLOYER_PROJECT_ID=DEPLOYER_PROJECT_ID

Remplacez DEPLOYER_PROJECT_ID par l'ID du projet Google Cloud.

DEPLOYER_PROJECT_NUMBER=$(gcloud projects describe "${DEPLOYER_PROJECT_ID}" \
    --format="value(projectNumber)")

Activez les API :

Container Registry

gcloud --project=${DEPLOYER_PROJECT_ID} \
  services enable\
  container.googleapis.com\
  containerregistry.googleapis.com\
  binaryauthorization.googleapis.com

Artifact Registry

gcloud --project=${DEPLOYER_PROJECT_ID} \
  services enable\
  container.googleapis.com\
  artifactregistry.googleapis.com\
  binaryauthorization.googleapis.com

Obtenez le nom du compte de service du projet déployant :
```
DEPLOYER_SERVICE_ACCOUNT="service-${DEPLOYER_PROJECT_NUMBER}@gcp-sa-binaryauthorization.iam.gserviceaccount.com"
```
Vous utiliserez ce nom ultérieurement lors de la configuration des autorisations sur la note Artifact Analysis associée à votre certificateur.

Configurer le projet certifiant

Un projet certifiant stocke les certificateurs qui peuvent valider le fait qu'une image est prête à être déployée. Souvent, vous disposez d'un seul projet certifiant qui agit comme un magasin centralisé pour obtenir des informations sur les parties de confiance dans le processus d'autorisation. Cela vous permet de gérer de manière centralisée les clés de sécurité requises pour valider l'identité des certificateurs et de limiter l'accès aux seules parties chargées de les administrer.

Pour configurer le projet certifiant, procédez comme suit :

Créez le projet et activez la facturation dans Google Cloud Console si vous ne l'avez pas déjà fait.
Remarque concernant la gestion de l'authentification et des accès : Étant donné que ce projet contient vos certificateurs, seul le personnel de sécurité doit disposer d'un accès en écriture.

Définissez les variables d'environnement pour stocker l'ID et le numéro du projet :

ATTESTOR_PROJECT_ID=ATTESTOR_PROJECT_ID

Remplacez ATTESTOR_PROJECT_ID par l'ID du projet certifiant.

ATTESTOR_PROJECT_NUMBER=$(gcloud projects describe "${ATTESTOR_PROJECT_ID}" \
    --format="value(projectNumber)")

Activez les API Artifact Analysis et d'autorisation binaire :

gcloud services --project=${ATTESTOR_PROJECT_ID} \
    enable containeranalysis.googleapis.com \
    binaryauthorization.googleapis.com

Obtenez le nom du compte de service du projet certifiant :
```
ATTESTOR_SERVICE_ACCOUNT="service-${ATTESTOR_PROJECT_NUMBER}@gcp-sa-binaryauthorization.iam.gserviceaccount.com"
```
Vous utiliserez ce nom ultérieurement lors de la configuration des autorisations sur la note Artifact Analysis associée à votre certificateur.

Configurer le projet d'attestation

Un projet d'attestation est un projet qui stocke les attestations créées par les certificateurs lorsqu'ils valident une image. Un projet d'attestation distinct vous permet d'organiser et d'inspecter plus facilement les déclarations liées à la préparation des logiciels.

Créez le projet et activez la facturation dans Google Cloud Console si vous ne l'avez pas déjà fait.
Remarque sur la gestion de l'authentification et des accès : Tous les rôles concernés par l'autorisation binaire doivent disposer d'un accès en lecture aux notes et occurrences Artifact Analysis de ce projet, mais seuls les gestionnaires d'attestations doivent disposer d'un accès en écriture.
Définissez une variable d'environnement pour stocker le nom du projet :
```
ATTESTATION_PROJECT_ID=ATTESTATION_PROJECT_ID
```
Remplacez ATTESTATION_PROJECT_ID par l'ID du projet d'attestation.

Activez les API Artifact Analysis et d'autorisation binaire :

gcloud services --project=${ATTESTATION_PROJECT_ID} \
    enable containeranalysis.googleapis.com \
    binaryauthorization.googleapis.com

Créer un cluster

Vous pouvez maintenant créer un cluster GKE dans le projet déployant. Il s'agit du cluster dans lequel vous souhaitez exécuter les images de conteneur que vous déployez. Lorsque vous créez le cluster, vous transmettez l'option --binauthz-evaluation-mode=PROJECT_SINGLETON_POLICY_ENFORCE à la commande gcloud container clusters create.

Pour créer le cluster :

gcloud --project=${DEPLOYER_PROJECT_ID} \
    container clusters create \
    --binauthz-evaluation-mode=PROJECT_SINGLETON_POLICY_ENFORCE \
    --zone us-central1-a \
    test-cluster

Dans cet exemple, vous créez un cluster nommé test-cluster dans la zone GKE us-central1-a.

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 --project=${DEPLOYER_PROJECT_ID} \
    container clusters get-credentials \
    --zone us-central1-a \
    test-cluster

Créer un certificateur

Un certificateur est une partie chargée d'attester qu'un processus requis est terminé avant le déploiement d'une image de conteneur. Cette partie peut être un utilisateur humain ou, plus souvent, un processus machine tel qu'un système de compilation et de test, ou vos pipelines d'intégration continue (CI) et de déploiement continu (CD). Vous créez des certificateurs dans votre projet certifiant.

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

Créer une note dans Artifact Analysis pour stocker les métadonnées de confiance utilisées dans le processus d'autorisation.
Créer le certificateur proprement dit dans le projet certifiant et associer la note que vous avez créée.
Ajouter une liaison de rôle IAM avec le certificateur pour le compte de service du projet déployant.
Définir des autorisations sur la note Artifact Analysis

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

Créer la note Artifact Analysis

Définissez des variables qui stockent le nom de votre certificateur et la note Artifact Analysis :
```
ATTESTOR_NAME=test-attestor
NOTE_ID=test-attestor-note
```
Remplacez :
- test-attestor : nom du certificateur de votre choix.
- test-attestor-note : nom de la note de certificateur de votre choix.

Créez un fichier JSON décrivant la note Container Analysis dans /tmp/note_payload.json :

cat > /tmp/note_payload.json << EOM
{
  "name": "projects/${ATTESTOR_PROJECT_ID}/notes/${NOTE_ID}",
  "attestation": {
    "hint": {
      "human_readable_name": "Attestor Note"
    }
  }
}
EOM

Créez la note en envoyant une requête HTTP à l'API REST Artifact Analysis :

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

Vérifiez que la note a bien été créée :

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

Créer le certificateur

Vous pouvez maintenant créer le certificateur.

Créez le certificateur dans l'autorisation binaire :

gcloud --project=${ATTESTOR_PROJECT_ID} \
    container binauthz attestors create ${ATTESTOR_NAME} \
    --attestation-authority-note=${NOTE_ID} \
    --attestation-authority-note-project=${ATTESTOR_PROJECT_ID}

Vérifiez que le certificateur a bien été créé :

gcloud --project=${ATTESTOR_PROJECT_ID} \
    container binauthz attestors list

Le certificateur que vous avez créé n'est pas utilisable sans paire de clés PKIX associée. Vous allez la créer ci-dessous.

Ajouter une liaison de rôle IAM pour le projet déployant

Vous devez ajouter une liaison de rôle IAM avec le certificateur pour le projet déployant. Celle-ci est utilisée par l'autorisation binaire lorsqu'elle évalue une stratégie pour déterminer si le projet est autorisé à accéder aux attestations associées.

Pour ajouter la liaison de rôle IAM, procédez comme suit :

gcloud --project ${ATTESTOR_PROJECT_ID} \
    container binauthz attestors add-iam-policy-binding \
    "projects/${ATTESTOR_PROJECT_ID}/attestors/${ATTESTOR_NAME}" \
    --member="serviceAccount:${DEPLOYER_SERVICE_ACCOUNT}" \
    --role=roles/binaryauthorization.attestorsVerifier

Définir des autorisations sur la note Artifact Analysis

Vous devez également définir des autorisations sur la note Artifact Analysis que vous avez créée afin qu'elle soit accessible à la fois au projet déployant et au projet certifiant. Pour ce faire, mettez à jour la stratégie IAM associée à la note afin d'accorder un accès en lecture aux comptes de service des projets.

Générez un fichier JSON contenant les informations nécessaires pour définir la stratégie IAM sur votre note.

cat > /tmp/iam_request.json << EOM
{
  'resource': 'projects/${ATTESTOR_PROJECT_ID}/notes/${NOTE_ID}',
  'policy': {
    'bindings': [
      {
        'role': 'roles/containeranalysis.notes.occurrences.viewer',
        'members': [
          'serviceAccount:${ATTESTOR_SERVICE_ACCOUNT}',
          'serviceAccount:${DEPLOYER_SERVICE_ACCOUNT}'
        ]
      }
    ]
  }
}
EOM

Ajoutez le compte de service et les rôles d'accès requis à la stratégie IAM pour la note que vous avez créée :

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

Configurer des clés PKIX

L'autorisation binaire utilise des clés cryptographiques pour vérifier de manière sécurisée l'identité des certificateurs. Ainsi, seules les parties validées peuvent participer à l'autorisation d'une image de conteneur. La paire de clés se compose d'une clé privée, utilisée par le certificateur pour signer numériquement les attestations, et d'une clé publique que vous ajoutez au certificateur telle qu'elle est stockée par le service d'autorisation binaire.

Dans ce tutoriel, vous allez utiliser l'algorithme de signature numérique à courbe elliptique (ECDSA) recommandé pour créer la paire de clés. 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 asymétriques 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.

Générer une paire de clés

Une paire de clés PKIX consiste en une clé privée, que le signataire utilise pour signer numériquement des attestations, et une clé publique que vous ajoutez au certificateur. Au moment du déploiement, l'autorisation binaire utilise cette clé publique pour vérifier l'attestation signée par la clé privée.

Générez la clé privée :

Pour générer une paire de clés PKIX asymétrique locale et la stocker dans un fichier, procédez comme suit :
PKIX (Cloud KMS)
Cette étape montre comment effectuer une attestation à l'aide de clés générées et stockées dans Cloud Key Management Service.
1. Configurez des variables d'environnement pour stocker les informations sur la paire de clés gérée par Cloud KMS :
  
  Si vous possédez déjà une paire de clés, vous pouvez définir ces variables d'environnement et ignorer l'étape suivante.
```
KMS_KEY_PROJECT_ID=KMS_KEY_PROJECT_ID
KMS_KEY_LOCATION=KMS_KEY_LOCATION
KMS_KEYRING_NAME=KMS_KEYRING_NAME
KMS_KEY_NAME=KMS_KEY_NAME
KMS_KEY_VERSION=KMS_KEY_VERSION
```
  Remplacez les éléments suivants :
  - KMS_KEY_PROJECT_ID : ID du projet dans lequel les clés sont stockées
  - KMS_KEY_LOCATION : emplacement de la clé
  - KMS_KEYRING_NAME : nom du trousseau de clés
  - KMS_KEY_NAME : nom de la clé
  - KMS_KEY_VERSION : version de la clé
2. [Facultatif] Configurez une clé KMS :
  Remarque : Vous pouvez ignorer ces étapes si vous possédez déjà une clé KMS.
  1. Créez une clé KMS dont la clé publique peut être stockée dans un certificateur. Cette étape permet également de configurer les variables d'environnement que vous utilisez ci-dessous.
    
    Pour créer une clé et configurer les variables d'environnement, exécutez la commande suivante :
    
    KMS_KEY_PROJECT_ID=${PROJECT_ID} KMS_KEYRING_NAME=my-binauthz-keyring KMS_KEY_NAME=my-binauthz-kms-key-name KMS_KEY_LOCATION=global KMS_KEY_PURPOSE=asymmetric-signing KMS_KEY_ALGORITHM=ec-sign-p256-sha256 KMS_PROTECTION_LEVEL=software KMS_KEY_VERSION=1
  2. Créez un trousseau de clés KMS :
    
    gcloud kms keyrings create ${KMS_KEYRING_NAME} \ --location ${KMS_KEY_LOCATION} \ --project ${KMS_KEY_PROJECT_ID}
  3. Créez la clé :
    
    gcloud kms keys create ${KMS_KEY_NAME} \ --location ${KMS_KEY_LOCATION} \ --keyring ${KMS_KEYRING_NAME} \ --purpose ${KMS_KEY_PURPOSE} \ --default-algorithm ${KMS_KEY_ALGORITHM} \ --protection-level ${KMS_PROTECTION_LEVEL} \ --project ${KMS_KEY_PROJECT_ID}
    
    Pour en savoir plus sur la création de clés KMS, consultez la page Créer une clé asymétrique.
3. Ajoutez la clé publique au certificateur :
```
gcloud --project="${ATTESTOR_PROJECT_ID}" \
    container binauthz attestors public-keys add \
    --attestor="${ATTESTOR_NAME}" \
    --keyversion-project="${KMS_KEY_PROJECT_ID}" \
    --keyversion-location="${KMS_KEY_LOCATION}" \
    --keyversion-keyring="${KMS_KEYRING_NAME}" \
    --keyversion-key="${KMS_KEY_NAME}" \
    --keyversion="${KMS_KEY_VERSION}"
```
PKIX (clé locale)

Avertissement : Nous vous déconseillons vivement d'utiliser des paires de clés générées localement dans des environnements de production, car elles présentent un risque de sécurité. Nous vous recommandons plutôt d'utiliser Cloud Key Management Service. Cet exemple n'est fourni qu'à titre indicatif.
1. Pour générer la clé privée, exécutez les commandes suivantes :
```
PRIVATE_KEY_FILE="/tmp/ec_private.pem"
openssl ecparam -genkey -name prime256v1 -noout -out ${PRIVATE_KEY_FILE}
```
  PRIVATE_KEY_FILE est le nom du fichier contenant la clé privée stockée dans le certificateur.
2. Extrayez la clé publique de la clé privée et stockez-la dans un fichier :
```
PUBLIC_KEY_FILE="/tmp/ec_public.pem"
openssl ec -in ${PRIVATE_KEY_FILE} -pubout -out ${PUBLIC_KEY_FILE}
```
  PUBLIC_KEY_FILE est le nom du fichier contenant la clé publique stockée dans le certificateur.
3. Pour ajouter la clé publique que vous avez exportée au certificateur, exécutez le code suivant.
```
gcloud --project="${ATTESTOR_PROJECT_ID}" \
  container binauthz attestors public-keys add \
  --attestor="${ATTESTOR_NAME}" \
  --pkix-public-key-file=${PUBLIC_KEY_FILE} \
  --pkix-public-key-algorithm=ecdsa-p256-sha256
```
  L'autorisation binaire utilise la clé publique du certificateur pour valider l'attestation.

Configurer la stratégie

Vous pouvez maintenant configurer votre stratégie dans le projet déployant. Au cours de cette étape, vous exportez le fichier YAML de stratégie vers votre système local et modifiez la règle par défaut de sorte qu'elle nécessite une attestation de la part du certificateur que vous avez défini ci-dessus.

Pour configurer la stratégie, procédez comme suit :

Créez un fichier de stratégie qui autorise les images système gérées par Google, définit evaluationMode sur REQUIRE_ATTESTATION et ajoute un nœud nommé requireAttestationsBy qui référence le certificateur que vous avez créé :

cat > /tmp/policy.yaml << EOM
    globalPolicyEvaluationMode: ENABLE
    defaultAdmissionRule:
      evaluationMode: REQUIRE_ATTESTATION
      enforcementMode: ENFORCED_BLOCK_AND_AUDIT_LOG
      requireAttestationsBy:
        - projects/${ATTESTOR_PROJECT_ID}/attestors/${ATTESTOR_NAME}
    name: projects/${DEPLOYER_PROJECT_ID}/policy
EOM

Importez le fichier YAML de stratégie dans l'autorisation binaire :

gcloud --project=${DEPLOYER_PROJECT_ID} \
    container binauthz policy import /tmp/policy.yaml

Pour plus d'informations sur la configuration des stratégies, consultez la page Configurer une stratégie à l'aide de la CLI.

Tester la stratégie

Dans ce tutoriel, vous allez créer une attestation, par exemple des images publiques "Hello World!" à partir de Container Registry et Artifact Registry. Au départ, l'outil d'application bloque le déploiement des images, car l'attestation requise n'existe pas.

Essayez de déployer l'image :

Container Registry

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

Artifact Registry

kubectl run hello-server --image us-docker.pkg.dev/google-samples/containers/gke/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 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 une déclaration émise par un certificateur qui indique qu'un processus requis dans votre pipeline est terminé et que l'image de conteneur en question est autorisée pour le déploiement. L'attestation elle-même est un enregistrement signé numériquement qui contient le chemin d'accès complet à une version de l'image stockée dans votre registre d'images de conteneurs, ainsi que l'identité du certificateur.

Dans ce tutoriel, votre attestation indique simplement que vous autorisez l'image en vue du déploiement. Vous créez l'attestation dans le projet d'attestation.

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

Définissez les variables qui stockent le chemin d'accès au registre et le condensé de l'image :

Container Registry

IMAGE_PATH="gcr.io/google-samples/hello-app"
IMAGE_DIGEST="sha256:c62ead5b8c15c231f9e786250b07909daf6c266d0fcddd93fea882eb722c3be4"

Artifact Registry

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

Créer l'attestation

PKIX Cloud KMS

Pour créer l'attestation à l'aide de la clé Cloud KMS, exécutez la commande suivante :

gcloud beta container binauthz attestations sign-and-create \
    --project="${PROJECT_ID}" \
    --artifact-url="${IMAGE_TO_ATTEST}" \
    --attestor="${ATTESTOR_NAME}" \
    --attestor-project="${PROJECT_ID}" \
    --keyversion-project="${KMS_KEY_PROJECT_ID}" \
    --keyversion-location="${KMS_KEY_LOCATION}" \
    --keyversion-keyring="${KMS_KEYRING_NAME}" \
    --keyversion-key="${KMS_KEY_NAME}" \
    --keyversion="${KMS_KEY_VERSION}"

PKIX (clé locale)

Pour créer l'attestation à l'aide d'une clé locale, procédez comme suit :

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

gcloud --project=${ATTESTATION_PROJECT_ID} \
  container binauthz create-signature-payload \
  --artifact-url=${IMAGE_TO_ATTEST} > /tmp/generated_payload.json

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

Container Registry

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

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

Signez la charge utile.

Si vous utilisez des fichiers PKIX locaux, signez la charge utile avec votre clé privée PKIX locale 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 sortie est une version signée du fichier JSON de charge utile que vous avez créé ci-dessus.
Obtenez l'ID de clé publique auprès du certificateur.

Vous pouvez afficher l'ID de votre clé publique à tout moment à l'aide de la commande gcloud container binauthz attestors describe ATTESTOR_NAME.

Pour enregistrer votre ID de clé publique dans une variable d'environnement, saisissez la commande suivante :
```
PUBLIC_KEY_ID=$(gcloud container binauthz attestors describe ${ATTESTOR_NAME} \
--format='value(userOwnedGrafeasNote.publicKeys[0].id)' --project ${ATTESTOR_PROJECT_ID})
```

Créez et validez l'attestation :

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

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

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

gcloud --project=${ATTESTATION_PROJECT_ID} \
    container binauthz attestations list \
    --attestor=$ATTESTOR_NAME --attestor-project=$ATTESTOR_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 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 à la fois le chemin d'accès de l'image et le condensé afin de rechercher les attestations. Ici, l'autorisation binaire permet le déploiement de l'image, car elle est associée à une attestation.

Pour déployer l'image :

kubectl run hello-server --image ${IMAGE_TO_ATTEST} --port 8080

Pour vérifier que l'image a été déployée :

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

Maintenant que vous avez déployé l'image de conteneur et vérifié que votre configuration fonctionne, vous pouvez supprimer le cluster que vous avez créé dans GKE :

gcloud --project=${DEPLOYER_PROJECT_ID} \
    container clusters delete \
    --zone=us-central1-a \
    test-cluster

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

Vous pouvez également supprimer les projets Google Cloud que vous avez créés pour ce tutoriel.

Étape suivante

Obtenez davantage d'informations sur l'autorisation binaire.
Découvrez les concepts clés utilisés dans l'autorisation binaire.
Activez le mode de simulation pour modifier le mode d'application d'une stratégie.
Utilisez le mode "bris de glace" pour contourner l'application.

Paramétrer une configuration multiprojet

Objectifs

Coûts

Avant de commencer

Configurer le projet déployant

Container Registry

Artifact Registry

Configurer le projet certifiant

Configurer le projet d'attestation

Créer un cluster

Créer un certificateur

Créer la note Artifact Analysis

Créer le certificateur

Ajouter une liaison de rôle IAM pour le projet déployant

Définir des autorisations sur la note Artifact Analysis

Configurer des clés PKIX

Générer une paire de clés

PKIX (Cloud KMS)

PKIX (clé locale)

Configurer la stratégie

Tester la stratégie

Container Registry

Artifact Registry

Créez un certificat

Container Registry

Artifact Registry

PKIX Cloud KMS

PKIX (clé locale)

Container Registry

Artifact Registry

Tester une nouvelle fois la stratégie

Effectuer un nettoyage

Étape suivante