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

Enable RH Registry signature verification by default #1349

Open
jasinner opened this issue Dec 19, 2019 · 16 comments
Open

Enable RH Registry signature verification by default #1349

jasinner opened this issue Dec 19, 2019 · 16 comments
Labels
lifecycle/frozen Indicates that an issue or PR should not be auto-closed due to staleness.

Comments

@jasinner
Copy link

Description

All images in the Red Hat registry are signed. We have the GPG key on disk to enable verification of these images when pulling, all that's left to do is configure Cri-o to verify the signatures when pulling those images.

Steps to reproduce the issue:

See: https://access.redhat.com/verify-images-ocp4

Describe the results you received:

Signatures are not verified

Describe the results you expected:

Verification steps from the reproduction article are met

Output of oc adm release info --commits | grep machine-config-operator:

machine-config-operator                       https://github.com/openshift/machine-config-operator                       d780d197a9c5848ba786982c0c4aaa7487297046

Additional environment details (platform, options, etc.):

OCP 4.2.12

@smarterclayton
Copy link
Contributor

Are there any negative implications of turning on verification? Would it fail for images that don’t have signatures for some reason (and are we certain all of them have signatures)?

@cgwalters
Copy link
Member

This almost may merit an enhancement but I'd also be fine just trying it out in master (4.4) for a bit...

@adambkaplan
Copy link

Would we want builds to perform similar signature checks for the base/builder images?

@jasinner
Copy link
Author

Are there any negative implications of turning on verification? Would it fail for images that don’t have signatures for some reason (and are we certain all of them have signatures)?

According to DELIVERY-5889 and DELIVERY-6699 they should all be signed. If an image doesn't have a signature and your pulling from one of the Red Hat repos (registry.access.redhat.com), or (registry.redhat.io) the pull will fail.

@jasinner
Copy link
Author

jasinner commented Dec 20, 2019

Would we want builds to perform similar signature checks for the base/builder images?

Sure, why not.

@adambkaplan
Copy link

This almost may merit an enhancement but I'd also be fine just trying it out in master (4.4) for a bit...

@cgwalters I'd like to see an enhancement so we can discuss what to do in builds. It's unclear to me how frequently customers use non-Red Hat images in their build pipelines.

@openshift-bot
Copy link
Contributor

Issues go stale after 90d of inactivity.

Mark the issue as fresh by commenting /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.
Exclude this issue from closing by commenting /lifecycle frozen.

If this issue is safe to close now please do so with /close.

/lifecycle stale

@openshift-ci-robot openshift-ci-robot added the lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. label Sep 24, 2020
@openshift-bot
Copy link
Contributor

Stale issues rot after 30d of inactivity.

Mark the issue as fresh by commenting /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.
Exclude this issue from closing by commenting /lifecycle frozen.

If this issue is safe to close now please do so with /close.

/lifecycle rotten
/remove-lifecycle stale

@openshift-ci-robot openshift-ci-robot added lifecycle/rotten Denotes an issue or PR that has aged beyond stale and will be auto-closed. and removed lifecycle/stale Denotes an issue or PR has remained open with no activity and has become stale. labels Oct 25, 2020
@openshift-bot
Copy link
Contributor

Rotten issues close after 30d of inactivity.

Reopen the issue by commenting /reopen.
Mark the issue as fresh by commenting /remove-lifecycle rotten.
Exclude this issue from closing again by commenting /lifecycle frozen.

/close

@openshift-ci-robot
Copy link
Contributor

@openshift-bot: Closing this issue.

In response to this:

Rotten issues close after 30d of inactivity.

Reopen the issue by commenting /reopen.
Mark the issue as fresh by commenting /remove-lifecycle rotten.
Exclude this issue from closing again by commenting /lifecycle frozen.

/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

@bparees
Copy link

bparees commented Mar 26, 2021

Are there any negative implications of turning on verification? Would it fail for images that don’t have signatures for some reason (and are we certain all of them have signatures)?

just for posterity: today the catalog images consumed by OLM are not signed. We're working on fixing that, though it looks like they'll be signed w/ a different key than the standard release key. So any effort to enable signature verification by default needs to take into account how the olm catalog images can be verified (or exempt them from verification)

@JAORMX
Copy link
Contributor

JAORMX commented May 18, 2021

Are there any negative implications of turning on verification? Would it fail for images that don’t have signatures for some reason (and are we certain all of them have signatures)?

just for posterity: today the catalog images consumed by OLM are not signed. We're working on fixing that, though it looks like they'll be signed w/ a different key than the standard release key. So any effort to enable signature verification by default needs to take into account how the olm catalog images can be verified (or exempt them from verification)

Is this still the case? Are even redhat-provided catalog images unsigned?

@bparees
Copy link

bparees commented May 18, 2021

Is this still the case? Are even redhat-provided catalog images unsigned?

yes. should be resolved soon. Here's some more info on how you can enable verification for everything else (the content the catalog references is still signed):

https://bugzilla.redhat.com/show_bug.cgi?id=1903632#c38

@cgwalters
Copy link
Member

I do think we should do this by default when we're ready.
/reopen
/lifecycle frozen

@openshift-ci openshift-ci bot reopened this Jan 25, 2022
@openshift-ci
Copy link
Contributor

openshift-ci bot commented Jan 25, 2022

@cgwalters: Reopened this issue.

In response to this:

I do think we should do this by default when we're ready.
/reopen
/lifecycle frozen

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

@openshift-ci openshift-ci bot added lifecycle/frozen Indicates that an issue or PR should not be auto-closed due to staleness. and removed lifecycle/rotten Denotes an issue or PR that has aged beyond stale and will be auto-closed. labels Jan 25, 2022
@cgwalters
Copy link
Member

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
lifecycle/frozen Indicates that an issue or PR should not be auto-closed due to staleness.
Projects
None yet
Development

No branches or pull requests

8 participants