virtual/apiexport: serve wildcard apibindings

[sttts]

Virtual workspaces should make the defining objects of workspaces visible. For APIExports, this is the APIBindings, for initializing workspace this would be the Workspace.

This PR adds the APIBindings (both wildcard requests and normal requests) to the APIExport VW.

It does that by adding a "reflexive claim label" to APIBindings marking the binding visible for the corresponding APIExport. The APIExport VW then can filter via a "IN" label selector, matching either the reflexive label or a real claim label:

// ToReflexiveAPIBindingLabelKeyAndValue returns label key and value that is set (as fallback for filtering)
// on APIBindings that point to the given APIExport and the binding has not accepted a claim to it.
func ToReflexiveAPIBindingLabelKeyAndValue(exportClusterName logicalcluster.Name, exportName string) (string, string) {
  claimHash := toBase62([28]byte{0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 0, 1, 2, 3, 4, 5, 6, 7})
  exportHash := toBase62(sha256.Sum224([]byte(exportClusterName.Join(exportName).String())))
  return apisv1alpha1.APIExportPermissionClaimLabelPrefix + exportHash, claimHash
}

This way the APIExport owners will always see "their own" bindings, but are able to claim access to all bindings, overriding the reflexive labels.

[sttts]

This PR is getting interesting (and it is just an example of more to come):

We want to make APIBindings available to the owner of the corresponding APIExport. But the owner can also claim permission on APIBindings. The later shows a superset of bindings (all, not only those belonging to the APIExport addressed by the VW).

So the challenging bit: label selectors do not allow disjunction. So we cannot say "show me all bindings for the current export, plus those that are claimed". At the same time, we cannot easily do disjunction on the storage layer in the VW. So this is tricky.

What I could imagine: now we set the claim label to:

func ToLabelKeyAndValue(permissionClaim apisv1alpha1.PermissionClaim) (string, string, error) {
	bytes, err := json.Marshal(permissionClaim)
	if err != nil {
		return "", "", err
	}
	hash := fmt.Sprintf("%x", sha256.Sum224(bytes))
	labelKeyHashLength := validation.LabelValueMaxLength - len(apisv1alpha1.APIExportPermissionClaimLabelPrefix)
	return apisv1alpha1.APIExportPermissionClaimLabelPrefix + hash[0:labelKeyHashLength], hash, nil
}

We could change that a little to

claimed.internal.apis.kcp.dev/<hash(root:org:ws:export-name)>: <hash(claim)>

With that we can express what the APIExport VW needs: claimed.internal.apis.kcp.dev/<hash(root:org:ws:export-name)> IN { <hash(claim)>, some-constant }

Then admission can either set the claim hash, if there is one, or the constant if there isn't and it's a binding against the APIExport.

[shawn-hurley]

I just have some questions but overall makes sense and looks good

I wonder if a comment explaining what API export/build BuildVirtualWorkspace is doing and what someone should expect in the return may be valuable?

[shawn-hurley]

Another question, around the options, is there ever a time when someone would want the APIExport VW but not have the bindings?

[sttts]

Another question, around the options, is there ever a time when someone would want the APIExport VW but not have the bindings?

No. With this PR the APIBinding is part of the virtual workspace API contract. You cannot specify and should ne depend on what you cannot see in a VW.

[sttts]

@shawn-hurley has a point with #1563 (comment).

/hold

Will turn into a hash after vacation.

[sttts]

/hold cancel

[ncdc]

submitting what i have so far so you don't have to wait for them all at the end. will continue reviewing.

[ncdc]

Can you use the field helpers (e.g. field.NewInvalid(field.NewPath - whatever is most appropriate here)?

[sttts]

done

[ncdc]

Can you use the field helpers (e.g. field.NewInvalid(field.NewPath - whatever is most appropriate here)?

[sttts]

done

[sttts]

Linker killed 🤷‍♂️

/retest

[openshift-ci]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: ncdc

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [ncdc]
• config/crds/OWNERS [ncdc]
• pkg/admission/OWNERS [ncdc]
• pkg/apis/OWNERS [ncdc]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment