Nastavení uživatelů a práv

[petrs...@gmail.com]

Ahojte,

řešíme rozdělení rolí v PostgreSQL a potřebujeme poradit s minimálními právy pro roli tool, kterou používá Terraform.

Potřebujeme správně nastavit tyto role:

- tool — role používaná Terraformem k provisioningu (má vytvářet, měnit a mazat DB a role).
- owner — role, která je ownerem DB a používá se pro spuštění migrací (má DDL práva).
- app — aplikační role s omezeným přístupem (pouze DML, ne DDL).

Zároveň chceme dosáhnout:

1. Chceme omezit práva na minimální nutnou úroveň.
2. tool musí umět vytvořit a později i smazat či upravit zdroje, které Terraform spravuje.
3. Nechceme/nemůžeme dávat roli tool superusera.
4. DB/owner/app tvori jednotku kterych je N (kazda sluzba ma svoji vlastni db, owner a app roli).
5. Cheme aby jednotlive App byly oddeleny pravy.

Problém:

- Pokud je tool superuser, vše funguje.
- Pokud tool není superuser, nejsem si jistý, jak umožnit, aby kromě vytváření mohl také mazat nebo modifikovat objekty (DROP/ALTER), zvlášť když objekty vlastní jiná role.

V podstatě narážíme na to, že když transferujeme ownership, tak už s objekty terraform role nemůže nakládat. Níže ještě příklad:

• máme dvě služby: auto a register

• role tool vytvoří:

  • roli auto_owner

  • roli auto_app

  • databázi auto_db (vlastněnou auto_owner)

  • roli register_owner

  • roli register_app

  • databázi register_db (vlastněnou register_owner)

• v čase dojde požadavek, že služba auto se má přejmenovat na vozidla

  • role tool tedy potřebuje přejmenovat:

    • roli auto_owner na vozidla_owner

    • roli auto_app na vozidla_app

    • DB auto_db na vozidla_db

• po čase se má aplikace register odebrat do křemíkového nebe

  • role tool tedy musí smazat:

    • roli register_owner

    • roli register_app

    • databázi register_db

Jak nastavit roli tool, aby umožnila nastíněné scénáře v příkladu a zároveň nebyla superuser. 

Jaké jsou osvědčené postupy pro ownership a role membership v situaci: Terraform + DB migrace + aplikační role?

Existují konkrétní GRANTy nebo mechanismy (role membership, policies), které umožní mazání objektů bez plného superuser práva? Tady narážíme na to, že vytvořenou DB může spravovat jen owner databáze nebo superuser. Nic takového se nám nepodařilo najít a myslíme si, že to dobře nejde.

[Michal Bartak]

Ahoj,

co takhle

owner role(s) - nologin - tady na tom bych trval tak nebo onak. je to dobry pattern.

tool - login, inheritance z owner roli. tim muze vytvaret a dropovat objekty vlastnene owner rolemi. prip. umoznuje zmenit context pomoci SET ROLE. A to bez su.

Nevyhoda: kazdou novou owner roli musis nagrantovat k toolu.

Jinak, obcas bez superuser to vubec nejde. mit jednoho dedikovaneho  usera s su neni spatne. muzes pro nej zapnout logovani vsech dotazu pro pripad budouci investigace. 

Michal Bartak

29. 1. 2026 v 21:22, petrs...@gmail.com <petrs...@gmail.com>:



--
Tuto zprávu jste obdrželi, protože jste přihlášeni k odběru skupiny „PostgreSQL-cz“ ve Skupinách Google.
Chcete-li zrušit odběr skupiny a přestat dostávat e‑maily ze skupiny, zašlete e-mail na adresu postgresql-c...@googlegroups.com.
Tuto diskuzi najdete na adrese https://groups.google.com/d/msgid/postgresql-cz/91763fec-ed45-47b6-88ba-5b930b97b989n%40googlegroups.com.

[Michal Bartak]

Jeste doplnim

Tool, aby mohl vytvaret novou DB a nove role nemusi byt superuser. Staci ze ma nastevene atributy CREATEDB a CREATEROLE.

Tady funkcni POC:

-- priprava uzivatele tool
CREATE ROLE tool CREATEROLE CREATEDB PASSWORD 'abcd'; -- prihlaseno jako tool

CREATE ROLE test_owner;

GRANT test_owner TO tool;

CREATE DATABASE testcars OWNER test_owner ; -- prihlaseno do testcars jako tool SET ROLE test_owner; CREATE SCHEMA test_schema; SELECT nspowner::regrole FROM pg_namespace WHERE nspname = 'test_schema'

nspowner |

----------+

test_owner|

Dalsi potencialni alternativou, jsou SECURITY DEFINER utility funkce, ktere meni scope na usera, ktery muze vsechno. Treba i superusera zs vypnutou moznosti prihlaseni (NOLOGIN).
K takovym funkcim nagrantujes EXECUTE vyhradne pro uzivatele tool. Je treba mit na vedomi, ze pg vsem novym funkcim grantuje EXECUTE pro public. Je to treba revoke'nout.

