[KAJdev]

Workers authenticate with a key minted for their app environment (or for the app's dev sessions), never with the developer's own key. The key is stored as a RunPod secret named flash-app-key.<app>.<env> (flash-dev-key.<app> for dev) and every endpoint template references it as {{ RUNPOD_SECRET_... }}, so the platform decrypts it at boot and the value never lands in a template, an env payload, or a log. A resource that sets its own RUNPOD_API_KEY in env keeps it.

The key is minted on the first deploy that needs it and reused after that. Its scopes cover what flash runtime does from a worker: calling and listing endpoints, launching and terminating task pods, resolving volumes, and resolving registry credentials and secrets for task pods. Deleting an environment or an app revokes its key and deletes the secret.

Secrets go through the v2 REST routes. API keys stay on GraphQL because REST has no key routes.

[Copilot]

🟡 Changes recommended

Credential-name collisions and incomplete failure recovery can disrupt other deployments or leave active keys behind.

4 open issues

• Prevent credential name collisions between app/environment pairs · New
• Handle all secret creation failures to prevent orphaned keys · New
• Clean up environment credentials before permanent deletion · New
• Remove dev credentials before deleting the app · New

What changed in this PR

Replaces developer credentials in Flash worker templates with per-app keys stored as RunPod secrets.

Changes:

• Adds credential creation, reuse, and deletion for deployed environments and dev sessions.
• Injects secret references while preserving explicit resource credentials.
• Moves secret operations to REST and adds credential tests.

File	Description
tests/​test_apps/​test_worker_credentials.py	Tests credential lifecycle and worker authentication.
tests/​test_apps/​test_dev.py	Verifies developer keys are not forwarded.
tests/​test_apps/​test_api_client.py	Tests REST secret operations.
runpod/​apps/​manage.py	Adds credential cleanup during deletion.
runpod/​apps/​dev.py	Supplies dev workers with secret references.
runpod/​apps/​deploy.py	Supplies deployed workers with secret references.
runpod/​apps/​app_key.py	Implements credential naming and lifecycle.
runpod/​apps/​api.py	Adds key operations and REST secret access.
runpod/​api/​queries/​apps.py	Adds API-key listing query.
runpod/​api/​mutations/​apps.py	Adds key creation and revocation mutations.

_{Review effort: Balanced}

[deanq]

Previously workers ran on the deployer's own key. Now createApiKeyNew needs the caller to hold API key create permission, and the backend rejects any requested scope outside the caller's grantable set (scoped calling key or restricted org role) with "Scope(s) not grantable by the caller". A user deploying with a scoped key that lacks, for example, volumes:write or authentication:write would now fail every deploy that previously worked. Is that intended, and should the error tell them to set RUNPOD_API_KEY in the resource env instead?

Separately, have these six scopes been exercised end to end from a worker: deployCpuPod / podFindAndDeployOnDemand for task pods, GET /v2/registries for registry auth, DELETE /v2/pods/{id}, volume create, and endpoint resolution plus invocation through the sentinel? The unit tests mock the API, so a missing scope would only show up as a 401/403 inside a worker.