Provide the openai credentials to the chatbot application as a secret

[cmoulliard]

TODO

Provide the openai credentials to the chatbot application as a secret

[cmoulliard]

a secret

Can the secret be provided as backstage parameter from app-config.yaml ? @iocanel

[iocanel]

a secret Can the secret be provided as backstage parameter from app-config.yaml ? @iocanel

Given, that we don't want the secret to end up in the application source repository I don't think that backstage itself should be involved. For now, I would be happy if the secret was created manually once and then just have the template use it.

[cmoulliard]

Given, that we don't want the secret to end up in the application source repository I don't think that backstage itself should be involved

If you use locally app-config.local.yaml, then the password/token/secret is not at all stored under a github repository

[cmoulliard]

For now, I would be happy if the secret was created manually once and then just have the template use it.

Will the user provide the openai token using a template parameter ?

[iocanel]

Having the openai token in backstage has no practical use to us. The token needs to somehow end up in a secret. I don't see how backstage could help us here, unless it does provide actions to create a secret.

[cmoulliard]

Can you then confirm or amend the following scenario to be implemented ?

• A user creates a Quarkus Chatbot application using the Quarkus Rest Client template
• During the process to collect the user's input we will use a new parameter openai token to gather the openai token to be used by the Quarkus application
• A kubernetes secret will be created using backstage fetch:template
• The secret will be mounted as env var to the Deployment resource created by the helm chart

Such a scenario should then fix the following error which happens when we launch the chatBot

Caused by: io.smallrye.config.ConfigValidationException: Configuration validation failed:
    SRCFG00014: The config property quarkus.langchain4j.openai.api-key is required but it could not be found in any config source
    at io.quarkiverse.langchain4j.openai.runtime.OpenAiRecorder.chatModel(OpenAiRecorder.java:47)
    at io.quarkus.deployment.steps.OpenAiProcessor$generateBeans801072037.deploy_0(Unknown Source)
    at io.quarkus.deployment.steps.OpenAiProcessor$generateBeans801072037.deploy(Unknown Source)

@iocanel

[iocanel]

I don't see how a kubernetes secret can be create it with fetch:template without having the secret end up in the git repository. All an in all, I am not aware of any way of creating arbitrary resources on kubernetes without adding them to the repo.

So, I think that the secret needs to be configured up front and maybe let the user specify the name of the secret in the template.

[cmoulliard]

I don't see how a kubernetes secret can be create it with fetch:template without having the secret end up in the git repository.

Correct. There are until now only a few kubectl actions able to create resources from a backstage template:

• kubernetes:create-namespace: https://github.com/janus-idp/backstage-plugins/blob/main/plugins/kubernetes-actions/src/actions/createKubernetesNamespace.ts#L112
• cnoes:kubernetes-apply: https://github.com/cnoe-io/plugin-scaffolder-actions/blob/main/src/actions/k8s-apply.ts#L17

Ideally we should use an external secrets store as vault. Maybe this backstage backend plugin could help us but I need to have a look to see how a secret defined in a component can be next consumed by an application: https://www.npmjs.com/package/@backstage-community/plugin-vault-backend.

A better option is certainly to use Primaza as it allows to use vault as secret storage engine and mount to the target Deployment resource the secret created after we did a query in vault to find the key, credentials, etc.

Finally, this is what we should do

• A user creates a Runtime application (Quarkus, SpringBoot, Nodejs, Python, etc) using a backstage template
• Such a runtime requires a secret/token/password stored under a secrets store (vault, etc) according to the a key name. Such a key (or composite key) should match the Application property (e.g: app.datasource.jdbc-url, app.datasource.username, app.datasource.password, etc)
• The Component YAML is enriched with an annotation of the secret key path
• A platform engineer is notified about the request "Application x.y.z needs the following key path to access a secret (token, password/etc"
• The platform engineer creates under the secrets store the key path
• A 3rd party application able to scan the Component YAML file, check if there is a secret path, query the secret store, create a kubernetes secret.
• Next, the 3rd party application update the Deployment resource to add as envVar the secret -> key and push it to git if argocd is used

[cmoulliard]

An intermediate approach could be to use the devtools plugin (or to create a module for such a purpose) able to expose the the config parameters as endpoint from the backstage config if we agree to store such a AI token there of course and to use a scaffold customField where value is filled from the API call to the config endpoint (to be developed).

Some useful links:

• Devtool code exposing the config: https://github.com/backstage/backstage/blob/master/plugins/devtools-backend/src/service/router.ts#L91-L106
• Roadie code fetching values from API call: https://github.com/RoadieHQ/roadie-backstage-plugins/blob/main/plugins/scaffolder-field-extensions/scaffolder-frontend-module-http-request-field/src/components/SelectFieldFromApi/SelectFieldFromApi.tsx#L62