Conflict Between websocket.url and WEBSOCKET_REDIS_URL in open-webui-10.2.0 Helm Chart

[blegry]

Description:

There is a conflict in the open-webui-10.2.0.tgz Helm chart between the websocket.url value and the custom environment variable WEBSOCKET_REDIS_URL, which contains a secret and cannot be committed to the repository. The WEBSOCKET_REDIS_URL is sourced from a secret (valueFrom.secretKeyRef).

Explanation:

The issue arises in the following section of the Helm chart:

{{- if .Values.websocket.enabled }}
- name: "ENABLE_WEBSOCKET_SUPPORT"
  value: "True"
- name: "WEBSOCKET_MANAGER"
  value: {{ .Values.websocket.manager | default "redis" | quote }}
- name: "WEBSOCKET_REDIS_URL"
  value: {{ .Values.websocket.url | quote }}
{{- end }}

The WEBSOCKET_REDIS_URL environment variable is hardcoded to use the websocket.url value, which does not allow for the use of secrets. This is problematic because WEBSOCKET_REDIS_URL should be able to pull its value from a secret, similar to how other sensitive environment variables are handled in the chart.

Proposal:

To resolve this issue, we should conditionally include either the websocket.url value or the WEBSOCKET_REDIS_URL environment variable from a secret. This approach ensures that the secret is properly managed and not exposed in the Helm values file.

Here's the proposed change:

{{- if .Values.websocket.enabled }}
- name: "ENABLE_WEBSOCKET_SUPPORT"
  value: "True"
- name: "WEBSOCKET_MANAGER"
  value: {{ .Values.websocket.manager | default "redis" | quote }}
{{- if .Values.websocket.url }}
- name: "WEBSOCKET_REDIS_URL"
  value: {{ .Values.websocket.url | quote }}
{{- else }}
- name: "WEBSOCKET_REDIS_URL"
  valueFrom:
    secretKeyRef:
      name: {{ .Values.websocket.existingSecret | default "websocket-secret" | quote }}
      key: {{ .Values.websocket.secretKey | default "redis-url" | quote }}
{{- end }}
{{- end }}

This change will allow users to either specify the websocket.url directly in the values file or use a secret, providing flexibility and better security management.

Please review the proposed changes and let me know if you need any further adjustments or additional information.

[blegry]

Extension Suggestion:

This approach could be extended to other sensitive keys such as OPENAI_API_KEY and OPENAI_API_KEYS to ensure consistent and secure handling of secrets across the Helm chart. By applying a similar conditional logic, we can enhance the security and flexibility of managing sensitive environment variables.

Example for OPENAI_API_KEY:

{{- if .Values.openaiApiKey }}
- name: "OPENAI_API_KEY"
  value: {{ .Values.openaiApiKey | quote }}
{{- else }}
- name: "OPENAI_API_KEY"
  valueFrom:
    secretKeyRef:
      name: {{ .Values.openai.existingSecret | default "openai-secret" | quote }}
      key: {{ .Values.openai.secretKey | default "api-key" | quote }}
{{- end }}

However, this is not an issue for this environment variable because it already supports double values and is managed at the image level. The current implementation allows for both direct values and secrets, as shown in the example below:

            - name: OPENAI_API_BASE_URL
              value: https://api.openai.com/v1
            - name: OPENAI_API_KEY
              value: 0p3n-w3bu!
            - name: OPENAI_API_KEYS
              valueFrom:
                secretKeyRef:
                  key: api-keys
                  name: secret
            - name: OPENAI_API_BASE_URLS
              value: "http://internal.url.com;http://anotherInternal.url.com"

This would simplify the understanding and maintenance of the Helm chart, while reducing exceptions managed at lower levels. Having a single high-level value for sensitive configurations would allow for more consistent and secure secret management, making the code more readable and easier to maintain. It would also avoid potential conflicts and confusion related to managing secrets at different levels.

[flefevre]

This modification could enhance the security level by allowing the usage of secret for kuberntes.
Thanks for the proposal.