Github Job only producing one intoto.jsonl file

[zurrehma]

I have Github build running which is building three docker images, for each docker image I want attestation.intoto.jsonl file but I am only getting one file in Artifacts. Is it due to static name and overriding happening? if so, how can I change the file name since I am not seeing the attestaion-name var in input

How can I produce three intoto.jsonl for three docker images in one build?

[laurentsimon]

Thanks for the report. The generic generator is not officially released, please see https://github.com/slsa-framework/slsa-github-generator#generation-of-provenance

We are going to release this week. We have added support for the user to provide an attestation-name.

Note that we workflow only outputs a single attestation, and it has the attestation for all the artifacts you pass in base64-subjects.

Is that enough for your use case?

[zurrehma]

Note that we workflow only outputs a single attestation, and it has the attestation for all the artifacts you pass in base64-subjects.

@laurentsimon I am calling the slsa generic generator this way, will it still satisfy the above?

  generate-init-image-provenance:
    needs: push-init-image
    permissions:
      id-token: write # To sign the provenance.
      contents: write # To upload assets to release.
      actions: read #To read the workflow path.
    # needs: args
    uses: slsa-framework/slsa-github-generator/.github/workflows/[email protected]
    with:
      base64-subjects: "${{ needs.push-init-image.outputs.init_sha256sum_digest }}"

  generate-image-provenance:
    needs: push-image
    permissions:
      id-token: write # To sign the provenance.
      contents: write # To upload assets to release.
      actions: read #To read the workflow path.
    # needs: args
    uses: slsa-framework/slsa-github-generator/.github/workflows/[email protected]
    with:
      base64-subjects: "${{ needs.push-image.outputs.image_sha256sum_digest }}"

  generate-image-cli-provenance:
    needs: push-image-cli
    permissions:
      id-token: write # To sign the provenance.
      contents: write # To upload assets to release.
      actions: read #To read the workflow path.
    # needs: args
    uses: slsa-framework/slsa-github-generator/.github/workflows/[email protected]
    with:
      base64-subjects: "${{ needs.push-image-cli.outputs.cli_sha256sum_digest }}"
  

[zurrehma]

Additionally, it will be also helpful if you can tell me how I can decode(command) the attestation.intoto.jsonl file?

[laurentsimon]

your example is correct if you want 3 different attestation files. Some points:

Note: You can use a single call to the re-usable workflow if a single attestation file is enough for your use case (the attestation will attest to the 3 hashes instead of 1).

To verify the provenance, use https://github.com/slsa-framework/slsa-verifier. You can pass --print-provenance and pipe that into jq to see the provenance after it's been verified: slsa-verifier -provenance <> -source github.com/your/repo --print-provenance | jq.

To read the raw provenance yourself, you can use cat example.intoto.jsonl | jq -r '.payload' | base64 -d | jq

[zurrehma]

slsa-verifier gives an error when I don't provide -artifact-path?

[laurentsimon]

yes, that's intended. If you want the verifier to be able to verify a container image and pull the provenance automatically from the registry, you'll have to use the "container generator" instead. We're working on it and will release in Aug-Sept (see https://github.com/slsa-framework/slsa-github-generator#provenance-only-generators)

[ianlewis]

@zurrehma As @laurentsimon mentioned, in order to be able to verify provenance for container images you need to use the new "container generator" workflow. See the doc here: https://github.com/slsa-framework/slsa-github-generator/tree/main/internal/builders/container

Note that while this is experimental, you should be able to test it out with a workflow like the following:

generate-init-image-provenance:
  needs: [push-init-image]
  permissions:
    actions: read # for detecting the Github Actions environment.
    id-token: write # for creating OCID tokens for signing.
    packages: write # for uploading attestations.
  # TODO(https://github.com/slsa-framework/slsa-github-generator/issues/492): Use a tagged release once we have one.
  uses: slsa-framework/slsa-github-generator/.github/workflows/generator_container_slsa3.yml@main
  with:
    image: ${{ needs.push-init-image.outputs.tag }}
    digest: ${{ needs.push-init-image.outputs.digest }}
    registry-username: ${{ env.REGISTRY_USERNAME }}
    # TODO(https://github.com/slsa-framework/slsa-github-generator/issues/492): Remove after GA release.
    compile-generator: true
  secrets:
    registry-password: ${{ secrets.REGISTRY_PASSWORD }}

