ateapi currently connects to PostgreSQL as the postgres superuser. The HBA rule accepts any database and requested role from any client holding a certificate issued by the pod-identity CA. ateapi also applies its embedded schema during startup, coupling normal runtime access with DDL privileges.
|
hostssl all all all trust clientcert=verify-ca |
We should move to least-privilege application roles, but the correct role split depends on the PostgreSQL migration design (tracked separately in #901) which has not yet been established. For example, migrations may need a separate owner / migrator role while the running API server only receives DML privileges. HBA rules also should be restricted appropriately.
#940 (comment)
ateapi currently connects to PostgreSQL as the
postgressuperuser. The HBA rule accepts any database and requested role from any client holding a certificate issued by the pod-identity CA. ateapi also applies its embedded schema during startup, coupling normal runtime access with DDL privileges.substrate/manifests/ate-install/postgres.yaml
Line 34 in 517e48e
We should move to least-privilege application roles, but the correct role split depends on the PostgreSQL migration design (tracked separately in #901) which has not yet been established. For example, migrations may need a separate owner / migrator role while the running API server only receives DML privileges. HBA rules also should be restricted appropriately.
#940 (comment)