lab/automation
1
0
Fork 0
Code Issues 6 Pull requests 3 Projects Releases Packages Wiki Activity Actions

Per-project Harbor robots via VSO #13

New issue
Open
opened 2026-09-22 19:42:19 +00:00 by ginjiruu · 0 comments
ginjiruu commented 2026-09-22 19:42:19 +00:00
Owner
Copy link

What to build

Retire the PoC admin Harbor account in favor of per-project robot accounts:

  1. The onboarding workflow creates a per-project Harbor robot account (scoped to the project's image repository) and writes its credentials to Vault under a per-repo path convention.
  2. The scaffold's .ci/ carries per-app VaultAuth + VaultStaticSecret (the ADR-0004 shape, bound to the CI service account in the ci namespace), materializing the docker config.json as a native Secret.
  3. The build workflow pushes with the robot account; the admin ExternalSecret is removed from the ci namespace.

External dependencies: the Vault Secrets Operator must be deployed on mini (lab/clusters #1524), and the Vault kubernetes auth backend + per-app roles must exist (a lab/iac follow-on explicitly out of #1524's scope).

Acceptance criteria

  • Onboarding creates a Harbor robot scoped to the project's image repository
  • The Vault secret exists under the per-repo path convention
  • The VaultAuth/VaultStaticSecret in .ci/ materialize the docker config.json Secret in the ci namespace
  • A build pushes with the robot account (verifiable in Harbor)
  • The admin ExternalSecret is removed from the ci namespace

Blocked by

  • #10 — Onboarding flow: repo-created → scaffold PR + factory PR + cluster resources
  • lab/clusters #1524 — Deploy the Vault Secrets Operator across clusters (external)
  • lab/iac — Vault kubernetes auth backend + per-app roles (external, follow-on to #1524)
## What to build Retire the PoC admin Harbor account in favor of per-project robot accounts: 1. The onboarding workflow creates a per-project Harbor robot account (scoped to the project's image repository) and writes its credentials to Vault under a per-repo path convention. 2. The scaffold's `.ci/` carries per-app `VaultAuth` + `VaultStaticSecret` (the ADR-0004 shape, bound to the CI service account in the `ci` namespace), materializing the docker config.json as a native Secret. 3. The build workflow pushes with the robot account; the admin ExternalSecret is removed from the `ci` namespace. External dependencies: the Vault Secrets Operator must be deployed on mini (lab/clusters #1524), and the Vault kubernetes auth backend + per-app roles must exist (a lab/iac follow-on explicitly out of #1524's scope). ## Acceptance criteria - [ ] Onboarding creates a Harbor robot scoped to the project's image repository - [ ] The Vault secret exists under the per-repo path convention - [ ] The `VaultAuth`/`VaultStaticSecret` in `.ci/` materialize the docker config.json Secret in the `ci` namespace - [ ] A build pushes with the robot account (verifiable in Harbor) - [ ] The admin ExternalSecret is removed from the `ci` namespace ## Blocked by - #10 — Onboarding flow: repo-created → scaffold PR + factory PR + cluster resources - lab/clusters #1524 — Deploy the Vault Secrets Operator across clusters (external) - lab/iac — Vault kubernetes auth backend + per-app roles (external, follow-on to #1524)
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
master
issue-9-central-allowlist
bridge-moodle-exporter
bridge-ghost-blog
bridge-advent-of-code-2015
bridge-gofantasy
0.0.1
Labels
Clear labels   
ready-for-agent
No labels
ready-for-agent
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
lab/automation#13
No description provided.