Add Secrets CRUD
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 flagsecrets-vault.- Vault integration: New shared
vaultclient (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.secretstable (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), andVAULT_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 intostart-services.- Env templates:
.env.templateadds Vault-related vars.- Dependencies:
- Add
github.com/hashicorp/vault-client-go,go-retryablehttp,go-secure-stdlib/strutil,ryanuber/go-globand related sums.Written by Cursor Bugbot for commit 027e290ab4e5632645e672866354f097d013a9d8. This will update automatically on new commits. Configure here.
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
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.