lablup / lablup/backend.ai

Reference secrets from deployment revisions

Open
#13,986 0 comments 0 reactions 0 assignees View on GitHub
Dominant language
Python
Stars
670
Forks
183
Avg merge
15h 13m
Merged PRs (30d)
368

Description

Implements phase 3 of BEP-1074 (proposals/BEP-1074-container-secret-references.md). Depends on the session bindings.

Opens secret_bindings to deployment revisions and carries a revision's bindings into the sessions its replicas run as. Because a binding pins a version, replicas of one revision hold the same value whenever they started, and activating an older revision returns that revision's values.

Commit split for review:
1. Revision create and read APIs
2. Revision to session binding carry-over, and pruning cleanup

Key design points:
- Adding a revision is always a complete new create request. The UI reads the current revision to fill the form and resubmits the whole spec. Since it cannot read values, the origin name and version number take their place in the read response.
- Do not add a carry-over rule that pulls a secret the request omitted from the previous revision. The user names the origin again, which is what keeps the request self-describing.
- Leave _resolve_environ alone: secrets do not travel the environ path. Copy the revision's bindings into the session draft so the session owns its own bindings and the delivery path added in phase 2 only ever reads session bindings.
- Copy the version id verbatim. Do not resolve it again; the version the revision pinned is the one that must be used.
- Revision pruning deletes bindings along with the revision.
- Name collision validation is reused from phase 2.

See the draft for the full file and feature tables: drafts/BEP-1074-container-secrets/issues.md

Success Criteria
- [ ] Naming a secret when adding a revision records the version that was latest at that moment
- [ ] A revision read answers with environment variable names and origins, never values
- [ ] Changing a secret value leaves existing revision bindings untouched
- [ ] No secret appears in deployment_revisions.environ
- [ ] The environment variable holds the named secret inside a deployment replica container
- [ ] Replicas of one revision hold the same value however many times they are recreated
- [ ] Activating an older revision injects the values of that revision's pinned versions
- [ ] Pruning a revision leaves no binding behind
- [ ] pants test passes for affected packages

JIRA Issue: BA-7497

Contributor guide

Open the contributing guide

Research direction

Read proposals/BEP-1074-container-secret-references.md and drafts/BEP-1074-container-secrets/issues.md first, then trace the phase 2 session-binding implementation and the deployment revision create, read, and pruning entry points. Use the success criteria to verify pinned versions, value-free reads, session carry-over, cleanup, and the affected-package pants tests.

Written by the indexing model from the issue text.

Assessment

Tech stack
docker, python
Domain
api, backend, security
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Active
Clarity
Mostly clear
Newbie friendliness
45/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.