Privileges en het reader- en contributorpatroon

Geef rechten op het schema, via twee groepen

Je hebt nu een namespace en identiteiten. Deze les verbindt ze. Het patroon dat wij op elk platform gebruiken is kort: per schema één reader-groep en één contributor-groep en een groep als eigenaar. Mensen krijgen toegang door lid te worden van een groep en niemand krijgt een eigen recht.

We behandelen de privileges die je nodig hebt, hoe overerving werkt en waarom het schema het juiste niveau is. Privileges op metastore-niveau behandelen we niet uitgebreid.

De privileges die ertoe doen

De Unity Catalog-documentatie definieert elk privilege. Dit zijn de privileges die je dagelijks gebruikt.

Twee punten laten de meeste teams struikelen. Ten eerste: usage-privileges zijn vereist naast het dataprivilege. Een groep met SELECT op een tabel maar zonder USE SCHEMA ziet niets. Ten tweede vereist MODIFY het recht SELECT, dus een contributor moet ook reader zijn.

Overerving: waarom het schema het niveau is

Privileges die op een catalog of schema worden gegeven, gelden voor de bestaande en toekomstige onderliggende objecten. De documentatie geeft het voorbeeld dat SELECT op een schema elke bestaande en nieuwe tabel en view daarin dekt. Hetzelfde geldt voor MODIFY, READ VOLUME, WRITE VOLUME en EXECUTE. MANAGE op een container geeft ook MANAGE op de onderliggende objecten. De documentatie noemt ook dat overerving privilegemodel versie 1.0 vereist, dus oudere metastores moeten mogelijk eerst worden bijgewerkt.

Dat gedrag maakt het schema het natuurlijke niveau voor rechten:

• Een recht op een tabel moet voor elke nieuwe tabel worden herhaald en mensen vergeten dat.
• Een recht op een catalog is breed: het bereikt elk schema, ook de schema's die je volgend jaar toevoegt.
• Een recht op een schema past bij een laag of vakgebied. Een nieuwe tabel in gold is gedekt zodra hij bestaat.

Geef alleen rechten op een tabel of volume als één object een ander publiek heeft dan de rest van zijn schema, zoals een tabel met salarisdata. Onze standaard voegt in die gevallen een groep op tabelniveau toe.

Het reader- en contributorpatroon

Maak voor elk schema twee groepen.

Pipelines die silver schrijven zijn lid van de contributorgroep van silver en de readergroep van bronze. Analisten zijn lid van de readergroep van gold. Niemand behalve de ingestieprincipal is lid van een contributorgroep van bronze. De lagen uit les 1 en de groepen komen een-op-een overeen, dus het toegangsmodel legt zichzelf uit.

Hier staat de SQL voor één schema. Groepsnamen volgen de conventie uit les 2.

-- Reader: mag alles in prd_finance.gold zien en bevragen, nu en in de toekomst.
GRANT USE CATALOG ON CATALOG prd_finance              TO `grp-uc-prd-finance-gold-reader`;
GRANT USE SCHEMA  ON SCHEMA  prd_finance.gold         TO `grp-uc-prd-finance-gold-reader`;
GRANT SELECT      ON SCHEMA  prd_finance.gold         TO `grp-uc-prd-finance-gold-reader`;
GRANT READ VOLUME ON SCHEMA  prd_finance.gold         TO `grp-uc-prd-finance-gold-reader`;
 
-- Contributor: leest als de reader en mag ook tabellen en bestanden maken en wijzigen.
GRANT USE CATALOG  ON CATALOG prd_finance             TO `grp-uc-prd-finance-gold-contributor`;
GRANT USE SCHEMA   ON SCHEMA  prd_finance.gold        TO `grp-uc-prd-finance-gold-contributor`;
GRANT SELECT       ON SCHEMA  prd_finance.gold        TO `grp-uc-prd-finance-gold-contributor`;
GRANT MODIFY       ON SCHEMA  prd_finance.gold        TO `grp-uc-prd-finance-gold-contributor`;
GRANT CREATE TABLE ON SCHEMA  prd_finance.gold        TO `grp-uc-prd-finance-gold-contributor`;
GRANT WRITE VOLUME ON SCHEMA  prd_finance.gold        TO `grp-uc-prd-finance-gold-contributor`;
 
-- Eigenaarschap hoort bij een groep.
ALTER SCHEMA prd_finance.gold OWNER TO `grp-uc-prd-finance-gold-owner`;

Draai zulke rechten via je pipeline, vanuit code. In les 7 wordt hetzelfde patroon een Terraform-module, zodat niemand in productie met de hand een GRANT typt.

Inspecteren en intrekken

SHOW GRANTS ON SCHEMA prd_finance.gold;                    -- alles wat op dit schema is gegeven
SHOW GRANTS `grp-uc-prd-finance-gold-reader` ON SCHEMA prd_finance.gold;
 
REVOKE CREATE TABLE ON SCHEMA prd_finance.gold FROM `grp-uc-prd-finance-gold-contributor`;

De documentatie noemt dat REVOKE slaagt, ook als het privilege nooit is gegeven. Het is dus veilig in opruimscripts en even veilig te verkeerd te typen. Lees daarna de uitvoer van SHOW GRANTS.

Gevoelige tabellen hebben hun eigen publiek nodig

Stel dat gold.payroll alleen voor HR zichtbaar mag zijn. Houd het readerrecht op het schema voor algemene tabellen en zet payroll in een eigen schema, zoals gold_hr, of geef het een groep op tabelniveau. Een apart schema is netter: de rechten blijven op schemaniveau en overerving werkt voor je. Moet je payroll in gold houden, dan stelt het readerrecht op het schema hem bloot. Daarom ontwerpen we schemagrenzen rond doelgroepen en niet alleen rond lagen.

Review toegang elk kwartaal

Verwijder rechten die niemand gebruikt. Haal één keer per kwartaal de leden van elke groep en de rechten van elk schema op en vraag de eigenaar beide te bevestigen. Omdat toegang via groepen loopt, is de review een lijst groepsleden en geen duizenden individuele rechten. Systeemtabellen helpen (les 5), want ze tonen wat een groep werkelijk gebruikte.

Veelgemaakte fouten

• Ontbrekende USE SCHEMA. De klassieke "ik zie mijn tabel niet".
• Rechten aan een persoon "alleen voor vandaag". Het blijft jaren staan.
• Rechten op de catalog terwijl een schema bedoeld was.
• ALL PRIVILEGES als snelkoppeling. Het geeft meer dan de taak nodig heeft en verbergt de bedoeling.
• De engineer die het object maakte, is eigenaar. Wijzig het eigenaarschap naar de groep.

Samenvatting

Geef rechten op het schema, aan twee groepen per schema, en laat overerving toekomstige tabellen dekken. Onthoud de usage-privileges. Geef eigenaarschap aan een groep. Los uitzonderingen op met aparte schema's of groepen op tabelniveau en review elk kwartaal.

Volgende les: fijnere controle binnen een tabel met rijfilters en kolommaskers.