1 open besluit1414 voorstellen

Onderwerp

Rollen, toegang en inloggegevens

Toepassingen, taken en personen krijgen tijdelijke inloggegevens op een eigen rol uit het geheimenbeheer. Vaste rollen bezitten de objecten, niemand werkt als postgres, en een verlopen of ingetrokken rol raakt ook lopende sessies.

Nog niet bevestigd door een mens. Eigenaar: vdo89. Bron in de atlas

Domein
Volgt uit
Functies
Producten
Verwant

Wat het is

Een toepassing meldt zich bij haar database aan met tijdelijke inloggegevens die het geheimenbeheer voor haar eigen rol uitgeeft; zij leest ze bij iedere nieuwe verbinding en houdt verbindingen kort in haar pool. Daarnaast zijn er vaste rollen die de objecten bezitten, een beheeraccount voor het geheimenbeheer, tijdelijke rollen voor structuurwijzigingen en beheer, en statische rollen voor replicatie en koppelingen.

Waarom zo

Met tijdelijke inloggegevens verloopt een gelekt wachtwoord vanzelf, en intrekking raakt ook open verbindingen. Vaste rollen zonder aanmelding houden het eigendom van schema en objecten stabiel, terwijl tijdelijke rollen er alleen lid van zijn; zo overschrijven het declaratieve rollenbeheer en het geheimenbeheer elkaar niet.

Het voorstel geeft niemand blijvende beheerrechten: de postgres-gebruiker heeft geen wachtwoord, beheer loopt via tijdelijke rollen zonder superuserrechten, en een opdrachtregel in een exemplaar kan alleen via de noodroute.

Uitspraken

1 vastgesteld16 voorstellen

Alle 16 voorstellen vaststellen

Tijdelijke inloggegevens

VoorstelOntwerpbesluit#

De tijdelijke inloggegevens komen uit de database-engine van OpenBao met de PostgreSQL-plug-in, met een eigen mount per applicatiecluster: een dynamische rol per toepassing met default_ttl 1h en max_ttl 24h, dus 1 uur geldig en verlengbaar tot ten hoogste 24 uur. Aanmaken zet VALID UNTIL op de vervaltijd van de lease; intrekken beëindigt eerst de sessies en verwijdert dan de rol. Tijdelijke rollen hebben een eigen voorvoegsel en staan buiten het declaratieve rollenbeheer.

Toelichting

Het gevolg is dat nieuwe aanmeldingen van het geheimenbeheer afhangen. Het beheeraccount dat de rollen maakt, heeft geen superuserrechten. Controle: de toets toegang op applicatie-identiteit.

VoorstelWerking#

De toepassing blijft verbonden terwijl haar inloggegevens worden vervangen. Een poolverbinding leeft ten hoogste 15 minuten; anders beëindigt het verlopen van de lease nog actieve verbindingen.

VanNaarHandeling
AgentOpenBaoVraagt een dynamische rol op, met een lease.
OpenBaoPostgreSQLMaakt tijdelijke inloggegevens met alleen de benodigde rechten.
AgentBestandVernieuwt de lease bij twee derde van de looptijd.
ToepassingPoolLeest bij iedere nieuwe verbinding opnieuw en sluit oude verbindingen tijdig.
VoorstelOntwerpbesluit#

De inloggegevens komen via de agent-injector van OpenBao: een sidecar zet ze met een sjabloon in een bestand op een gemeenschappelijk volume naast de container en vernieuwt de lease bij twee derde van de looptijd. Terugvaloptie is de CSI-provider. External Secrets levert alleen beheerde langlevende geheimen; voorbeeldsjablonen staan in de opslagplaats Catalogus.

Toelichting

De agent-injector is een acceptatiecriterium van de applicatieclusters, met de CSI-provider als terugvaloptie; de route van geheimen naar toepassingen staat bij geheimen, sleutels en certificaten.

VoorstelRegel#

De toepassing leest de inloggegevens bij iedere nieuwe verbinding, houdt verbindingen ten hoogste 15 minuten in haar pool en verbindt opnieuw na een geweigerde aanmelding, zodat een vervanging geen lopende verbinding treft. Er is geen centrale verbindingspooler: de pool zit in de toepassing.

Toelichting

Afgewezen: een PgBouncer-pooler van CloudNativePG per database. Dat is een extra onderdeel met eigen inloggegevens en een eigen TLS-eindpunt, en de toepassing controleert de database dan niet meer op certificaat. Een pooler past wel in de gedeelde databasevoorziening met veel toepassingen. Eigenaar van de regel: het applicatieteam. Controle: de toets vervanging van geheimen zonder onderbreking.

