Kamelet file parameters

[nicolaferraro]

Suppose that I want to create a Kamelet that uses this component under the hood.

The component accepts a parameter that is a path that points to some credentials provided as a JSON file by the cloud provider (all Google cloud components behave the same).

Obviously this does not map 1:1 with the current Kamelet model, but I wonder how can we make it fit.

Should we change the component to accept the credentials directly (is it possible?), or make something different?

E.g. we can use a parameter of "type" = "binary" that may indicate this scenario

The CLI + operator can make sure the parameter is e.g. expected to be passed encoded (b64?) in a KameletBinding and the property {{myparam}} can evaluate to the file location at runtime.

This seems a bit too custom as solution. Do you see a better one?
cc: @squakez , @astefanutti , @lburgazzoli , @oscerd , @davsclaus , @christophd

Should we instead define a general encoding of KameletBinding parameters into secrets, so that all properties are eventually stored into files and we can get {{theparam}} value, or {{file:theparam}} file?

[oscerd]

The service account file for google cloud are basically json or p12. We could add a list of options and then create the service account key file on the fly to be used, but it would be a mess in terms of camel options, so for me encoding the kamelet binding parameters into secrets is the best solution.

[lburgazzoli]

To me, this relates to #2003.

Maybe we should define the type of such option as resource and in such case we can store it into a secret/configmap and mount it to a specific resource location (i.e. this would also be useful for ssl related stuffs)

[davsclaus]

Not sure if the component has recently been updated, but I can see that the serviceAccountKey option is both configurable on the component level and in the endpoint.

I like Luca's idea of marking the option as a resource to indicate its something that is loaded as an external resource. And Camel typically support loading via classpath, file, http. We may think about turning off http as you can potentially use a ENV variable override and then load the resource from some malicious external http server.

[oscerd]

Yes, Google storage has that features, the other google cloud components rely on an env variable pointing to service account file

[nicolaferraro]

Would something like this work (apparently json-schema 7 compatible) ?

spec:
  definition:
    title: "Google cloud stuff"
    properties:
      token:
        title: Token
        description: The Token file
        type: string
        contentEncoding: base64
        contentMediaType: "application/json"
        x-camel-type: resource

At the end of the day, the configuration of a Kamelet is a JSON object and need to be validated by the schema. The x-camel-type vendor extension tells us to use the resource type binding at runtime.

Still we need to define how the file location can be accessed at runtime in the kamelet loader.

[lburgazzoli]

do we need the contentEncoding & contentMediaType ? as it is a resource, we know that is should be either a binary config map or a secret so I guess the encoding can be implicit.

With #2003, then will be multiple options to load from a location:

• using an env var, like: google-storage://myCamelBucket?serviceAccountKey={{env:CAMEL_K_RESOURCES:DIR}}/secretName/token
• looking up from the classpath google-storage://myCamelBucket?serviceAccountKey=/secretName/token (the resources location should be part of the classpath, may not work on native)
• extending the ResourceHelper to support serarching on pre-defined locations (so it would be runtime dependant)

[nicolaferraro]

do we need the contentEncoding & contentMediaType ? as it is a resource, we know that is should be either a binary config map or a secret so I guess the encoding can be implicit.

I know it, but the "resource" is "x-camel" specific metadata, while the Kamelet is supposed to tell an user (or a configuration UI) how to build a valid configuration object, without mentioning configmaps or secrets, which are Kubernetes concepts.

With #2003, then will be multiple options to load from a location:

• using an env var, like: google-storage://myCamelBucket?serviceAccountKey={{env:CAMEL_K_RESOURCES:DIR}}/secretName/token
• looking up from the classpath google-storage://myCamelBucket?serviceAccountKey=/secretName/token (the resources location should be part of the classpath, may not work on native)
• extending the ResourceHelper to support serarching on pre-defined locations (so it would be runtime dependant)

The problem is that a Kamelet can be used multiple times in an integration, and so you might have multiple files with a location that is different on each instance of the template. We need something instance-specific on top of the features above...

[lburgazzoli]

I was thinking only about the runtime but yes the contentEncoding and contentMediaType are indeed required for users & UIs.

About the other issue, there are some JIRA to track work that could help:

• https://issues.apache.org/jira/browse/CAMEL-16221
• https://issues.apache.org/jira/browse/CAMEL-16285

[nicolaferraro]

From Camel 3.10 we can use base64:{{theProperty}} in Resource-type fields (property encoded in base64 as described above, no need for x-camel-type).

[nicolaferraro]

Ref: apache/camel#5569