Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feat: support oci image verification #147

Merged
merged 13 commits into from
Aug 17, 2022
Merged

Conversation

asraa
Copy link
Contributor

@asraa asraa commented Jul 13, 2022

Signed-off-by: Asra Ali [email protected]

Support OCI image verification in the GHA verifier. OCI images can be verified using

slsa-verifier verify-image ${IMAGE} --source-uri ${SOURCE_URI}

Added initial testing, for valid signatures, invalid builder IDs and invalid source repositories.

Copy link
Contributor

@naveensrinivasan naveensrinivasan left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What is the process to verify the attached binaries?

The goal is to make sure the e2e tests are reliable.

@asraa
Copy link
Contributor Author

asraa commented Jul 19, 2022

Yes @naveensrinivasan I'm still trying to figure out a testing strategy

What is the process to verify the attached binaries?

I don't understand the question. Binaries are already e2e tested.

The goal is to make sure the e2e tests are reliable.

Yeah. Ideally I'd be able to attach manifests for OCI images and use those to verify. I will probably need to implement a fake registry and a fake signed image for cosign. do you have other ideas?

@naveensrinivasan
Copy link
Contributor

Binaries are already e2e tested.

How were these specific binaries already e2e tested? I am trying to understand, so pardon my ignorance.

@naveensrinivasan
Copy link
Contributor

Binaries are already e2e tested.

How were these specific binaries already e2e tested? I am trying to understand, so pardon my ignorance.

🤦 Now, I see them as renamed and not new binaries. Thanks, it makes sense. I thought these were new binaries.

main.go Outdated
@@ -82,7 +92,13 @@ func main() {
"print the verified provenance to std out")
flag.Parse()

if provenancePath == "" || artifactPath == "" || source == "" {
if (provenancePath == "" || artifactPath == "") && ociImageRef == "" {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I feel like we should have different commands for containers vs. artifacts

The combinations of how flags are used isn't really very user friendly and I feel like it will just get worse over time.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

...not that I expect that to be implemented in this PR. Just a general comment.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

For v2, I'll try to write a one-pager on the SLSA verifier API. There are a few issues on this (#180) and I am worried without writing it up first I'll get it wrong.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just to be clear, I was simply thinking something like slsa-verifier verify-artifact ... and slsa-verifier verify-image ... something like that. Right now it's down to the combination of what flags users use. Commands allow us to have different flags for different CLI commands.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah, yes I agree too we should have sub-commands separating the two.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

SGTM

main.go Outdated Show resolved Hide resolved
@asraa
Copy link
Contributor Author

asraa commented Aug 2, 2022

Currently working with example-test packages

$ go run . -oci-image ghcr.io/slsa-framework/example-package.e2e.container.schedule.main.default.slsa3@sha256:93e556b16d8be1283f3825aa0ee595250649f56e70e18a3089d92ba29cd81e85 -source github.com/slsa-framework/example-package
Verified build using builder https://github.com/slsa-framework/slsa-github-generator/.github/workflows/generator_container_slsa3.yml@refs/heads/main at commit 8837317a8c8021fa59bb05260f363c7deb4ca63d
PASSED: Verified SLSA provenance

For some reason, crane manifest'ing the image doesn't show me where the cosign attesation layer is. Trying to retrieve some testadata manifests.

@asraa
Copy link
Contributor Author

asraa commented Aug 4, 2022

Got tests in. Waiting for the queue of PRs #187

and then I'll implement the VerifyImage on the builder interface.

@asraa asraa marked this pull request as ready for review August 9, 2022 19:58
@asraa
Copy link
Contributor Author

asraa commented Aug 9, 2022

@ianlewis @laurentsimon This is ready now.

I had to make a few changes for testing -- remote and local images behave slightly different. See the container package.

I will make an issue to add more testing: malicious tests, tag verification. Just wanted to start the functionality.

Copy link
Contributor

@laurentsimon laurentsimon left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM overall. Excited to see this one land!!

)

func main() {
flag.StringVar(&builderID, "builder-id", "", "EXPERIMENTAL: the unique builder ID who created the provenance")
flag.StringVar(&provenancePath, "provenance", "", "path to a provenance file")
flag.StringVar(&artifactPath, "artifact-path", "", "path to an artifact to verify")
flag.StringVar(&artifactReference, "artifact-reference", "", "reference to an OCI image to verify")
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

so are we giving up on the idea of verify-artifact and verify-container subcommand? What was decided in the end?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we should, should I do that in this PR though? If it's pretty easy to review I can split the commands

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

up to you, I don't mind either way

cli/slsa-verifier/main.go Show resolved Hide resolved
)

func main() {
flag.StringVar(&builderID, "builder-id", "", "EXPERIMENTAL: the unique builder ID who created the provenance")
flag.StringVar(&provenancePath, "provenance", "", "path to a provenance file")
flag.StringVar(&artifactPath, "artifact-path", "", "path to an artifact to verify")
flag.StringVar(&artifactReference, "artifact-reference", "", "reference to an OCI image to verify")
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm curious: is "reference" is standard term in container world?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yes, it means repository:tag. technically it also supports the actual digest, so maybe I should say -artifact-image (and image reference resolution will be implicit)?

Copy link
Contributor

@laurentsimon laurentsimon Aug 10, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see. If this is a common term, then it's fine. artifact-image would also work for me.
/cc @ianlewis any thoughts?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Changed to artifact-image for now. Leaving unresolved for feedback from Ian

cli/slsa-verifier/main.go Outdated Show resolved Hide resolved
cli/slsa-verifier/main_test.go Outdated Show resolved Hide resolved
cli/slsa-verifier/main_test.go Outdated Show resolved Hide resolved
cli/slsa-verifier/main_test.go Outdated Show resolved Hide resolved
cli/slsa-verifier/main_test.go Outdated Show resolved Hide resolved
verifiers/internal/gha/verifier.go Show resolved Hide resolved
verifiers/internal/gha/verifier.go Show resolved Hide resolved
Copy link
Contributor

@laurentsimon laurentsimon left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks. Left a few comments.

verifiers/internal/gha/verifier.go Show resolved Hide resolved
crname "github.com/google/go-containerregistry/pkg/name"
)

var GetImageDigest = func(image string) (string, error) {
Copy link
Contributor

@laurentsimon laurentsimon Aug 16, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Note: would this break if we verify in parallel different images that require changing this global variable?
I don't think we're going to need that any time soon.. unless the unit tests have to.

I wonder whether we this should be a func GetImageDigest() and have an interface that this function implement in a structure. This way anyone who needs to update the function can create their structure and set the function to whatever they want. By default, the function would be the one declared in this file.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmmm The purpose of this global is just for testing -- only testing will use the modified vars (and always will)

I wonder whether we this should be a func GetImageDigest() and have an interface that this function implement in a structure.

Actually, that can work. We can do a file-based impl and a registry-based implementation of the container. Then we can instantiate based on the params (was image str a local file or a container reference)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's fine to do that in a follow-up PR. Up to you.

Signed-off-by: Asra Ali <[email protected]>
Signed-off-by: Asra Ali <[email protected]>
@asraa asraa merged commit 7b4b9cd into slsa-framework:main Aug 17, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants