Container provenance

[marcofranssen]

resolves #73

[marcofranssen]

Generating the provenance works now.

$ bin/slsa-provenance generate -github_context "{… left for brevity … }" -runner_context '{}' -container_repo ghcr.io/philips-labs/slsa-provenance -container_tags 'v0.4.0 33ba3da2213c83ce02df0f2f6ba925ec79037f9d' -artifact_path README.md -container_digest sha256:194b471a878add368bf02a7935fa099024576c029491bcefaeb87f81efa093a3
Generating provenance for 'ghcr.io/philips-labs/slsa-provenance' tags:
         - v0.4.0
         - 33ba3da2213c83ce02df0f2f6ba925ec79037f9d
Saving provenance to build.provenance

$ cat build.provenance 
{
  "_type": "https://in-toto.io/Statement/v0.1",
  "subject": [
    {
      "name": "ghcr.io/philips-labs/slsa-provenance:v0.4.0",
      "digest": {
        "sha256": "194b471a878add368bf02a7935fa099024576c029491bcefaeb87f81efa093a3"
      }
    },
    {
      "name": "ghcr.io/philips-labs/slsa-provenance:33ba3da2213c83ce02df0f2f6ba925ec79037f9d",
      "digest": {
        "sha256": "194b471a878add368bf02a7935fa099024576c029491bcefaeb87f81efa093a3"
      }
    }
  ],
  "predicateType": "https://slsa.dev/provenance/v0.2",
  "predicate": {
    "builder": {
      "id": "https://github.com/philips-labs/slsa-provenance-action/Attestations/SelfHostedActions@v1"
    },
    "buildType": "https://github.com/Attestations/GitHubActionsWorkflow@v1",
    "invocation": {
      "configSource": {
        "entryPoint": "Integration test file provenance",
        "uri": "git+https://github.com/philips-labs/slsa-provenance-action",
        "digest": {
          "sha1": "c4f679f131dfb7f810fd411ac9475549d1c393df"
        }
      },
      "parameters": null,
      "environment": null
    },
    "metadata": {
      "buildInvocationId": "https://github.com/philips-labs/slsa-provenance-action/actions/runs/1332651620",
      "buildFinishedOn": "2021-11-22T15:35:01Z",
      "completeness": {
        "parameters": true,
        "environment": false,
        "materials": false
      },
      "reproducible": false
    },
    "materials": [
      {
        "uri": "git+https://github.com/philips-labs/slsa-provenance-action",
        "digest": {
          "sha1": "c4f679f131dfb7f810fd411ac9475549d1c393df"
        }
      }
    ]
  }
}

Codebase needs cleanup before merge as explained in #93 to make this more predictable.

[codecov]

Codecov Report

Merging #88 (204d953) into main (33a20a0) will increase coverage by 0.11%.
The diff coverage is 79.85%.

@@            Coverage Diff             @@
##             main      #88      +/-   ##
==========================================
+ Coverage   78.21%   78.33%   +0.11%     
==========================================
  Files          12       15       +3     
  Lines         505      623     +118     
==========================================
+ Hits          395      488      +93     
- Misses         76       95      +19     
- Partials       34       40       +6     

Flag	Coverage Δ
unittests	78.33% <79.85%> (+0.11%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files	Coverage Δ
lib/intoto/intoto.go	100.00% <ø> (ø)
cmd/slsa-provenance/cli/container.go	73.68% <73.68%> (ø)
lib/oci/registry.go	78.12% <78.12%> (ø)
lib/oci/subjects.go	80.00% <80.00%> (ø)
lib/github/provenance.go	70.49% <92.30%> (+1.38%)	⬆️
cmd/slsa-provenance/cli/files.go	93.02% <100.00%> (+0.16%)	⬆️
cmd/slsa-provenance/cli/generate.go	100.00% <100.00%> (ø)
cmd/slsa-provenance/cli/github-release.go	55.55% <100.00%> (+0.83%)	⬆️
lib/intoto/subjects.go	80.64% <100.00%> (+1.33%)	⬆️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 33a20a0...204d953. Read the comment docs.

[ChaosInTheCRD]

Hey Marco! Quick question.. if a tag is specified, wouldn't it be possible to determine the digest of the image outwith the binary? and therefore no need for a parameter?

[marcofranssen]

@ChaosInTheCRD I have been trying to get the image digest in various ways. The image digest is only available after pushing the image to a registry. Currently we use the approach to run the provenance in a clean Github actions runner, by running that step in a separate job to not have any side effects from prior steps.

Besides that consumers of this Github Action might have their own versioning strategy of their docker images. So in that case we do not know for which tags we have to do the provenance. Therefore I decided to take the input arguments for now, to keep that flexibility. Then my code is verifying that image digest matches up with the tags to have some kind of validation.

Totally agree this is not the cleanest and easiest approach, but it also seems docker/oci registries have a way to pull all image tags for a given digest. Preferably I would have pulled all the tags from a given repository by digest. In that case I only need 2 arguments to pull all the images by digest and have this integrated in our CLI.

[ChaosInTheCRD]

@marcofranssen thanks for the reply. I think the decision to allow the user to pass in the digest, and compare it (see here) against the tags provided is a good idea for validation purposes. I guess you could argue that getting the digest for the image built in the workflow is out-with the scope of the action.

[ChaosInTheCRD]

I am considering whether expanding this command to also include flags that allow the user to present a provenance key to sign and upload the image to the registry would be worthwhile. However, this would clash with #91

[marcofranssen]

Once both PRs are ready I would love to reuse the signing logic and also do the attaching to docker image automagically. Just like we do with the github-release subcommand that auto uploads the provenance to the github release

[ChaosInTheCRD]

What I want to know @marcofranssen is whether the SLSA framework advocates for knitting the provenance generation, signing and uploading as close as possible.

My rationale is, if I create the provenance with slsa-provenance-action in one step, save it to disk, and then sign it and upload it in follow up steps... does that go against what is described in the "Service Generated" requirement:

The data in the provenance MUST be obtained from the build service (either because the generator is the build service or because the provenance generator reads the data directly from the build service). Regular users of the service MUST NOT be able to inject or alter the contents, except as noted below.

Maybe someone from the SLSA team could comment 😊

[ChaosInTheCRD]

Oh I see I am confused here. Does the github-release subcommand auto-upload the provenance straight after its generation? Meaning no need to save the provenance to disk?

[JeroenKnoops]

Awesome!!!