Use secrets with KameletBindings

[k0pper]

According the the Kamelets User Documentation, a way (3rd one) to configure your Kamelets is to

1. define a property file
2. create a secret using this property file
   kubectl create secret generic my-company-log-sink.mynamedconfig --from-file=mynamedconfig.properties
3. bind the kamelet to the secret
   kubectl label secret my-company-log-sink.mynamedconfig camel.apache.org/kamelet=my-company-log-sink camel.apache.org/kamelet.configuration=mynamedconfig
4. write an integration file that uses the Kamelet with the config

from('timer:tick')
  .setBody().constant('Hello')
  .to('kamelet:my-company-log-sink/mynamedconfig')

Right now, I have to hard-code needed (confidential) properties into the KameletBinding:

my-binding.kamelet.yaml

...
  sink:
    ref:
      kind: Kamelet
      apiVersion: camel.apache.org/v1alpha1
      name: my-telegram-sink
    properties:
      authorizationToken: "abcdefg"
      chatId: "123456"
...

Is there also a way of referencing the config in a KameletBinding? I don't want to use java routes only to be able to use secret-based configuration. Something like this:
my-binding.kamelet.yaml

...
  sink:
    ref:
      kind: Kamelet
      apiVersion: camel.apache.org/v1alpha1
      name: my-telegram-sink
      config: mynamedconfig
...

[oscerd]

You can do something like this:
https://github.com/apache/camel-k-examples/tree/main/kamelets/aws-s3-to-log-with-secret

[k0pper]

Exactly the solution I needed, works flawlessly! Thank you.

Is there a possibility including this in the documentation? I'm using Kamelets in an Enterprise context and this seems like a common use case because:

1. It simplifies the life of the Kamelet-User. The developer creates complex Kamelets with his Camel DSL knowledge and configures needed secrets, and the user just uses the Kamelets with just referencing the secret in the Binding. The user also has the flexibility of not using the secret and configuring own properties.

2. The goal, at least for us, is to write as little code as possible, that's why a configuration section for KameletBindings could be extremely useful

[nicolaferraro]

It's also possible to use auto-secrets in KameletBindings, like you do in java routes. The place you put the configuration name is in the special id property. Something like this should work:

# ...
  sink:
    ref:
      kind: Kamelet
      apiVersion: camel.apache.org/v1alpha1
      name: my-company-log-sink
    properties:
      id: mynamedconfig # The special "id" property links the binding to the secret you defined above

We should document this. There's an example in the e2e tests: https://github.com/apache/camel-k/tree/92c860599760f8d74c63c5f71e689e0a7b374438/e2e/yaks/common/kamelet-binding-autoload

The only problem of the solution described by @oscerd is that those properties become global in the KameletBinding, so any Kamelet in the binding that has e.g. and "authorizationToken" parameter gets the global value, while the secret autoload strategy does not suffer from this issue.

[oscerd]

I forgot to mention what @nicolaferraro said, we need to document it a bit better.

[k0pper]

@nicolaferraro This is an even better solution. This way I can configure every sink and source separately. For instance when I have a telegram sink and source that need to be connected.

Just to bundle the solution into one reply, how to use auto-secrets in KamelBindings:

1. create a secret using this property file

kubectl create secret generic telegram-secret --from-literal=authorizationKey=myauthkey --from-literal=chatId=myChatId<secretKey>

2. link the kamelet that needs the secret to the secret (--overwrite if secret already exists)

kubectl label secret telegram-secret camel.apache.org/kamelet=my-telegram-sink camel.apache.org/kamelet.configuration=telegram-secret --overwrite

3. use it like @nicolaferraro suggested:

# ...
  sink:
    ref:
      kind: Kamelet
      apiVersion: camel.apache.org/v1alpha1
      name: my-telegram-sink
    properties:
      id: telegram-secret # The special "id" property links the binding to the secret you defined above