generate-image-provenance:
  needs: [push-image]
  permissions:
    actions: read # for detecting the Github Actions environment.
    id-token: write # for creating OCID tokens for signing.
    packages: write # for uploading attestations.
  # TODO(https://github.com/slsa-framework/slsa-github-generator/issues/492): Use a tagged release once we have one.
  uses: slsa-framework/slsa-github-generator/.github/workflows/generator_container_slsa3.yml@main
  with:
    image: ${{ needs.push-image.outputs.tag }}
    digest: ${{ needs.push-image.outputs.digest }}
    registry-username: ${{ env.REGISTRY_USERNAME }}
    # TODO(https://github.com/slsa-framework/slsa-github-generator/issues/492): Remove after GA release.
    compile-generator: true
  secrets:
    registry-password: ${{ secrets.REGISTRY_PASSWORD }}

generate-image-cli-provenance::
  needs: [push-image-cli]
  permissions:
    actions: read # for detecting the Github Actions environment.
    id-token: write # for creating OCID tokens for signing.
    packages: write # for uploading attestations.
  # TODO(https://github.com/slsa-framework/slsa-github-generator/issues/492): Use a tagged release once we have one.
  uses: slsa-framework/slsa-github-generator/.github/workflows/generator_container_slsa3.yml@main
  with:
    image: ${{ needs.push-image-cli.outputs.tag }}
    digest: ${{ needs.push-image-cli.outputs.digest }}
    registry-username: ${{ env.REGISTRY_USERNAME }}
    # TODO(https://github.com/slsa-framework/slsa-github-generator/issues/492): Remove after GA release.
    compile-generator: true
  secrets:
    registry-password: ${{ secrets.REGISTRY_PASSWORD }}

The image attestations can then be verified using cosign

$ export COSIGN_EXPERIMENTAL=1
$ cosign verify-attestation --type slsaprovenance [INIT_IMAGE]
$ cosign verify-attestation --type slsaprovenance [IMAGE]
$ cosign verify-attestation --type slsaprovenance [IMAGE_CLI]

We are working on adding support to slsa-verifier for container in https://github.com/slsa-framework/slsa-verifier/issues/92

You can follow progress via the milestone for the container generator workflow GA here: https://github.com/slsa-framework/slsa-github-generator/milestone/3

[zurrehma]

Thanks @ianlewis @laurentsimon for useful info, some questions:

1. Can we use container generators for offical use? As release data is in sep and milestone progress is yet in intial stages.

2. How can we make sure that the provenance either produced through generaic or container generator is legit one? What if somebody temper with provenance file and attach it to their own malecious docker image?

3. One of the SLSA level 3 requirment is "The provenance identifies the top-level instructions used to execute the build. The identified instructions SHOULD be at the highest level available to the build", How we can injeect our build commands in generaic or container generator?

[ianlewis]

Thanks @ianlewis @laurentsimon for useful info, some questions:

1. Can we use container generators for offical use? As release data is in sep and milestone progress is yet in intial stages.

You can use it as long as you're ok with some potential instability before we announce it as generally available. It's not yet as well tested as the other workflows we have made generally available. I don't anticipate too many changes, but there may be some.

2. How can we make sure that the provenance either produced through generaic or container generator is legit one? What if somebody temper with provenance file and attach it to their own malecious docker image?

This project wouldn't be useful if we didn't do that! The OIDC identity for the reusable workflow (generator_container_slsa3.yml) is used to sign the provenance and the public key to verify the provenance is stored in the public rekor transparency log. If someone tampers with the the file then the signature will fail to verify. If someone uses a different image (different image digest) the provenance will fail to verify.

3. One of the SLSA level 3 requirment is "The provenance identifies the top-level instructions used to execute the build. The identified instructions SHOULD be at the highest level available to the build", How we can injeect our build commands in generaic or container generator?

Our take is that the "top-level instructions" is the user's GitHub Actions workflow. This is recorded in the invocation.entryPoint. It says that "The identified instructions SHOULD be at the highest level available to the build" so you don't necessarily all the the instructions as they are part of your workflow file.

[laurentsimon]

2. How can we make sure that the provenance either produced through generaic or container generator is legit one? What if somebody temper with provenance file and attach it to their own malecious docker image?

This project wouldn't be useful if we didn't do that! The OIDC identity for the reusable workflow (generator_container_slsa3.yml) is used to sign the provenance and the public key to verify the provenance is stored in the public rekor transparency log. If someone tampers with the the file then the signature will fail to verify. If someone uses a different image (different image digest) the provenance will fail to verify.

You should use the verifier https://github.com/slsa-framework/slsa-verifier to verify the provenance. I encourage you to change the binary / provenance file and you will see that verification will fail. You can also see https://slsa.dev/blog/2022/06/slsa-github-workflows for an overview.

[ianlewis]

2. How can we make sure that the provenance either produced through generaic or container generator is legit one? What if somebody temper with provenance file and attach it to their own malecious docker image?

This project wouldn't be useful if we didn't do that! The OIDC identity for the reusable workflow (generator_container_slsa3.yml) is used to sign the provenance and the public key to verify the provenance is stored in the public rekor transparency log. If someone tampers with the the file then the signature will fail to verify. If someone uses a different image (different image digest) the provenance will fail to verify.

You should use the verifier https://github.com/slsa-framework/slsa-verifier to verify the provenance. I encourage you to change the binary / provenance file and you will see that verification will fail. You can also see https://slsa.dev/blog/2022/06/slsa-github-workflows for an overview.

Right now slsa-verifier doesn't support containers (https://github.com/slsa-framework/slsa-verifier/issues/92) so you'll need to use cosign verify-attestation --type slsaprovenance <image> to verify the image. You can optionally write a cue or rego policy file and specify it using the --policy flag.

We will have support in slsa-verifier for OCI images before GA of the container workflow.

[zurrehma]

You should use the verifier https://github.com/slsa-framework/slsa-verifier to verify the provenance. I encourage you to change the binary / provenance file and you will see that verification will fail. You can also see https://slsa.dev/blog/2022/06/slsa-github-workflows for an overview.

If someone is using my docker image, don't you think this will be an extra step to download the verifier and then verify it (considering there might be installation problems or other sorts of issue). Can't i just provide some simple verifying method to the user who is using my docker image?

Also what or how the slsa verifier verify the docker image or artifact?

[ianlewis]

If someone is using my docker image, don't you think this will be an extra step to download the verifier and then verify it (considering there might be installation problems or other sorts of issue). Can't i just provide some simple verifying method to the user who is using my docker image?

I'm not sure exactly what you had in mind but, verification has to be done using some kind of tool and docker doesn't have SLSA or any kind of provenance verification functionality built-in. Verification can't be done by hand because it requires verifying a cryptographic signature, and several fields in the provenance. Verifying by hand would also be very error prone and can't really be automated.

So anyone consuming the image will need to use a tool like slsa-verifier or cosign to verify the image.

Also what or how the slsa verifier verify the docker image or artifact?

The slsa-verifier verifies the signature and identity that was used to sign the provenance. It also verifies the repository, branch, and that the source used is a tagged with a compatible semver release. That said, slsa-verifier support for verification of container images is still being worked on.

There are a few more options with regard to containers and verification. We haven't really documented them properly yet but they include cosign (#655), Kyverno (#389), and sigstore policy-controller (#491). These tools will allow you to write granular policy checks against the provenance.

[laurentsimon]

We could also provide a slsa verifier as a container.

[zurrehma]

I'm not sure exactly what you had in mind but, verification has to be done using some kind of tool and docker doesn't have SLSA or any kind of provenance verification functionality built-in. Verification can't be done by hand because it requires verifying a cryptographic signature, and several fields in the provenance. Verifying by hand would also be very error prone and can't really be automated.

Actually i am working with kyverno team to make kyverno SLSA level 3 complient.

