Decoupling deployers from OCM

[mandelsoft]

How to categorize this issue?

/area deployers
/area control-plane
/kind api-change
/priority 2

What would you like to be added:

The landscaper core service provides a REST API for deployers to access OCM resources resources
described in the deployitem. The templating engine provides function to request such resources and to
substitute the appropriate access information in the generated deploy item(s).

Why is this needed:

There are several scenarios a deployer has to access resources described by an OCM component version:

1. the resource has a global access method (is addressable in a technology specific manner from a repository
   reachable independently from the OCM repository containing the component version describing this resource)

   This is typically use to access resources from the environment the deployment is fed into from the deployer (for example images)
   The content can be access from the deployer as well as by the runtime environment just using the provided
   resource location (for example image name). In the latter case the deployer just forwards the location information
   and does not need access to the resource content content. In the first case (if really required), the deployer can use the
   technology-specific (and OCM agnostic) access to the externally available resource.

2. The resource is described by a component-version-local access method and is therefore only accessible via the OCM
   model support.

   In this scenario, the deployer always needs access to the content of the resource:

   • either to consume it by its own (for example to process a helm chart) or
   • or to publish it to a technology-specific repository accessible in a technology-specific manner from the deployment target
     environment and pass this location to the finally deployed resources.

The second scenario is currently solved by passing the OCM model information to the deployer and the deployer accesses the
content directly from the OCM repository. THis is required because those content might potentially quite large and cannot be passed inlined in the deploy item.

This means:

• those deployers have to be aware of the OCM model, they do NOT work on the deploy item, only.
• they depend on the OCM support library and they require all the credentials to access the OCM repository as well as the
  content potentially stored in another repository.

Those dependencies should strictly be avoided. Especially the required credentials are problematic because the landscaper is to forward its own credentials to the deployers, but it does not formally know, which of the credentials are really required for
intended access. The deployer should gain access for the resources passed by the deploy item, only.

Solution Proposal:

The landscaper always requires access to the described resources, because it must potentially be able to provide access to the content to the templating engines.

The OCM model and credentials should never be exposed to the deployers, the deployer model should not be interwoven with the OCM model. Therefore, there must be a way to provide access to the content in a generic way. This could be a web server which provides resource content identified by an own resource path model, and which provides a fine-grained access control for dedicated resources. The deploy item contains the appropriate URLs and access credentials for the explicitly requested resources (by the templating,), only. The deployer the uses this information to gain a streamed access to the resource content.

The task of the landscaper is then to provide an appropriate access URL and credentials for a requested OCM resource, which can then be embedded into the generated deploy item by the blueprints templates.

For example: template function: accessResource(resource identity) -> struct
where the result describes two fields: URL and accessToken (credentials),

At the same time it registers this access path at the web server frontend. It provides a book keeping of the requested resources and is able to remove the access again, when a resource is not required, anymore.

The web server could be part of the landscaper operator (may be a second container) or a completely different pod (which requires an additional registration API).

Both parts, the web server and the landscaper operator need access to the same OCM configuration, may be a better solution is to add the server part to the operator)

The web server could directly stream the content of the resources from the OCM api, or it could mirror the content on a local disk.

An important feature would be the token handling to control access to the resources. The tokens MUST survive restarts of pods and should therefore not stored in memory but not on disk, also. In best case they should be derivable from the OCM resource identity in an idempotent way, but this way MUST NOT be reproducible by third parties.

This could be achieved by signing the resource identity using private key only known by the landscaper operator.
The signature is the token passed to deploy items.

The server can than verify the signature using the public key for the requested resource identity to control the access to dedicated resources.

Because the deployers may not only run in the same K8S cluster than the ölandscaper operator/web server, the access must be possible from the outside of the cluster. This should not be a severe problem, because of the used access control to the resources.