linked artifacts page へのストレージおよびデプロイメント データのアップロード

組織内のパッケージとビルドをストレージと展開データに関連付けます。

この機能を使用できるユーザーについて

Anyone with write access to an organization-owned repository

Organization accounts on any plan

この記事で

linked artifacts page には、組織で構築した成果物のストレージ レコードとデプロイ レコードが含まれます。 各成果物のメタデータは、次のいずれかの方法を使用して組織によって提供されます。

  • GitHub のアクションを含むアーティファクト証明に対するワークフロー
  •         **JFrog Artifactory** または **Microsoft Defender for Cloud** との統合

  •         **アーティファクト メタデータ REST API** を使用したカスタム スクリプト

使用できる方法は、ストレージ レコードとデプロイ レコードのどちらをアップロードするかによって異なります。 レコード・タイプの詳細については、 AUTOTITLE を参照してください。

ストレージ レコードのアップロード

ストレージ レコードをアップロードするには、 成果物の構成証明 を作成するか、 JFrog Artifactory との統合を有効にします。 これらのオプションを使用しない場合は、 REST API とのカスタム統合を設定する必要があります。

GitHub Actions による認証

成果物のストレージ レコードをアップロードするには、GitHubのアーティファクト構成証明に対するファースト パーティのアクションを使用します。 これは、成果物のビルドに使用するのと同じワークフローで行うことができます。 これらのアクションにより、ビルドするソフトウェアの署名付き実証と整合性の保証が作成され、ストレージ レコードが linked artifacts page に自動的にアップロードされます。

(Note: Depending on specific requirements or known terms within the application's Japanese context, further information or context might adjust how this content should be presented.)

これらのアクションの使用方法の詳細については、 AUTOTITLE を参照してください。

成果物に構成証明が必要ない場合、またはデプロイ レコードまたは追加のストレージ メタデータをアップロードする場合は、次のセクションを参照してください。

JFrog 統合の利用

この双方向統合により、GitHub 上のストレージ レコードが JFrog の成果物と共に最新の状態に自動的に保持されます。 たとえば、GitHub で作成した構成証明は自動的に JFrog にアップロードされ、成果物を JFrog 上の実稼働に昇格すると、GitHub のレコードに実稼働コンテキストが自動的に追加されます。

セットアップ手順については、 JFrog ドキュメントの「JFrog Artifactory と GitHub Integration の概要 」を参照してください。

REST API の使用

証明する必要がない成果物と JFrog に格納されていない成果物の場合は、 成果物メタデータ ストレージ レコードの作成 API エンドポイントを使用してカスタム統合を作成できます。 選択したパッケージ リポジトリに成果物が発行されるたびにエンドポイントを呼び出すシステムを構成する必要があります。

メモ

成果物が GitHub の来歴証明に関連付けられていない場合は、github_repository パラメーターが必須です。

デプロイ レコードのアップロード

          **アーティファクトを Microsoft Defender for Cloud (MDC)** に格納する場合は、統合を使用して、データを linked artifacts page に自動的に同期できます。 それ以外の場合は、 **REST API** とのカスタム統合を設定する必要があります。

Microsoft Defender for Cloud の統合を利用する

MDC インスタンスを GitHub 組織に接続することができます。 MDC は、デプロイ データとランタイム データを GitHub に自動的に送信します。

セットアップ手順については、「クイック スタート: GitHub 環境を Microsoft Defender for Cloud に接続する」ドキュメントのMDCを参照してください。

メモ

Microsoft Defender for Cloud との統合はパブリック プレビュー にあり、変更される可能性があります。

REST API の使用

          [成果物デプロイ レコードの作成](/rest/orgs/artifact-metadata#create-an-artifact-deployment-record) API エンドポイントを使用すると、システムは特定の成果物のデプロイ データを GitHub (名前、ダイジェスト、環境、クラスター、デプロイなど) に送信できます。 成果物が新しいステージング環境または運用環境にデプロイされるたびに、このエンドポイントを呼び出す必要があります。

メモ

成果物が GitHub の来歴証明に関連付けられていない場合は、github_repository パラメーターが必須です。

アップロードの確認

レコードが正常にアップロードされたことを確認するには、組織の設定で更新された成果物を表示できます。 「組織のビルドをlinked artifacts page で監査する」を参照してください。

不要なレコードの削除

linked artifacts page から成果物を削除することはできません。 ただし、成果物の状態を反映するようにストレージ レコードまたはデプロイ レコードを更新できます。 「linked artifacts page からの成果物の削除」を参照してください。

GitHub Actions の例

成果物のビルドと発行に使用するのと同じワークフローで、linked artifacts page にデータをアップロードできます。

証明書の生成

次の例では、Docker イメージをビルドして発行し、次の手順で ${{ steps.push.outputs.digest }} 出力を使用して、実証構成証明を生成します。

          `attest-build-provenance`アクションは、`push-to-registry: true`が設定され、ワークフローに`artifact-metadata: write`アクセス許可が含まれている場合、ストレージ レコードを linked artifacts page に自動的にアップロードします。


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-build-provenance@v3
        with:
          subject-name: ${{ env.ACR_ENDPOINT }}/${{ env.IMAGE_NAME }}
          subject-digest: ${{ steps.push.outputs.digest }}
          push-to-registry: true

REST API の使用

または、構成証明を生成していない場合は、成果物メタデータ API を直接呼び出すことができます。


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

次のステップ

データをアップロードすると、組織内のチームは、ストレージデータと展開データのコンテキストを使用してセキュリティ アラートの優先順位を付けることができます。 「運用コンテキストを使用した Dependabot とコード スキャンアラートの優先順位付け」を参照してください。