There are a few more options with regard to containers and verification. We haven't really documented them properly yet but they include cosign (https://github.com/slsa-framework/slsa-github-generator/issues/655), Kyverno (https://github.com/slsa-framework/slsa-github-generator/issues/389), and sigstore policy-controller (https://github.com/slsa-framework/slsa-github-generator/issues/491). These tools will allow you to write granular policy checks against the provenance.

This is i think the problem if someone is using kyverno policy engine for verification of their images, he needs to first verify that kyverno image which is being used is legit one?

[zurrehma]

Also using container generator, i am not seeing any provenance artifacts being generated. Is this intentional? Here is the link to workflow file and successful build.

[laurentsimon]

In the case of containers, the attestation if uploaded to the registry but not present in the artifact or release assets. The main reason is that this seems to be standard practice for delivering the provenance. There should be a ghcr.io/zurrehma/kyvernopre:sha256-<abcdef...>.att uploaded to the registry.

You can use crane manifest ghcr.io/zurrehma/kyvernopre:sha256-<abcdef...>.att to view it:

{
  "schemaVersion": 2,
  "mediaType": "application/vnd.oci.image.manifest.v1+json",
  "config": {
    "mediaType": "application/vnd.oci.image.config.v1+json",
    "size": 233,
    "digest": "sha256:4fc40b3f7b2a8d7cfd60e49d5a7d53a1ec8d506a9e109f3cbf79a0104f8a3ae9"
  },
  "layers": [
    {
      "mediaType": "application/vnd.dsse.envelope.v1+json",
      "size": 10576,
      "digest": "sha256:SOME_SHA",
      "annotations": {
        "dev.cosignproject.cosign/signature": "",
...

You can then view the attestation via crane blob ghcr.io/zurrehma/kyvernopre@sha256:SOME_SHA | jq -r '.payload' | base64 -d | jq:

{
  "_type": "https://in-toto.io/Statement/v0.1",
  "predicateType": "https://slsa.dev/provenance/v0.2",
  "subject": [
    {
      "name": "ghcr.io/zurrehma/kyvernopre",
      "digest": {
        "sha256": "some-hash"
      }
    }
  ],

[ianlewis]

This is i think the problem if someone is using kyverno policy engine for verification of their images, he needs to first verify that kyverno image which is being used is legit one?

Yes. I assume they either sign or generate provenance for their images that you can verify with cosign.

In the case of containers, the attestation if uploaded to the registry but not present in the artifact or release assets. The main reason is that this seems to be standard practice for delivering the provenance.

Yes. We upload the provenance to the registry alongside the image. You can also view it using cosign:

$ cosign tree ghcr.io/slsa-framework/example-package.e2e.container.schedule.main.default.slsa3:main
📦 Supply Chain Security Related artifacts for an image: ghcr.io/slsa-framework/example-package.e2e.container.schedule.main.default.slsa3:main
└── 💾 Attestations for an image tag: ghcr.io/slsa-framework/example-package.e2e.container.schedule.main.default.slsa3:sha256-35b98700fe048347c1c06765f32c494104ed565d3397d7858480bf7c50b00903.att
   └── 🍒 sha256:134411b13ea507d0cf3fb72c01ce404089bee098994da22f5f9df5ad50b9ad4a

[laurentsimon]

I did not know about that cosign tree command, it's neat!

[ianlewis]

The contents can be viewed with the download command too.

$ cosign download attestation ghcr.io/slsa-framework/example-package.e2e.container.schedule.main.default.slsa3:main | jq -r '.payload' | base64 -d | jq | head
{
  "_type": "https://in-toto.io/Statement/v0.1",
  "predicateType": "https://slsa.dev/provenance/v0.2",
  "subject": [
    {
      "name": "ghcr.io/slsa-framework/example-package.e2e.container.schedule.main.default.slsa3",
      "digest": {
        "sha256": "35b98700fe048347c1c06765f32c494104ed565d3397d7858480bf7c50b00903"
      }
    }

[ianlewis]

@zurrehma I think that the answer was to use the container workflow and slsa-verifier, cosign, Kyverno, or sigstore policy-controller for verification.

As I don't think there is any changes that we need to make I'm going to close this issue. Feel free to re-open if you still think there are some specific changes that need to be made.