Chargement des données de stockage et de déploiement dans le linked artifacts page

Associez des packages et des builds dans votre organisation aux données de stockage et de déploiement.

Qui peut utiliser cette fonctionnalité ?

Anyone with write access to an organization-owned repository

Organization accounts on any plan

Dans cet article

Le linked artifacts page inclut les enregistrements de stockage et les enregistrements de déploiement pour les artefacts que vous construisez dans votre organisation. Les métadonnées de chaque artefact sont fournies par votre organisation à l’aide de l’une des méthodes suivantes :

  • Flux de travail contenant l’une des GitHub actions pour les attestations d’artefacts
  • Intégration à Dynatrace, JFrog Artifactory ou Microsoft Defender for Cloud
  • Script sur mesure utilisant l’API REST des métadonnées d’artefact

Les méthodes disponibles dépendent du chargement d’un enregistrement de stockage ou d’un enregistrement de déploiement. Pour plus d’informations sur les types d’enregistrements, consultez À propos des artefacts liés.

Chargement d’un enregistrement de stockage

Vous pouvez charger un enregistrement de stockage en créant une attestation d’artefact ou en activant une intégration avec JFrog Artifactory. Si vous ne souhaitez pas utiliser ces options, vous devez configurer une intégration personnalisée avec l’API REST.

Attester avec GitHub Actions

Vous pouvez importer un enregistrement de stockage pour un artéfact en utilisant les actions propres de GitHub pour les attestations d'artéfact. Vous pouvez le faire dans le même flux de travail que celui que vous utilisez pour générer l’artefact. Ces actions créent des garanties d’intégrité et de provenance signées pour le logiciel que vous générez, ainsi que le chargement automatique d’un enregistrement de stockage dans le linked artifacts page.

L’action d’attestation crée automatiquement des enregistrements de stockage sur le linked artifacts page si les deux conditions suivantes sont remplies :

  • L’option push-to-registry est définie sur true
  • Le flux de travail qui inclut l’action a l’autorisation artifact-metadata: write

Pour plus d’informations sur l’utilisation de ces actions, consultez Utilisation des attestations d’artefacts pour établir la provenance des builds.

Si l’artefact ne nécessite pas d’attestation ou si vous souhaitez charger des enregistrements de déploiement ou des métadonnées de stockage supplémentaires, consultez les sections suivantes.

Utilisation de l’intégration de JFrog

Cette intégration bidirectionnelle conserve automatiquement les enregistrements GitHub de stockage à jour avec l’artefact sur JFrog. Par exemple, les attestations que vous créez sur GitHub sont automatiquement téléchargées sur JFrog, et la promotion d'un artefact vers la production sur JFrog ajoute automatiquement le contexte de production à l'enregistrement sur GitHub.

Pour obtenir des instructions de configuration, consultez Get Started with JFrog Artifactory et GitHub Integration dans la documentation JFrog.

Utilisation de l’API REST

Pour les artefacts qui n’ont pas besoin d’être attestés et qui ne sont pas stockés sur JFrog, vous pouvez créer une intégration personnalisée à l’aide du point de terminaison de l’API Créer un enregistrement de stockage de métadonnées d’artefact . Vous devez configurer votre système pour appeler le point de terminaison chaque fois qu’un artefact est publié dans votre dépôt de package choisi.

Remarque

Si l’artefact n’est pas associé à une attestation de provenance sur GitHub, le github_repository paramètre est obligatoire.

Chargement d’un enregistrement de déploiement

Si vous surveillez les charges de travail déployées avec Dynatrace ou Microsoft Defender for Cloud (MDC), vous pouvez utiliser une intégration pour synchroniser automatiquement les données de déploiement vers le linked artifacts page. Sinon, vous devez configurer une intégration personnalisée avec l’API REST.

Utilisation de l’intégration de Dynatrace

Vous pouvez configurer Dynatrace pour envoyer des enregistrements de déploiement à GitHub pour les images de conteneur qui s'exécutent dans vos environnements Kubernetes surveillés par Dynatrace. Dynatrace associe les images déployées à vos référentiels, puis fournit le contexte d'exécution.

En outre, les enregistrements de déploiement de Dynatrace peuvent inclure le contexte de risque d’exécution, par exemple :

  • Exposition à l’Internet public
  • Accès aux données sensibles

Vous pouvez utiliser ce contexte dans le filtrage des alertes au niveau de l’organisation et dans les campagnes de sécurité pour hiérarchiser les alertes qui affectent les charges de travail de données sensibles ou exposées à Internet.

Pour obtenir des instructions de configuration, consultez GitHub Advanced Security l’intégration de la sécurité - Prise en main de la documentation Dynatrace.

Utilisation de l’intégration de Microsoft Defender for Cloud

