Créer des certificateurs à l'aide de l'outil gcloud

Cette page explique comment créer un certificateur dans l'autorisation binaire à l'aide de l'outil de ligne de commande gcloud. Vous pouvez également effectuer ces étapes à l'aide de Google Cloud Console ou de l'API REST. Cette tâche fait partie de la configuration de l'autorisation binaire.

Un certificateur est une ressource Google Cloud utilisée par l'autorisation binaire pour valider une attestation. Pour en savoir plus sur les attestations, consultez la page Présentation de l'autorisation binaire.

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

  • Créer une note dans Container Analysis pour stocker les métadonnées de confiance utilisées dans le processus d'autorisation.
  • Configurer une paire de clés PKIX pouvant être utilisées pour vérifier l'identité du certificateur. (Les paires de clés asymétriques générées par Cloud Key Management Service (Cloud KMS) sont dans un format compatible avec PKIX.)
  • Créer le certificateur proprement dit dans l'autorisation binaire, puis lui associer la note et la clé publique que vous avez créées.

Dans une configuration à un seul projet, vous créez votre certificateur dans le projet Google Cloud au sein duquel vous configurez votre stratégie d'autorisation binaire. Dans une configuration multiprojets, vous avez probablement un projet déployant hébergeant la configuration de votre stratégie et un projet certifiant distinct hébergeant vos certificateurs.

Configurer l'environnement

Configurez des variables d'environnement pour stocker les noms et les numéros de vos projets :

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

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

Si votre projet certifiant est le même que votre projet déployant, utilisez le même ID de projet pour les deux variables. Pour accéder à un tutoriel de bout en bout décrivant la séparation des tâches à l'aide de plusieurs projets, consultez la section Configuration multiprojet.

Vous devez également obtenir les noms des comptes de service associés à ces projets :

DEPLOYER_SERVICE_ACCOUNT="service-${DEPLOYER_PROJECT_NUMBER}@gcp-sa-binaryauthorization.iam.gserviceaccount.com"
ATTESTOR_SERVICE_ACCOUNT="service-${ATTESTOR_PROJECT_NUMBER}@gcp-sa-binaryauthorization.iam.gserviceaccount.com"

Créer une note Container Analysis

L'autorisation binaire utilise Container Analysis pour stocker les métadonnées de confiance utilisées dans le processus d'autorisation. Pour chaque certificateur que vous créez, vous devez créer une note Container Analysis. Chaque attestation est stockée en tant qu'occurrence de cette note.

Pour créer une note Container Analysis, procédez comme suit :

  1. Configurez des variables d'environnement pour stocker l'ID de note et une description lisible :

    NOTE_ID=NOTE_ID
    NOTE_URI="projects/${ATTESTOR_PROJECT_ID}/notes/${NOTE_ID}"
    DESCRIPTION=DESCRIPTION
    

    Remplacez les éléments suivants :

    • NOTE_ID est le nom interne de la note, composé de caractères alphanumériques sans espace (par exemple, test-attestor-note) ;
    • NOTE_URI est le chemin d'accès complet à la ressource de note ;
    • DESCRIPTION est le nom lisible à afficher pour la note (par exemple, Test Attestor Note).
  2. À l'aide d'un éditeur de texte, créez un fichier JSON décrivant la note Container Analysis dans /tmp/note_payload.json :

    cat > /tmp/note_payload.json << EOM
    {
      "name": "${NOTE_URI}",
      "attestation": {
        "hint": {
          "human_readable_name": "${DESCRIPTION}"
        }
      }
    }
    EOM
    
  3. Créez la note en envoyant une requête HTTP à l'API REST Container Analysis :

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

    Pour vérifier que la note a bien été créée, exécutez la commande suivante :

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

Définir des autorisations Identity and Access Management sur la note

Vous devez attribuer un rôle IAM (Identity and Access Management) au compte de service du projet certifiant pour la ressource de note Container Analysis. Pour ce faire, ajoutez le compte de service du projet certifiant au rôle containeranalysis.notes.occurrences.viewer dans la stratégie IAM de la note.

Pour ajouter le rôle, procédez comme suit :

  1. Générez un fichier JSON contenant les informations nécessaires pour définir le rôle IAM sur votre note :

    cat > /tmp/iam_request.json << EOM
    {
      "resource": "${NOTE_URI}",
      "policy": {
        "bindings": [
          {
            "role": "roles/containeranalysis.notes.occurrences.viewer",
            "members": [
              "serviceAccount:${ATTESTOR_SERVICE_ACCOUNT}"
            ]
          }
        ]
      }
    }
    EOM
    
  2. 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)" \
        -H "x-goog-user-project: ${ATTESTOR_PROJECT_ID}" \
        --data-binary @/tmp/iam_request.json \
        "https://containeranalysis.googleapis.com/v1/projects/${ATTESTOR_PROJECT_ID}/notes/${NOTE_ID}:setIamPolicy"
    

