Initial version of OCI registry as storage

[0xavi0]

Implements an initial proposal to use OCI registries as storage.

NOTE: The feature is only available when the environment variable EXPERIMENTAL_OCI_STORAGE is set to true.

Adds the following new options to the gitrepo yaml:

// when ociRegistry is defined fleet will use oci registry as storage
ociRegistry:
    // url is the OCI registry url.
    url: "docker.io/your-user-here"
    // secret name where the credentials for the OCI registry are.
    // expects a generic secret with username and password keys set.
    authSecretName: oci-secret
    // basicHTTP allows fleet to uses basic http connections to communicate
    // with the registry (defaults to false)
    basicHTTP: false
    // insecureSkipTLS allows connections to the OCI registry
    // without certs (defaults to false)
    insecureSkipTLS: false

New parameters are passed to fleet apply to propagate the values above.

If at least the url value is set, fleet apply will do the following:

• Creates a manifest from the resources found in the bundle
• Creates and pushes an OCI manifest
• Clears the bundle's resource list (contents are in the OCI registry)
• Adds the contentID value (this is a new value) in the bundles spec
• Creates a secret to pass the OCI registry values to the fleet controller and agents. This secret contains all the values so the controller and agents are able to reach the OCI registry.

The upstream fleet controller then reconciles the just created bundle (remember, with no resources and the content's id set).

When targeting, it also clones the secret containing all the OCI values, just changing the namespace to match the bundledeployment's namespace. (This way the agents will be able to obtain the OCI values) It will also flag the bundledeployment to state that the content is stored in the OCI registry instead to a content resource.

When deploying, the agents will check if the bundledeployment is flagged to has its contents in an OCI registry. If so, it gathers the OCI values it needs to access the registry from the bundledeployment secret and pulls the OCI manifest which is converted back into a fleet manifest.

The agent deploys the manifest just like a regular manifest that was stored as a contents resource.

All secrets created have the owner set to the bundle or bundledeployment so they are properly garbage collected when their owners are deleted.

To be defined / todo / other considerations:

• OCI registry garbage collection? (do we need this?)
• Sign the OCI manifest when pushing the OCI manifest and check for the signature when pulling and before deploying to avoid back doors. At the moment the code checks that the id annotation is found in the OCI manifest and that it matches the expected content id. We could, maybe, use annotations to add a signature field.
• This implementation does not fallback to normal bundle + resource list + content resource if there is any issue connecting to the OCI registry. That's something we could do as bundle keeps the info to know if it is stored in a remote OCI registry or not.

This has been tested with:

• zot with basic HTTP
• zot with HTTPS connections and insecure (self signed certs)
• zot with secure HTTPS (through ngrok)
• dockerhub (secure HTTPS)

Refers to: #2114

[weyfonk]

Thanks for this effort, leaving a few comments :)

[manno]

• respect EXPERIMENTAL_OCI_STORAGE env var