Main Problem description:

The end user is signing and attesting their container images with cosign ( https://docs.sigstore.dev/cosign/signing/signing_with_containers/#sign-with-a-local-key-pair ). Attestations are attaching SLSA provenance JSON and SBOMs to the images. Unfortunately, it seems the satellite as a registry does not support this:

$ podman push satellite618.example.com/xxxxx/infra/k8s-debug:0.2.1
Getting image source signatures
Copying blob eaacaedf7cb8 skipped: already exists  
Copying blob d344a99c689e skipped: already exists  
Copying config d360654c93 done   | 
Writing manifest to image destination

$ cosign sign --tlog-upload=false --sk satellite618.example.com/xxxxx/infra/k8s-debug@sha256:xxxxxxxxxxxx
setting TUF refresh period to 24h0m0s
WARNING: no x509 certificate retrieved from the PIV token
Error: signing [satellite618.example.com/xxxxx/infra/k8s-debug@sha256:xxxxxxxxxxxx]: accessing image: unknown mime type: application/vnd.docker.distribution.manifest.v2+json; charset=utf-8
error during command execution: signing [satellite618.example.com/xxxxx/infra/k8s-debug@sha256:xxxxxxxxxxxx]: accessing image: unknown mime type: application/vnd.docker.distribution.manifest.v2+json; charset=utf-8

Current situation:

• From what I could find out, Katello ( as in satellite itself ) is not yet integrated with the registry signing service of pulp, and Satellite QE also confirmed that, cosign or registry signing process is not something that has been tested or integrated with satellite.

• This doc https://pulpproject.org/pulp_container/docs/admin/guides/sign-image/ explains the way Pulp supports it but that signing service is yet be part of Katello for it to work via Satellite. 

Expected workflow defined by the end-user:

Through GitLab CI pipelines:

• They build and push container images using CI pipelines (Gitlab).
• They signed the image with Cosign in the registry
• During pipeline run, They create SLSA image provenance, sign this provenance file and attest it to the image in the registry
• During pipeline run,  SBOM is generated to the application and image. They merge these, sign it and attest it to the registry with Cosign
• And then they pull these images with podman and kubernetes (BTW, kubernetes pull fails as well)

Expectations from Satellite as an OCI registry:

The user had the idea to use the Red Hat Satellite registry as a "generic" OCI registry for all infrastructure-related images. Of course, this would require that is supports all of these use cases.

As currently, Red Hat Satellite Registry is far to be usable for this purpose and they will migrate away from the current registry ( e.g. Sat acting as registry ) and will start to use another solution. 

Once the explained feature has been implemented and can be integrated in the explained workflow, they will move back to Satellite ( to use it as the registry ).