Michal

pá 30. 1. 2026 v 0:50 odesílatel Michal Bartak <maxym...@gmail.com> napsal:

[petrs...@gmail.com]

Mockrát díky! 

My jsme to právě takto měli v hlavě a překvapilo nás, že to u nás nefunguje. Jenže jakmile jsme to zkusili znovu a přesně, jak si napsal, tak to klaplo. 

Takže teď zjišťujeme, kde máme problém a myslíme si, že problém bude v tom, že jednotlivé DB vznikají Terraformem z postgresql templatu, odkud se zřejmě budou kopírovat i granty těch rolí a všude je jako grantor postgres.  Ve chvíli, kdy jsem zkusil pustit grant znova, tak se tam doplnil jako grantor "tool" a najednou to běhá, tak jak potřebujeme.

Mohlo by to takto dávat smysl?

Díky moc

Dne pátek 30. ledna 2026 v 2:02:31 UTC+1 uživatel maxym...@gmail.com napsal:

[Michal Bartak]

Jsem rad ze muj priklad pomohl.

Ohledne grantora, nikde v praxi jsem se nesetkal s tim aby mel nejaky vyznam.

V uvedenem priklade je dulezite aby:

- tool role mela pravo vytvaret db a role

- ownerem aplikacni db (a nasledne objektu uvnitr) byla aplikacni role

- tool role dedila z aplikacni role (ne naopak ;) )

- po prihlaseni tool roli do app db, session meni aktivniho usera na aplikacniho

v tomto contextu  je uplne jedno kdo komu nastavoval tato prava (grantor). konkretni chyba, na ktere kolaboval vas testcase mohla by pripadne pomoct.

Jsem zvedav na co prijdete.

Michal Bartak

2. 2. 2026 v 15:32, petrs...@gmail.com <petrs...@gmail.com>:



Tuto diskuzi najdete na adrese https://groups.google.com/d/msgid/postgresql-cz/9b1b9389-8d7d-4b10-b469-f9aba71d984bn%40googlegroups.com.

[petrs...@gmail.com]

Já bohužel nemám úplně historii, co se tam všechno udělalo dříve, ale původně chybová hláška byla, že ALTER DATABASE RENAME může udělat jen vlastník databáze nebo superuser. Grant té role mezi test_owner a tool tam probehl už při zakládání databáze Terraformem. Když jsem teď pustil znova  

GRANT test_owner TO tool;

Tak najednou rename proběhl a jediné, co se změnilo byl ten grantor. Jinak se mi granty zdají v pořádku. Budeme to zkoumat dál a dám vědět jakmile na to přijdeme.

Díky moc!

Dne pondělí 2. února 2026 v 16:02:44 UTC+1 uživatel maxym...@gmail.com napsal:

[Michal Bartak]

Muj odhad je, ze jste nemel nagrantovany test_owner do toolu.
Myslim si to proto, ze:

1. Opetovny pokus o provedeni stejneho grantu sice s chybou neskonci, ale nahlasi notifikaci:
   role "<child>" has already been granted membership in role "<parent>" by role "<grantor>".
   Toho byste si asi vsiml. ha.. prave jsme prisli na to k cemu je pouzivan grantor  ;)

2. Pokus o opetovne zadani stejneho grantu neovlivni puvodne uvedeneho grantora.
   Pokud mate pocit, ze se zmenil, znamena to, ze tento presny grant neexistoval. 😉

Michal

po 2. 2. 2026 v 16:09 odesílatel petrs...@gmail.com <petrs...@gmail.com> napsal:

Tuto diskuzi najdete na adrese https://groups.google.com/d/msgid/postgresql-cz/516e91e3-eaa2-4d0c-9000-0db4156503cbn%40googlegroups.com.

[petrs...@gmail.com]

já myslím, že už jsem na to přišel. Vydumpoval jsem si ty role (protože mám přístup až k tomu, co tam naleje Terraform) a tam je u všech těchto grantů všude INHERIT FALSE a SET FALSE. Zkoušel jsem to pak zase na tom minimálním příkladu a pak to nefunguje. Ten první grant bude ten z templatu a ten druhý je ten můj, který jsem dnes pustil ručně.

GRANT test__owner TO tool WITH ADMIN OPTION, INHERIT FALSE, SET FALSE GRANTED BY postgres;

GRANT test__owner TO tool WITH INHERIT TRUE GRANTED BY tool;

Takže vlastně máte pravdu :-) Proto si všichni byli jistí, že to nagrantované je, ale nefungovalo to. Tam vzniklo historicky něco divného, protože tohle si nemyslím, že někdo chtěl udělat.

Dne pondělí 2. února 2026 v 18:02:46 UTC+1 uživatel maxym...@gmail.com napsal: