Teleport: make sidecar resource labels configurable
Problem
The Teleport sidecar hardcodes the labels it puts on the db and app resources it creates: dblab: "true", environment: <environment-id>, clone_id, and optionally dblab_user. The environment label is doing two jobs at once:
- Internal ownership - the reconcile loop finds "its own" resources with
dblab == "true" && environment == <environment-id>, so the value must be unique per DBLab instance. - Access control - operators whose Teleport roles grant DB/app access by label expect
environmentto follow their own taxonomy (a value shared across instances), plus extra keys likeserviceanddb-type.
These requirements conflict. An operator can't repoint environment to match their roles without breaking per-instance reconciliation, and the hardcoded labels don't match roles that gate on other keys, so the bot identity ends up with access to db/app denied.
Solution
Decouple the two concerns and make the operator-facing labels configurable (branch teleport/configurable-resource-labels):
- Add
--label key=value(repeatable, env varTELEPORT_LABELS) so operators attach arbitrary labels to everydb/appresource, matching their existing Teleport taxonomy. - Move per-instance ownership to a dedicated
dblab_instance: <environment-id>label. Reconcile filters on that instead ofenvironment, soenvironmentis free for operator use. - Reserved keys (
dblab,dblab_instance,clone_id,dblab_user) are validated and rejected at startup. - Backward compatible:
environmentstill defaults to<environment-id>when no custom value is given, and the reconcile filter keeps a legacy fallback so resources created beforedblab_instanceexisted are still recognised.
Example:
dblab teleport serve --environment-id <unique-instance-id> \
--label environment=prod \
--label db-type=main \
--label service=dblabA role can then gate on the stable labels with the rest as wildcards:
db_labels:
service: ["dblab"]
environment: ["*"]
db-type: ["*"]
app_labels:
service: ["dblab"]
environment: ["*"]
db-type: ["*"]Note: Teleport requires the resource to carry every label key a role names. If a role lists a key the sidecar doesn't set (e.g. writable), add it with --label writable=readwrite, otherwise access is denied.
Docs updated in engine/cmd/cli/commands/teleport/SETUP.md.