Resource resolution on CD set

[mandelsoft]

What this PR does / why we need it:

Introduction resolution of relative resource references of the level of component descriptors.

So far, this the resolution was only possible on the level of the complete component version access abstraction.
This PR adds such a functionality on the level of plain component descriptors.
Therefore, it provides a ComponentVersionResolver abstraction for component descriptors, with two
implementations: a set of component descriptors and a compound resolver similar to the one for component version accesses.

To align the element names in package compdesc, the ComponentReferenceans been renamed to Reference (like Resource and Source). The old type has been deprecated.

This functionality is required for the OCM controllers working an deep resources for a component version.

To verify the digest of the retrieved content of a resource, a new function
signing.VerifyResourceDigest(cv, index, content)
is provided. it uses the digesting type described by the component version to recalculate the digest of the retrieved resource and verify it against the digest described by the component version.

[Skarlso]

Please confirm if I understand this correctly. Given a component version and a resolver that is configured with all the component descriptors from a references of the component version ( plus any references that have been references by the references ) we can now get a Resource and a descriptor using this single resolver?

[Skarlso]

So the current method of recursive lookup for a Resource is simply doing this:

	identities = append(identities, resource.ReferencePath...)

	res, _, err := utils.ResolveResourceReference(
		cva,
		ocmmetav1.NewNestedResourceRef(ocmmetav1.NewIdentity(resource.Name), identities),
		cva.Repository(),
	)
	if err != nil {
		return nil, "", -1, fmt.Errorf(
			"failed to resolve reference path to resource: %s %w",
			resource.Name,
			err,
		)
	}

Given an identity with the referencePath and the root component that function just simply figured out where the resource is given the path.

With this approach, and please correct me if I'm wrong, we have to construct a Set ( which needs all of the component descriptors from all the nested references), then a resolver for that set then call ResolveResourcePath and get our resource. Is that correct?

If yes, then it looks like we already done the work of gathering the component descriptors and at that point we would just fetch the resource ourselves.

[mandelsoft]

Yes, there is basically just a second resolution environment for component descriptors similar to the already existing one working on ocm.ComponentVersionAccess objects and ocm.ComponentVersionResolver`s.

This environment is in package ocm.compdesc:

• A special descriptor resolver interface ComponentVersionResolver
• A ComponentVersionSet as standard implementation for this interface, hosting just a set of ComponentDescriptors.
• A CompoundResolver to bundle multiple resolvers
• and the approriate functions to resolve references: ResolveReferencePath and ResolveResourceReference

These elements are 1:1 mappings of the current ones (in ocmutils) working on ComponentVersionAccesses.

Both environments work on the standard etav1.ResourceReference. But the compdesc version provide the Resource entry and the ComponentDescriptor of the requested resource. To access the resource content. The om library can be used directly of the component version of the found component descriptor.

Example:

  set := compdesc.NewComponentVersionSet()
  set.AddVersion(cd1)
  set.AddVersion(cd2)
  ...

 refpath := []metav1.Identity{...}
 rscid := metav1.NewIdentity("myresource")

  ref := metav1.NewNestedResourceRef(rscid, refpath)

or

  ref := metav1.NewResourceRef(rscid, comprefid1, ....)

 rsc, effcd, err := compdesc.ResolveResourceReference(rootcd, ref, set)
  ...
  
.
  var ocmrepo Repository = ...

  cv, err := ocmrepo.LookupComponentVersion(effcd.GetName(), effcd.GetVersion())

  reader, err := ocmutils.GetResourceReaderForPath(cv, ref.Resource)

or
  r, err := cv.GetResource(ref.Resource)
  reader, err :=  GetResourceReader(r)
		

So, if the K8s Component resource provides the serialized set of CDs along the ref hierarchy,
the K8s Resource resource just specifies the relative resource ref, which can be resolved according to the given CD set.
The returned compdesc.Resource provides the digest, which can be validated against the resource content provided by the reader.

May be, we have to provide a dedicated verification method, which takes the given artifact normalization into account for verifying the digest. I think, so far this is hard wired in the signature validation.

I'll check tomorrow...

[mandelsoft]

I added a new functionsigning.VerifyResourceDigest(cv, index, content) to do this job,

[Skarlso]

Okay, sure, however, my question was, that we already have a utils method that resolves and finds the right resource given an extra identity component path and the root component without the need for the resolvers and the set and the extra implementation of finding all of the component versions and putting them into the set.

So I was wondering what is the benefit of this implementation over the simple utils.ResolveResourceReference?

Is it that if we parse all of the ComponentDescriptors into k8s objects, we can provide those k8s objects to this set / resolver combination and it doesn't matter in what order we'll do that this thing will just figure it out which Component Version the searched Resource resides in?

[mandelsoft]

@Skarlso , exactly, if the k8s resource Component verifies the component version it should expose the transitive closure of component descriptors (which are covered by the verification). A k8s Resource resource is then able to use this set to resolve the resource reference without OCM repository access to figure out the effective component version. If the digest found for this version matches the digest provided by the Component resource it can verify the downloaded artifact content and assure this to be verified by the signature checked by the Component without rechecking the complete CV graph.

[Skarlso]

Gotcha, that makes sense. Thanks for the clarification.

[Skarlso]

A few remarks and a question regarding the new store.