Add Secrets CRUD

[Code42Cate]

WIP

This is still WIP and requires https://github.com/e2b-dev/belt/pull/200 to be merged and deployed.

Adds vault client + basic CRUD routes for secrets. Not integrated into hot path of sandbox create yet.

Still working on some observability stuff

---

Note

Adds Secrets CRUD API backed by HashiCorp Vault, including DB table/queries, feature flag/config, IaC wiring, and CI setup with a dev Vault.

• API/Backend:
  • Secrets CRUD: New endpoints GET/POST /secrets, PATCH/DELETE /secrets/{secretID} with validation (hostname allowlist, sizes) and feature flag secrets-vault.
  • Vault integration: New shared vault client (AppRole auth, token renewal, KV v2 ops) and API config/env support: VAULT_ADDR, VAULT_APPROLE_ROLE_ID, VAULT_APPROLE_SECRET_ID, VAULT_TLS_CA.
  • Spec/Codegen: OpenAPI updated; generated server/client/types include Secret, NewSecret, UpdateSecret, routes registration; logging/metrics middleware includes /secrets.
  • Tests: Unit tests for hostname validation; extensive integration tests for listing/creating/updating/deleting secrets and team access control; minor test utils ctx fixes.
• Data layer:
  • Migration: New public.secrets table (RLS enabled) with indices; sqlc queries for create/get/update/delete.
• Infrastructure/IaC:
  • Nomad/Jobs: API job exports VAULT_ADDR, AppRole creds (from GCP Secret Manager), and VAULT_TLS_CA.
  • Terraform: New variables/secret names for Vault creds/CA; wire secret versions and pass into API job template.
• CI/Dev tooling:
  • GitHub Actions: Start Vault dev container with AppRole, policy, and env export (.github/actions/start-services/start-vault.sh) integrated into start-services.
  • Env templates: .env.template adds Vault-related vars.
• Dependencies:
  • Add github.com/hashicorp/vault-client-go, go-retryablehttp, go-secure-stdlib/strutil, ryanuber/go-glob and related sums.

^{Written by Cursor Bugbot for commit 027e290. This will update automatically on new commits. Configure here.}

[Code42Cate]

My integration tests don’t really clean up after themselves, but it seems like the existing ones don’t either. Was that intentional, or just something that never got done? If it wasn’t intentional, I’ll add cleanup to my tests. @ValentaTomas

[sitole]

My integration tests don’t really clean up after themselves, but it seems like the existing ones don’t either. Was that intentional, or just something that never got done? If it wasn’t intentional, I’ll add cleanup to my tests. @ValentaTomas

Integration tests are executed on an environment that is cleaned after that, so there is no need for cleanup except if you are expecting that some messy tests can cause interference with other tests in the same run.