Repository navigation
fix(apps): user secrets (e.g. HF_TOKEN) are written in plain text into the uploaded build manifest - #698
Open
deanq wants to merge 5 commits into
Open
fix(apps): user secrets (e.g. HF_TOKEN) are written in plain text into the uploaded build manifest#698deanq wants to merge 5 commits into
deanq wants to merge 5 commits into
Conversation
Deploy wrote every resource's env, literal values included, into the manifest it uploads and packs into the build artifact. - Queue and API env is checked against reserved names, then left out of the manifest. Endpoints get their env from the endpoint template. - Task env stays in the manifest sent to the backend, which launches deployed task pods from it. - The packaged runpod_manifest.json carries no env for any resource. - Warn when a secret-looking env name (*_TOKEN, *_KEY, *_SECRET, *_PASSWORD) has a literal value, pointing to runpod.Secret. SLS-994
Contributor
|
bugbot run |
There was a problem hiding this comment.
🟢 Approval recommended
No active review issues remain for the changes aimed at reducing literal-secret exposure in deployment manifests.
No open issues 🎉
What changed in this PR
This PR reduces exposure of literal environment secrets in deployment manifests while preserving how workers receive their environment values.
Changes:
- Removes queue and API environment values from uploaded manifests, retaining reserved-name validation and task environment values needed by the backend.
- Strips all resource environment values from the packaged manifest without modifying the caller’s manifest.
- Warns about secret-looking literal environment values without logging their contents, with regression tests for filtering and warnings.
| File | Description |
|---|---|
tests/test_apps/test_deploy.py |
Adds coverage for environment filtering, task retention, reserved names, packaging, and secret warnings. |
runpod/apps/deploy.py |
Filters manifest environment values and warns about secret-looking literals. |
Review effort: Balanced
KAJdev
requested changes
Nov 9, 2026
Endpoint env was serialized into the manifest entry and then popped back out. Build the entry without it instead, via a new include_env flag on ResourceSpec.to_manifest, and validate the reserved keys from the spec. Behavior is unchanged: endpoints carry no env in the manifest, task env still goes to the backend.
This branch has not been deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
rp flash deploywrote every resource'senvinto the build manifest, including literal values such asenv={"HF_TOKEN": os.environ["HF_TOKEN"]}. That manifest is sent to the backend when the build is finalized, and also packed into the artifact asrunpod_manifest.json. Neither copy needs the endpoint values.Changes:
envis still checked against reserved names, then left out of the manifest. Endpoints already get their env from the endpoint template, so workers see the same values.envstays in the manifest sent to the backend, because the backend launches deployed task pods from it.runpod_manifest.jsonhas noenvfor any resource. Nothing reads env from that file._TOKEN,_KEY,_SECRETor_PASSWORDhas a literal value, and points torp secret addplusrunpod.Secret(...). The warning names the variable, never the value.Why this shape
runpod.Secretvalues were already sent as references, so only literal values were affected. Literal values still have to reach the endpoint template or task definition, which is where they're used. The warning steers secret-looking values torunpod.Secret, the only way to keep a value out of those definitions.Test plan
tests/test_apps/test_deploy.py:runpod.Secretvalues and ordinary names don't warnmake quality-check(2783 passed)DEMO_TOKENandMODE. The CLI printed the warning, the worker returned both values, and the stored build manifest did not contain the literal value. A deploy of the same app from unfixed code stored the value in the manifest.