Créer des certificateurs à l'aide de la CLI

Cette page explique comment créer un certificateur dans l'autorisation binaire en ligne de commande à l'aide des commandes 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.

Présentation

Un certificateur est une ressource GCP 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 actions 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.

Définir le projet par défaut

Si ce n'est pas déjà fait, définissez le projet Google Cloud par défaut :

PROJECT_ID=PROJECT_ID
gcloud config set project ${PROJECT_ID}

Configurer l'environnement

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

DEPLOYER_PROJECT_ID=${PROJECT_ID}
DEPLOYER_PROJECT_NUMBER="$(
    gcloud projects describe "${DEPLOYER_PROJECT_ID}" \
      --format="value(projectNumber)"
)"
ATTESTOR_PROJECT_ID=${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.

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
    

    Où :

    • 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 sur la note

Vous devez également définir des autorisations sur la note Container Analysis que vous avez créée afin qu'elle soit accessible au compte de service du projet certifiant. Pour ce faire, vous devez mettre à jour la stratégie IAM de la note afin d'attribuer au compte le rôle containeranalysis.notes.occurrences.viewer.

Pour définir les autorisations, procédez comme suit :

  1. 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": "${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"
    

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 est le 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}" \
        beta 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 beta 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}" \
         beta 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 des 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
      

      Où :

      • KMS_KEY_PROJECT_ID correspond à l'ID du projet dans lequel les clés sont stockées ;
      • KMS_KEY_LOCATION correspond à l'emplacement de la clé ;
      • KMS_KEYRING_NAME correspond au nom du trousseau de clés ;
      • KMS_KEY_NAME correspond au nom de la clé ;
      • KMS_KEY_VERSION correspond à la version de clé.
    2. [Facultatif] Configurez une clé KMS :

      Créez une clé KMS pouvant ê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
      
      1. Créez un trousseau de clés KMS :
      gcloud kms keyrings create ${KMS_KEYRING_NAME} \
        --location ${KMS_KEY_LOCATION}
      
      1. 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}
      

      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}" \
          alpha 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 bien été créé, exécutez la commande suivante :

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

Étape suivante