VoorstelRegel#

Een verlopen of ingetrokken rol wordt verwijderd na beëindiging van haar sessies, en PostgreSQL weigert haar ook als het geheimenbeheer onbereikbaar is. Zo geldt een intrekking ook voor open verbindingen.

VoorstelUitgangspunt#

Valt het geheimenbeheer uit, dan werken lopende verbindingen door en slagen nieuwe aanmeldingen nog tot de inloggegevens verlopen, 20 minuten tot 1 uur na de laatste verlenging. Dat is een aanvaard restrisico, begrensd door drie exemplaren van het geheimenbeheer en voorrang bij herstel.

VoorstelWerking#

Het draaiboek trekt de leases van een identiteit of van de hele database in binnen de norm voor intrekking van het geheimenbeheer; een intrekking die de database niet bereikt, blijft zichtbaar en wordt herhaald. Na een mogelijke compromittering vervangt platformbeheer binnen 24 uur beheeraccount en leases.

Rollenmodel

VoorstelOntwerpbesluit#

Er zijn drie vaste rollen, eigenaar, schrijven en lezen, zonder aanmelding. De eigenaar bezit schema en objecten; iedere tijdelijke rol is lid van precies één vaste rol, zodat tijdelijke rollen geen objecten bezitten. De vaste rollen zijn DatabaseRole-objecten met reclaimPolicy retain; een DatabaseRole neemt een bestaande rol over en herstelt ontbrekende eigenschappen.

VoorstelRegel#

Een toepassing meldt zich aan met de Kubernetes-authenticatierol van haar serviceaccount en naamruimte; haar eigen rol is lid van ‘schrijven’ of ‘lezen’. De migratietaak van het team draait in het applicatiecluster met een eigen serviceaccount en krijgt per uitvoering een rol als lid van ‘eigenaar’, 1 uur geldig; in reguliere productie start zij alleen uit een beoordeeld wijzigingsvoorstel. Een pijplijn krijgt geen databaserol en geen langlevend token.

VoorstelRegel#

Teamleden werken met de gegevens via hun toepassing: bij ontwikkelen en beproeven met de blijvende teamrechten, in reguliere productie met een verhoging binnen de eigen dienst. Een gegevenscorrectie in reguliere productie loopt via een goedgekeurd draaiboek.

Beheer en noodtoegang

VoorstelRegel#

De postgres-gebruiker heeft geen wachtwoord (enableSuperuserAccess uit), en niemand werkt als postgres. Het beheeraccount van het geheimenbeheer is geen superuser; zijn wachtwoord bestaat alleen in het geheimenbeheer en wisselt iedere 30 dagen. Beheeraccount, migratie-identiteit en back-upgebruiker hebben ieder één taak en een eigenaar.

Toelichting

De instelling schakelt alleen het wachtwoord van de postgres-gebruiker uit, niet de beheerrechten van de beheerfunctie; wie Cluster- of DatabaseRole-objecten mag wijzigen, kan rechten in de database toekennen.

VoorstelWerking#

Iedere database heeft een eigen beheeraccount voor het geheimenbeheer, met CREATEROLE, ADMIN OPTION op de vaste rollen en lidmaatschap van pg_signal_backend, zonder superuserrechten. De automatisering maakt het aan met een startwachtwoord, voert direct rotate-root uit en haalt startwachtwoord en verwijzing uit het rolobject, zodat de beheerfunctie het wachtwoord niet terugzet; rotate-root volgt daarna iedere 30 dagen.

VoorstelRegel#

Een persoon krijgt alleen met een verhoging een eigen databaserol, via de beheerwerkplek met poortdoorschakeling en sessieopname, met inloggegevens die uiterlijk op de einddatum van de verhoging vervallen. Een platformbrede verhoging geeft een tijdelijke beheerrol met pg_monitor, pg_signal_backend en pg_maintain, zonder superuserrechten. Een beheertaak krijgt haar verhoogde rechten na goedkeuring door een tweede persoon.

Toelichting

Zo is beheer taakgebonden en controleerbaar. Controle: de toets beheertoegang en noodtoegang.

Langlevende identiteiten

VoorstelRegel#

Replicatie- en koppelingsidentiteiten naar databases buiten het platform zijn statische rollen van het geheimenbeheer, met rotation_period 30 dagen. Zonder twee geldige waarden tegelijk geldt een onderbrekingsuitzondering met einddatum; het herverbinden na een vervanging wordt beproefd.

Toelichting

Zo breken koppelingen niet onverwacht.

Verwijzen hiernaar

Onderwerpen 4