Vous pouvez connecter votre MDC instance à votre GitHub organisation. MDC envoie automatiquement des données de déploiement et d’exécution à GitHub.

Pour obtenir des instructions de configuration, consultez Démarrage rapide : Connecter votre GitHub environnement à Microsoft Defender for Cloud dans la documentation pour MDC.

Remarque

L'intégration avec Microsoft Defender for Cloud est dans préversion publique et susceptible de changer.

Utilisation de l’API REST

Le point de terminaison de l’API Créer un enregistrement de déploiement d’artefacts permet aux systèmes d’envoyer des données de déploiement pour un artefact GitHubspécifique, comme son nom, digest, environnements, cluster et déploiement. Vous devez appeler ce point de terminaison chaque fois qu’un artefact est déployé dans un nouvel environnement intermédiaire ou de production.

Remarque

Si l’artefact n’est pas associé à une attestation de provenance sur GitHub, le github_repository paramètre est obligatoire.

Vérification d’un chargement

Pour vérifier qu’un enregistrement a été chargé avec succès, vous pouvez afficher l’artefact mis à jour dans les paramètres de votre organisation. Consultez Audit des builds de votre organisation sur le linked artifacts page.

Suppression d’enregistrements indésirables

Il n’est pas possible de supprimer un artefact du linked artifacts page. Toutefois, vous pouvez mettre à jour un enregistrement de stockage ou un enregistrement de déploiement pour refléter l’état d’un artefact. Consultez Suppression des artefacts du linked artifacts page.

Exemples GitHub Actions

Vous pouvez charger des données dans le linked artifacts page même flux de travail que celui que vous utilisez pour générer et publier un artefact.

Génération d’une attestation

Dans l’exemple suivant, nous créons et publions une image Docker, puis utilisons la ${{ steps.push.outputs.digest }} sortie à l’étape suivante pour générer une attestation de provenance.

L'action attest charge automatiquement un enregistrement de stockage sur le linked artifacts page lorsque push-to-registry: true est défini et que le flux de travail inclut la permission artifact-metadata: write.


env:
  IMAGE_NAME: my-container-image
  ACR_ENDPOINT: my-registry.azurecr.io

jobs:
  generate-build:
    name: Build and publish Docker image
    runs-on: ubuntu-latest
    permissions:
      id-token: write
      contents: read
      attestations: write
      packages: write
      artifact-metadata: write

    steps:
      - name: Build and push Docker image
        id: push
        uses: docker/build-push-action@263435318d21b8e681c14492fe198d362a7d2c83
        with:
          context: .
          push: true
          tags: |
            ${{ env.ACR_ENDPOINT }}/${{ env.IMAGE_NAME }}:latest
            ${{ env.ACR_ENDPOINT }}/${{ env.IMAGE_NAME }}:${{ github.sha }}

      - name: Generate artifact attestation
        uses: actions/attest@v4
        with:
          subject-name: ${{ env.ACR_ENDPOINT }}/${{ env.IMAGE_NAME }}
          subject-digest: ${{ steps.push.outputs.digest }}
          push-to-registry: true

Utilisation de l’API REST

Sinon, si vous ne générez pas d’attestation, vous pouvez appeler directement l’API de métadonnées d’artefact.


env:
  IMAGE_NAME: my-container-image
  IMAGE_VERSION: 1.1.2
  ACR_ENDPOINT: my-registry.azurecr.io

jobs:
  generate-build:
    name: Build and publish Docker image
    runs-on: ubuntu-latest
    permissions:
      id-token: write
      contents: read
      packages: write
      artifact-metadata: write

    steps:
      - name: Build and push Docker image
        id: push
        uses: docker/build-push-action@263435318d21b8e681c14492fe198d362a7d2c83
        with:
          context: .
          push: true
          tags: |
              ${{ env.ACR_ENDPOINT }}/${{ env.IMAGE_NAME }}:latest
              ${{ env.ACR_ENDPOINT }}/${{ env.IMAGE_NAME }}:${{ github.sha }}

      - name: Create artifact metadata storage record
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
        run: |
          jq -n --arg artifactName "${{ env.IMAGE_NAME }}" --arg artifactVersion "${{ env.IMAGE_VERSION }}" --arg artifactDigest "${{ steps.push.outputs.digest }}" '{"name": $artifactName, "digest": $artifactDigest, "version": $artifactVersion, "registry_url": "https://azurecr.io", "repository": "my-repository"}' > create-record.json

          gh api -X POST orgs/${{ github.repository_owner }}/artifacts/metadata/storage-record --input create-record.json
        shell: bash

Étapes suivantes

Une fois que vous avez chargé des données, les équipes de votre organisation peuvent utiliser le contexte à partir des données de stockage et de déploiement pour hiérarchiser les alertes de sécurité. Consultez Hiérarchisation des alertes Dependabot et d'analyse de code à l'aide du contexte de production.