Application d’attestations d’artefact avec un contrôleur d’admission Kubernetes

Utilisez un contrôleur d’admission pour appliquer des attestations d’artefact dans votre cluster Kubernetes.

Dans cet article

À propos du contrôleur d’admission Kubernetes

Les attestations d’artefact vous permettent de créer des garanties de provenance et d’intégrité non vérifiables pour le logiciel que vous créez. En retour, les personnes qui utilisent votre logiciel peuvent vérifier où et comment il a été conçu.

Les contrôleurs d’admission Kubernetes sont des plug-ins qui régissent le comportement du serveur d’API Kubernetes. Ils sont couramment utilisés pour appliquer les stratégies de sécurité et les meilleures pratiques dans un cluster Kubernetes.

À l’aide du projet open source du contrôleur de stratégie Sigstore, vous pouvez ajouter un contrôleur d’admission à votre cluster Kubernetes pouvant appliquer des attestations d’artefact. Ainsi, vous pouvez vous assurer que seuls les artefacts dotés d’attestations valides pourront être déployés.

Pour installer le contrôleur, nous proposons deux graphiques Helm : un pour le déploiement du contrôleur de stratégie Sigstore, et un autre pour le chargement de la racine de confiance GitHub et d’une stratégie par défaut.

À propos des racines de confiance et des stratégies

Le contrôleur de stratégie Sigstore est principalement configuré avec des racines de confiance et des stratégies, représentées par les ressources personnalisées TrustRoot et ClusterImagePolicy. Une TrustRoot représente un canal de distribution approuvé pour le matériel de clé publique utilisé pour vérifier les attestations. Une ClusterImagePolicy représente une stratégie permettant d’appliquer des attestations sur des images.

Une TrustRoot peut également contenir une racine de référentiel TUF, ce qui permet à votre cluster de recevoir en permanence et en toute sécurité des mises à jour de son matériel de clé publique approuvé. Si elle n’est pas spécifiée, une ClusterImagePolicy utilise par défaut le matériel clé open source de Sigstore Public Good Instance. Lors de la vérification des attestations générées pour les référentiels privés, la ClusterImagePolicy doit se référer à la TrustRoot de GitHub.

Bien démarrer avec le contrôleur d’admission Kubernetes

Pour configurer un contrôleur d’admission afin d’appliquer des attestations d’artefact GitHub, vous devez :

  1. Déployer le contrôleur de stratégie Sigstore.
  2. Ajouter la TrustRoot de GitHub et une ClusterImagePolicy à votre cluster.
  3. Activer la stratégie dans votre espace de noms.

Déployer le contrôleur de stratégie Sigstore

Nous avons empaqueté le contrôleur de stratégie Sigstore sous la forme d’un graphique Helm distribué par GitHub. Avant de commencer, vérifiez que les prérequis suivants sont remplis :

  • Un cluster Kubernetes avec la version 1.27 ou une version ultérieure
  • Helm 3.0 ou une version ultérieure
  • kubectl

Tout d’abord, installez le graphique Helm qui déploie le contrôleur de stratégie Sigstore :

Bash
helm upgrade policy-controller --install --atomic \
  --create-namespace --namespace artifact-attestations \
  oci://ghcr.io/github/artifact-attestations-helm-charts/policy-controller \
  --version v0.10.0-github9

Cela installe le contrôleur de stratégie dans l’espace de noms artifact-attestations. À ce stade, aucune stratégie n’a été configurée et aucune attestation ne sera appliquée.

Ajouter la TrustRoot de GitHub et une ClusterImagePolicy

Une fois le contrôleur de stratégie déployé, vous devez ajouter la TrustRoot de GitHub et une ClusterImagePolicy à votre cluster. Utilisez le graphique Helm que nous fournissons pour effectuer cette opération. Veillez à remplacer MY-ORGANIZATION par le nom de votre organisation GitHub (par exemple, github ou octocat-inc).

Bash
helm upgrade trust-policies --install --atomic \
 --namespace artifact-attestations \
 oci://ghcr.io/github/artifact-attestations-helm-charts/trust-policies \
 --version v0.6.2 \
 --set policy.enabled=true \
 --set policy.organization=MY-ORGANIZATION

Vous avez à présent installé la racine de confiance GitHub et une stratégie d’attestation d’artefact dans votre cluster. Cette stratégie rejette les artefacts qui ne proviennent pas de votre organisation GitHub.

Activer la stratégie dans votre espace de noms

Warning

Cette stratégie n’est pas appliquée tant que vous ne spécifiez pas les espaces de noms auxquels elle doit s’appliquer.

Chaque espace de noms de votre cluster peut appliquer indépendamment des stratégies. Pour activer la mise en œuvre dans un espace de noms, vous pouvez ajouter l’étiquette suivante à l’espace de noms :

metadata:
  labels:
    policy.sigstore.dev/include: "true"

Une fois l’étiquette ajoutée, la stratégie d’attestation d’artefact GitHub est appliquée dans l’espace de noms.

Vous pouvez aussi exécuter :

Bash
kubectl label namespace MY-NAMESPACE policy.sigstore.dev/include=true

Images correspondantes

Par défaut, la stratégie installée avec le trust-policies graphique Helm vérifie les attestations de toutes les images avant de les admettre dans le cluster. Si vous envisagez uniquement d’appliquer des attestations pour un sous-ensemble d’images, vous pouvez utiliser les valeurs policy.images Helm et policy.exemptImages spécifier une liste d’images à mettre en correspondance. Ces valeurs peuvent être définies sur une liste de modèles glob qui correspondent aux noms d’image. La syntaxe globbing utilise la sémantique go filepath, avec l’ajout de la correspondance à ** n’importe quelle séquence de caractères, y compris les barres obliques.

Par exemple, pour appliquer des attestations pour les images qui correspondent au modèle ghcr.io/MY-ORGANIZATION/* et admettre busybox sans attestation valide, vous pouvez exécuter :

Bash
helm upgrade trust-policies --install --atomic \
 --namespace artifact-attestations \
 oci://ghcr.io/github/artifact-attestations-helm-charts/trust-policies \
 --version v0.6.2 \
 --set policy.enabled=true \
 --set policy.organization=MY-ORGANIZATION \
 --set-json 'policy.exemptImages=["index.docker.io/library/busybox**"]' \
 --set-json 'policy.images=["ghcr.io/MY-ORGANIZATION/**"]'

Tous les modèles doivent utiliser le nom complet, même si les images proviennent de Docker Hub. Dans cet exemple, si nous voulons exempter l’image busybox, nous devons fournir le nom complet incluant le domaine et la glob double étoile pour couvrir toutes les versions de l’image : index.docker.io/library/busybox**.

Notez que toute image que vous envisagez d’admettre doit avoir un modèle glob correspondant dans la liste policy.images. Si une image ne correspond à aucun modèle, elle sera rejetée. En outre, si une image correspond à la fois à policy.images et policy.exemptImages, elle sera rejetée.

Si votre compte GitHub Enterprise a un sous-domaine sur GHE.com, vous devez spécifier une valeur pour le domaine d’approbation GitHub. Cette valeur est utilisée pour récupérer les documents approuvés associés à la région de résidence des données qui héberge votre compte GitHub Enterprise. Vous trouverez cette valeur en vous connectant à votre compte d’entreprise avec l’outil CLI gh et en exécutant la commande suivante :

Bash
gh api meta --jq .domains.artifact_attestations.trust_domain

Cette valeur doit être ajoutée lors de l’installation du graphique trust-policies, comme suit :

Bash
--set-json 'policy.trust.githubTrustDomain="YOUR-GHEC-TRUST-DOMAIN"'

Utilisation avancée

Pour afficher l’ensemble complet d’options que vous pouvez configurer avec le graphique Helm, vous pouvez exécuter l’une des commandes suivantes. Pour les options du contrôleur de stratégie :

Bash
helm show values oci://ghcr.io/github/artifact-attestations-helm-charts/policy-controller --version v0.10.0-github9

Pour les options de stratégie de confiance :

Bash
helm show values oci://ghcr.io/github/artifact-attestations-helm-charts/trust-policies --version v0.6.2

Pour plus d’informations sur le contrôleur de stratégie Sigstore, consultez la documentation relative au contrôleur de stratégie Sigstore.