[PR #5] [MERGED] feat(Kubernetes Operator): Move API Key from Pod Spec to Secret #38

New issue

Closed

opened 2026-10-18 21:13:41 +00:00 by bsakaguchi · 0 comments

bsakaguchi commented

2026-10-18 21:13:41 +00:00

Owner

📋 Pull Request Information

Original PR: https://github.com/open-webui/terminals/pull/5
Author: @james-westbrook
Created: 3/20/2026
Status: ✅ Merged
Merged: 3/20/2026
Merged by: @tjbck

Base: main ← Head: fix-k8s-backend-api-key-secret

📝 Commits (1)

f9000a1 fix: update Kubernetes backend to store API key as secret

📊 Changes

1 file changed (+43 additions, -11 deletions)

View changed files

📝 terminals/backends/kubernetes.py (+43 -11)

📄 Description

Description

Store terminal API keys in Kubernetes Secrets instead of plain pod env vars

Moves the per-terminal OPEN_TERMINAL_API_KEY from a literal value in the pod spec to a Kubernetes Secret referenced via secretKeyRef. This aligns the Kubernetes backend with the existing pattern in the Kubernetes Operator backend, which already stores API keys in Secrets (_build_secret_manifest / _read_api_key_from_secret).

Problem

The Kubernetes backend embedded API keys directly in pod env vars, making them visible to anyone with kubectl describe pod access, which is a lower permission bar than reading Secrets. There is already a working pattern for the Kubernetes Operator to store the API key as a secret; this PR uplifts the Kubernetes backend implementation to match this more secure configuration.

Changes

provision() — creates a {name}-apikey Secret before the Pod, injects the key via V1EnvVarSource(secret_key_ref=...) instead of a literal value
teardown() — deletes the Secret alongside the Pod and Service on teardown
reconcile() — reads the API key from the Secret (read_namespaced_secret) instead of extracting it from pod.spec.containers[].env[].value, which is empty for secretKeyRef references

Consistency with Operator backend

Aspect	Operator backend (existing)	Kubernetes backend (this PR)
Secret naming	`{name}-apikey`	`{name}-apikey`
Secret key	`api-key`	`api-key`
Pod env injection	`secretKeyRef`	`secretKeyRef`
Reconcile reads from	`read_namespaced_secret`	`read_namespaced_secret`

Contributor License Agreement

By submitting this pull request, I confirm that I have read and fully agree to the Contributor License Agreement (CLA), and I am providing my contributions under its terms.

Note

Deleting the CLA section will lead to immediate closure of your PR and it will not be merged in.

_{🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.}

## 📋 Pull Request Information **Original PR:** https://github.com/open-webui/terminals/pull/5 **Author:** [@james-westbrook](https://github.com/james-westbrook) **Created:** 3/20/2026 **Status:** ✅ Merged **Merged:** 3/20/2026 **Merged by:** [@tjbck](https://github.com/tjbck) **Base:** `main` ← **Head:** `fix-k8s-backend-api-key-secret` --- ### 📝 Commits (1) - [`f9000a1`](https://github.com/open-webui/terminals/commit/f9000a1e335f51e49fbaf5250c145aa339e42eb6) fix: update Kubernetes backend to store API key as secret ### 📊 Changes **1 file changed** (+43 additions, -11 deletions) <details> <summary>View changed files</summary> 📝 `terminals/backends/kubernetes.py` (+43 -11) </details> ### 📄 Description ## Description **Store terminal API keys in Kubernetes Secrets instead of plain pod env vars** Moves the per-terminal `OPEN_TERMINAL_API_KEY` from a literal `value` in the pod spec to a Kubernetes Secret referenced via `secretKeyRef`. This aligns the Kubernetes backend with the existing pattern in the Kubernetes Operator backend, which already stores API keys in Secrets (`_build_secret_manifest` / `_read_api_key_from_secret`). ### Problem The Kubernetes backend embedded API keys directly in pod env vars, making them visible to anyone with `kubectl describe pod` access, which is a lower permission bar than reading Secrets. There is already a working pattern for the Kubernetes Operator to store the API key as a secret; this PR uplifts the Kubernetes backend implementation to match this more secure configuration. ### Changes - **`provision()`** — creates a `{name}-apikey` Secret before the Pod, injects the key via `V1EnvVarSource(secret_key_ref=...)` instead of a literal value - **`teardown()`** — deletes the Secret alongside the Pod and Service on teardown - **`reconcile()`** — reads the API key from the Secret (`read_namespaced_secret`) instead of extracting it from `pod.spec.containers[].env[].value`, which is empty for `secretKeyRef` references ### Consistency with Operator backend | Aspect | Operator backend (existing) | Kubernetes backend (this PR) | |---|---|---| | Secret naming | `{name}-apikey` | `{name}-apikey` | | Secret key | `api-key` | `api-key` | | Pod env injection | `secretKeyRef` | `secretKeyRef` | | Reconcile reads from | `read_namespaced_secret` | `read_namespaced_secret` | --- ## Contributor License Agreement  - [x] By submitting this pull request, I confirm that I have read and fully agree to the [Contributor License Agreement (CLA)](./CLA.md), and I am providing my contributions under its terms. > [!NOTE] > Deleting the CLA section will lead to immediate closure of your PR and it will not be merged in. --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>

bsakaguchi

2026-10-18 21:13:41 +00:00