ROX-29160: Add built-in signature integration for Red Hat signature

[guzalv]

Description

change me!

User-facing documentation

• CHANGELOG.md is updated OR update is not needed
• documentation PR is created and is linked above OR is not needed

Testing and quality

• the change is production ready: the change is GA, or otherwise the functionality is gated by a feature flag
• CI results are inspected

Automated testing

• added unit tests
• added e2e tests
• added regression tests
• added compatibility tests
• modified existing tests

How I validated my change

change me!

[openshift-ci]

Skipping CI for Draft Pull Request.
If you want CI signal for your change, please convert it to an actual PR.
You can still manually trigger a test run with /test all

[rhacs-bot]

Images are ready for the commit at e87a45d.

To use with deploy scripts, first export MAIN_IMAGE_TAG=4.9.x-98-ge87a45db91.

[codecov]

Codecov Report

Attention: Patch coverage is 82.50000% with 7 lines in your changes missing coverage. Please review.

Project coverage is 48.81%. Comparing base (c61921b) to head (e87a45d).

Files with missing lines	Patch %	Lines
...entral/signatureintegration/datastore/singleton.go	53.33%	5 Missing and 2 partials ⚠️

Additional details and impacted files

@@                                  Coverage Diff                                  @@
##           ROX-17872-Remove-remaining-reference-to-feature-flag   #15761   +/-   ##
=====================================================================================
  Coverage                                                 48.81%   48.81%           
=====================================================================================
  Files                                                      2590     2590           
  Lines                                                    190591   190629   +38     
=====================================================================================
+ Hits                                                      93029    93059   +30     
- Misses                                                    90252    90258    +6     
- Partials                                                   7310     7312    +2     

Flag	Coverage Δ
go-unit-tests	48.81% <82.50%> (+<0.01%)	⬆️

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

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[guzalv]

This change is part of the following stack:

• ROX-29160: Add feature flag ROX_RED_HAT_IMAGES_SIGNED_POLICY #15794
  • ROX-17872: Remove stale reference to feature flag #15795
    • ROX-29160: Add built-in signature integration for Red Hat signature #15761 ◀
      • ROX-29160: Add built-in policy to ensure Red Hat images are signed #15763

_{Change managed by git-spice.}

[stehessel]

Not a blocker, but one side effect of a default signature integration that I want to call out: Central currently has an optimization to skip image signature downloads if no signature integration has been added. If we add now a signature by default, this optimization will no longer work as is, and signatures will always be loaded. In the past some users have reported this as an issue because their image registries are self-hosted and are sensitive to additional load.

Some ideas come to my mind to address this issue:

• Rework the optimization such that image signature fetch is still skipped if the image is not a Red Hat image (and no other signature integrations exist).
• Remove the optimization and point customers towards disabling image signatures via feature flags if they are very sensitive to registry load. May also simplify the scan flow in general, as with the "skip optimization" users may wonder why no signatures are loaded in some cases (namely when there are no integrations).

As a side note, this optimization only works in Central - when using delegated scanning, image signature are already always fetched.

[guzalv]

Not a blocker, but one side effect of a default signature integration that I want to call out: Central currently has an optimization to skip image signature downloads if no signature integration has been added. If we add now a signature by default, this optimization will no longer work as is, and signatures will always be loaded. In the past some users have reported this as an issue because their image registries are self-hosted and are sensitive to additional load.

Some ideas come to my mind to address this issue:

• Rework the optimization such that image signature fetch is still skipped if the image is not a Red Hat image (and no other signature integrations exist).
• Remove the optimization and point customers towards disabling image signatures via feature flags if they are very sensitive to registry load. May also simplify the scan flow in general, as with the "skip optimization" users may wonder why no signatures are loaded in some cases (namely when there are no integrations).

As a side note, this optimization only works in Central - when using delegated scanning, image signature are already always fetched.

Thanks! I could have introduced a performance penalty for some customers without knowing.

I'm not a big fan of adding tangling between different areas of the product, special cases etc, which is what reworking the optimization implies. On the other I can imagine that customers who rely on the optimization would not be happy to see that it's been removed and now they need to use feature flags to prevent their registries from getting overloaded. So the tangling sounds better than this.

Are there any other alternatives here? How about reworking the optimization to only fetch signatures of images hosted at registries for which a signature integration exists? Does that sound too difficult/cumbersome?

[stehessel]

Are there any other alternatives here? How about reworking the optimization to only fetch signatures of images hosted at registries for which a signature integration exists? Does that sound too difficult/cumbersome?

The problem is that signature integrations do not depend on the registry. For example, I may create a signature integration for my public key - but I can use this public key to sign images of any registry. The only exception - more or less - are the Red Hat registries, where we know that all images are supposed to be signed by the golden key, and nobody else have write permissions to create any other signatures. So we could say something like "if only the Red Hat signature integration exists, then only download signatures for Red Hat images".

[guzalv]

Are there any other alternatives here? How about reworking the optimization to only fetch signatures of images hosted at registries for which a signature integration exists? Does that sound too difficult/cumbersome?

The problem is that signature integrations do not depend on the registry. For example, I may create a signature integration for my public key - but I can use this public key to sign images of any registry. The only exception - more or less - are the Red Hat registries, where we know that all images are supposed to be signed by the golden key, and nobody else have write permissions to create any other signatures. So we could say something like "if only the Red Hat signature integration exists, then only download signatures for Red Hat images".

Yeah right, I was mixing up signatures and policies, I meant "only fetch sigs of images hosted at registries for which a signature-verifying policy exists".

I imagine that this is probably a no-go, because we use the signature integration to verify signatures and at least display that info in the UI even if there's no policy involving signatures.

I will give a shot at your proposal, which seems to me like our best bet: "if only the Red Hat signature integration exists, then only download signatures for Red Hat images