boundary/internal/db/schema/migrations/oss/postgres/99

Vault Generic Credential Library DB Refactor

Historically, the "Vault generic" credential library was named just "Vault" credential library. Over the course of Boundary's development, it was renamed to "Vault generic" to better match its abilities and to conceptually separate it from other Vault-specific credential libraries, however this nomenclature change was not applied to database (or domain) entities. This migration applies this nomenclature change at the database level, renaming all related entities to match the new "Vault generic" name.

Currently, these database entities are either named or prefixed with credential_vault_library. This migration changes them to be named or prefixed with credential_vault_generic_library.

Additionally, credential_vault_library takes on a new meaning and is defined as a new base table that holds information about all Vault-specific credential libraries. credential_vault_library is a subtype table of credential_library:

credential_library |> credential_vault_library |> credential_vault_generic_library
                   |                           |> credential_vault_ssh_cred_library
                   |                           |> any future Vault-specific credential libraries
                   |
In the future, we could also have:
                   |> base table for a non-Vault system's credlibs |> credential library subtype tables

While the history table for Vault generic credential libraries is renamed to credential_vault_generic_library_hst, the overall history design remains unchanged.

This pattern is being established due to the need to differentiate between the systems that Boundary's credential libraries integrate with, for database integrity purposes:

credential_dynamic is a base table that represents all renewable/revokable dynamic credentials. credential_vault_credential is a subtype table that represents renewable/revokable dynamic credentials (Vault leases). Given the specificity of this design, these leases must be obtained by a Vault credential library.

To enforce this, the library_id field in credential_vault_credential has a foreign key constraint on credential_vault_library(public_id), meaning only Vault leases obtained by a Vault generic credential library can ever be inserted into this table and therefore managed by Boundary.

With the future introduction of new Vault credential libraries that can also issue Vault leases, this constraint becomes too restrictive and the design needs to be extended. By redefining credential_vault_library as described above, this refactor provides the backing for this to be done.