docs(arch): принцип секретов подресурсов — в TOOLS/ARCHITECTURE.md
Записал в ОБЩИЙ файл архитектуры (TOOLS/ARCHITECTURE.md, PRIMARY SOURCE OF TRUTH): - раздел «Subresource-born secrets» в Subresource Resources — проблема, принцип, правило «service-specific DATA, never logic», факт postgres vs mariadb; - пункт 3 в Exception Registry — как объявлять признак в YAML-спеке и прокидывать через types.go + loader.go, без svc.Name == "..." в шаблоне. В provider_philosophy.md оставлена короткая ссылка на ARCHITECTURE.md (источник один).
This commit is contained in:
@@ -203,6 +203,30 @@ resource "nubes_postgres_user" "user1" {
|
||||
role = "app_user"
|
||||
}
|
||||
|
||||
#### Subresource-born secrets (principle)
|
||||
|
||||
Some `create_user` operations generate a password on the platform side and store it
|
||||
in the PARENT instance's `vault_secrets`; the subresource's `Create` does not read it
|
||||
back, and the parent's `vault_secrets` (Computed) refreshes only on `Read`. Result: in a
|
||||
single `apply`, the password is unavailable right after `create_user` (accessing
|
||||
`vault_secrets["users"]` fails with `Invalid index`).
|
||||
|
||||
**Principle:** a secret born in a subresource operation must become an OUTPUT of that
|
||||
subresource at the end of its `Create`; consumers read `nubes_<svc>_<sub>.<password>`,
|
||||
never the parent's `vault_secrets`.
|
||||
|
||||
**Rule:** this is service-specific DATA, never logic (see Exception Registry below):
|
||||
the flag «user password is platform-generated, decrypt from parent vault, secret name X»
|
||||
comes from the service YAML spec, exactly like `suspend_on_destroy_default`. The shared
|
||||
subresource template (`TOOLS/resource-generator/internal/templates/subresource.go`) only
|
||||
adds a conditional block gated on that flag — no service name is hardcoded there.
|
||||
|
||||
Per-service fact (from specs):
|
||||
- PostgreSQL (`90_postgres.yaml`): `create_user` has NO `password` input → password is
|
||||
platform-generated into `vault_secrets["users"]` → NEEDS the output.
|
||||
- MariaDB (`115_mariadb.yaml`): `create_user` TAKES `password` as input (sensitive) →
|
||||
the password is already in the manifest (`nubes_mariadb_user.x.password`) → output NOT needed.
|
||||
|
||||
### Redeploy (inline action)
|
||||
|
||||
Services with `redeploy` operation get a `git_revision` field in the main resource.
|
||||
@@ -292,6 +316,13 @@ services. Service-specific deviations are of two kinds:
|
||||
|---|---|---|
|
||||
| `serviceSpecificDocExamples` | `TOOLS/docs-generator/internal/writers/writers.go` | per-service doc examples, gated on service name + required state/vault keys |
|
||||
|
||||
3. **Subresource-born secrets** — a platform-generated user password available only after
|
||||
`create_user` (see «Subresource-born secrets» under «Subresource Resources»). The
|
||||
generator flag «user password is platform-generated; read from parent vault secret X»
|
||||
is declared in the service YAML spec — add the field to the spec's struct in
|
||||
`TOOLS/resource-generator/internal/types/types.go` and wire it in
|
||||
`TOOLS/resource-generator/internal/loader/loader.go`, NOT as `svc.Name == "..."` logic.
|
||||
|
||||
Rules:
|
||||
|
||||
- Key by stable service NAME (slug), never by raw numeric ID.
|
||||
|
||||
Reference in New Issue
Block a user