Utilisation multiprojet

Si vous stockez le certificateur dans un projet et que vous le déployez dans un projet distinct, vous devez attribuer le rôle roles/binaryauthorization.attestorsVerifier au compte de service associé au projet déployant sur le certificateur.

Configurer des clés cryptographiques

L'autorisation binaire vous permet d'utiliser des clés PKIX afin de vérifier de manière sécurisée l'identité du signataire ayant créé une attestation. Ainsi, seules les parties validées peuvent autoriser une image de conteneur. Au lieu de clés PKIX, vous pouvez également utiliser des clés PGP.

Générer une paire de clés

Dans ce guide, l'algorithme de signature numérique à courbe elliptique (ECDSA) recommandé est utilisé 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.

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.

Pour générer une paire de clés PKIX asymétrique locale et la stocker dans un fichier, procédez comme suit :

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

    PRIVATE_KEY_FILE correspond au nom du fichier contenant la clé privée utilisée pour signer la charge utile de l'attestation.

    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 et stockez-la dans un fichier :

    PUBLIC_KEY_FILE est le nom du fichier contenant la clé publique, qui sera stockée dans le certificateur.

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

Les paires de clés asymétriques générées et stockées dans Cloud KMS sont compatibles avec le format PKIX. Pour créer une clé Cloud KMS à utiliser avec l'autorisation binaire, consultez la page Créer des clés asymétriques. Veillez à choisir l'option Signature asymétrique comme objectif de clé lors de la création de celle-ci.

Créer le certificateur

L'étape suivante consiste à créer le certificateur proprement dit dans l'autorisation binaire avec la note Container Analysis associée. Vous devez également ajouter la clé cryptographique publique.

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

  1. Configurez une variable d'environnement pour stocker le nom du certificateur, tel que défini dans l'autorisation binaire :

    ATTESTOR_NAME=ATTESTOR_NAME
    

    ATTESTOR_NAME est le nom du certificateur que vous souhaitez créer (par exemple, build-secure ou prod-qa).

  2. Créez la ressource de 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}"
    
  3. Ajoutez 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.

    gcloud container binauthz attestors add-iam-policy-binding \
      "projects/${ATTESTOR_PROJECT_ID}/attestors/${ATTESTOR_NAME}" \
      --member="serviceAccount:${DEPLOYER_SERVICE_ACCOUNT}" \
      --role=roles/binaryauthorization.attestorsVerifier
    
  4. Ajoutez la clé publique au certificateur :

    PKIX (clé locale)

    1. Ajoutez une clé publique PKIX stockée localement à un certificateur :

      Ajoutez maintenant la clé publique que vous avez exportée au certificateur afin qu'elle puisse être utilisée par l'autorisation binaire pour la validation de l'identité :

      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
      

      Remarque : Si vous ajoutez une clé publique à un certificateur sans spécifier d'ID de clé (qui peut être n'importe quelle chaîne), celui-ci est automatiquement attribué au format RFC 6920 : ni:///sha-256;..., où ... est un hachage encodé de la clé publique. Cette valeur est renvoyée dans le champ id du résultat de la commande. L'ID renvoyé peut être enregistré dans PUBLIC_KEY_ID et utilisé pour créer une attestation.

    2. Enregistrez l'ID de la clé publique.

      Lors de la création d'une attestation, vous aurez besoin de l'ID de la clé publique. Pour enregistrer l'ID de la clé publique, vous pouvez utiliser le résultat de la commande binauthz attestors public-keys add ci-dessus.

      Vous pouvez également afficher l'ID de clé publique de votre certificateur à tout moment à l'aide de la commande gcloud container binauthz attestors describe ${ATTESTOR}.

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

    PKIX (Cloud KMS)

    1. Configurez des variables d'environnement pour stocker les informations sur la paire de clés gérée par Cloud KMS :

      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
      KMS_KEY_PURPOSE=asymmetric-signing
      KMS_KEY_ALGORITHM=KMS_KEY_ALGORITHM
      KMS_PROTECTION_LEVEL=KMS_PROTECTION_LEVEL
      

      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é.
      • KMS_KEY_ALGORITHM : algorithme. Nous vous recommandons ec-sign-p256-sha256.
      • KMS_PROTECTION_LEVEL : niveau de protection ; par exemple, software.
    2. Créez un trousseau de clés Cloud KMS :

      gcloud --project ${KMS_KEY_PROJECT_ID} kms keyrings create \
        ${KMS_KEYRING_NAME} \
        --location ${KMS_KEY_LOCATION}
      
    3. Créez la clé :

      gcloud --project ${KMS_KEY_PROJECT_ID} 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}
      

      Pour en savoir plus sur la création de clés KMS, consultez la page Créer une clé asymétrique.

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

Vérifier que le certificateur a bien été créé

Pour vérifier que le certificateur a été créé, exécutez la commande suivante :

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

Étape suivante