Onderwerp
Nog niet bevestigd door een mens. Eigenaar: vdo89. Bron in de atlas
Het geheimenbeheer geeft geheimen uit, vervangt ze en trekt ze in: wachtwoorden, sleutels, tokens en certificaten die toepassingen, koppelingen en beheerders nodig hebben. Uitgifte, vervanging en intrekking liggen bij het geheimenbeheer, niet bij de toepassing. Vraagt een dienstbeschrijving om een databaserol, een bucket of een koppeling met een ander systeem, dan maakt het platform bij de levering de identiteit, het beleid en de koppeling aan. De eigenaar van het doelsysteem bepaalt welke rechten die identiteit daar krijgt.
Iedere cel heeft een eigen geheimenbeheer: OpenBao, in het basisdienstencluster. De levenscyclus van sleutels en de ontgrendeling staan in Sleutels, ontgrendeling en versleuteling, de certificaten in Certificaten en PKI.
Naast beheerrechten zijn geheimen een belangrijk doelwit van een aanvaller. Een kort geldig geheim beperkt wat een gestolen geheim waard is, en een eigen geheimenbeheer per cel zorgt dat een incident in de ene cel de andere niet raakt. Kortlevende geheimen werken alleen als de vernieuwing automatisch gaat. Daarom levert het platform de geheimenkoppeling en voorbeeldsjablonen, en wordt iedere vervanging per koppeling beproefd: pas als de oude waarde nergens meer werkt, is zij vervangen.
Alle geheimen (wachtwoorden, sleutels, tokens, certificaten) komen uit het geheimenbeheer van de cel. Geen geheim staat in code, containerbeelden, tickets, chat, e-mail of documentatie. Een dienstbeschrijving, sjabloon of clusterdefinitie bevat alleen verwijzingen naar geheimen.
De controle is een geheimenscanner in iedere pijplijn en een wekelijkse scan over de volledige historie; een echt geheim is een incident.
Buiten het geheimenbeheer staan alleen vijf geheimen, alle vijf in het register met eigenaar, reden en einddatum: de toegangsgegevens van het sleutelslot (pincode en clientcertificaat), de sleutel van de luisteraar (clustergeheim en kluis), de herstelsleutels, de noodaccounts en een kopie van de keystore van midPoint (kluis).
Iedere cel heeft een eigen geheimenbeheer met eigen geheimen, zodat een incident met de geheimen van de ene cel de andere niet raakt. Geen account of sleutel heeft beheerrechten in beide cellen, behalve de vlootbrede rollen. Een beheerd cluster krijgt zijn geheimen uit zijn eigen cel; via de hub gaan alleen verwijzingen, zodat een aangetaste hub geen geheimen van clusters bevat.
Vier onderdelen raken wel beide cellen, als aanvaard restrisico: de gedeelde wortel van de PKI, de tussen-CA ‘vloot’ voor de dienstnamen van P3-diensten, de hardwaresleutelmodule van PKI-beheer en de vlootbrede beheerrollen.
Authenticatiegegevens (tokens, wachtwoorden, kubeconfigs) hebben een vervangingsbeleid en worden veilig opgeslagen.
Geheimen zijn kort geldig waar het product dat toelaat en worden automatisch vervangen, zonder tussenkomst van het team.
Toepassingen krijgen tijdelijke inloggegevens voor databases en diensten, uitgegeven op hun applicatie-identiteit: 1 uur geldig, verlengbaar tot ten hoogste 24 uur.
Een langlevend geheim is een uitzondering, alleen waar de andere kant geen identiteit en geen tijdelijke uitgifte kent. Het staat in het register met eigenaar, reden en einddatum, wordt in productie iedere 30 dagen vervangen en is nooit ouder dan 90 dagen, gerekend vanaf het aanmaken van de waarde. Uitstel kan alleen vóór het verlopen, met een harde einddatum.
De koppelsleutels van het opslagcluster volgen het opslagontwerp: zij worden alleen vervangen na een incident of een vermoeden van compromittering.
Langlopende processen en koppelingen gebruiken een vernieuwbare identiteit, anders een beheerd geheim met overlappende vervanging. Een vervanging onderbreekt geen koppeling die twee geldige waarden tegelijk of herladen zonder herstart ondersteunt; andere koppelingen krijgen een gedateerde onderbrekingsuitzondering in het uitzonderingsregister. Het gedrag wordt per koppeling beproefd, vóór productie.
De norm: een vervanging kost hoogstens één herverbinding en geen gegevens. Er zijn vaste patronen voor replicatie, batchverwerking, doorlopende verbindingen, beheertaken en locaties zonder vaste verbinding.
Een vervanging is pas voltooid als de afnemer de nieuwe waarde gebruikt en de oude niet meer werkt, ook niet bij de ontvangende dienst.
Een toepassing leest een geheim bij het verbinden en niet bij de start, hergebruikt een verbinding ten hoogste 15 minuten en leest en verbindt opnieuw na een geweigerde aanmelding. Het platform levert die regels in voorbeeldsjablonen en bibliotheken voor de gangbare programmeeromgevingen.
Kan een toepassing een geheim zelf ophalen, dan doet zij dat met haar applicatie-identiteit en houdt zij het alleen in het geheugen. Anders zet de geheimenkoppeling het geheim in een bestand naast de container en vernieuwt zij het vóór het verloopt. De laatste mogelijkheid is een clustergeheim: het cluster bewaart het zelf, versleuteld in rust.
Open punt: de regel voor applicatieclusters laat geheimen alleen via de geheimenkoppeling binnenkomen. Welke route geldt, is een open beslispunt.
Tijdelijke inloggegevens komen via de agent-injector van OpenBao, via beleid in alle teamnaamruimten: een sidecar zet ze met een sjabloon in een bestand naast de container en vernieuwt de leases automatisch. Terugvaloptie is de CSI-provider van OpenBao.
External Secrets Operator levert alleen beheerde langlevende geheimen, als clustergeheim. Per teamnaamruimte is er een ClusterSecretStore met een voorwaarde op die naamruimte en een eigen rol in OpenBao; terugvaloptie is een SecretStore per teamnaamruimte. Het clustergeheim wordt ieder uur ververst en de toepassing herstart via de reloader-annotatie, onder een gedateerde onderbrekingsuitzondering.
Toegang tot geheimen is begrensd per toepassing en per beheertaak, op basis van de identiteit van de toepassing, met per cluster een eigen mount. Een toepassing leest alleen de paden van haar eigen naamruimte. De herstelomgeving heeft alleen toegang tot herstel-<cel>.
Iedere opvraging van een geheim, ook een geweigerde, komt in het auditlogboek en gaat naar het SOC. Een ongebruikelijke opvraging wordt binnen 1 uur opgepakt: meer dan 3 keer het normale aantal (en meer dan 20) per identiteit per uur, of 5 of meer weigeringen buiten het eigen beleid.
Eén cluster overbelast het geheimenbeheer niet: ten hoogste 100 aanvragen per seconde per mount, hoger na een capaciteitstoets. Terugvaloptie is een melding van ongebruikelijke opvragingen en het tijdelijk intrekken van de toegangsbewijzen van dat cluster.
Logboeken bevatten geen geheimen. De audit van het geheimenbeheer legt vast op metadataniveau, en de audit van de clusterbesturing legt de inhoud van schrijfacties vast, behalve van geheimen en toegangsbewijzen.
Sleutels en geheimen worden vervangen na een incident en na vertrek van iemand die ze kende. Bij een vastgestelde compromittering worden ze direct ingetrokken waar dat kan, en binnen 24 uur nadat een mogelijke compromittering is vastgesteld vervangen. Een gecompromitteerde waarde wordt nooit hersteld. De procedure wordt ieder half jaar beproefd.
Het geheimenbeheer draait op lokale volumes en niet op het opslagcluster, zodat het bruikbaar blijft tijdens herstel van het opslagcluster. Gevolg: geen live-migratie.
Het geheimenbeheer, de databases, de toegangsvoorziening en het identiteitsbeheer starten zonder opslagcluster en zonder draaiend geheimenbeheer. Daarvoor staan de geheimen van de startketen als clustergeheim, net als de slotgegevens en de sleutel van de luisteraar, en staan de beelden op ieder knooppunt.
Het geheimenbeheer wordt afzonderlijk hersteld, omdat toepassingen en koppelingen zonder geheimen niet starten, vanuit een momentopname uit de onveranderbare kopie. Na compromittering van de cel of van het beheer zelf begint het herstel buiten de getroffen vertrouwensgrens, vanuit de herstelkern.
De momentopname wordt ieder uur gemaakt, door de snapshotagent.
Het geheimenbeheer is OpenBao: open source, met de benodigde koppelingen, en automatisch ontgrendeld van buiten de cel.
OpenBao 2.7.0 vanaf de eerste levering; daarna steeds de nieuwste minorversie, na een vaste beproeving binnen 30 dagen in productie.
Het versiebeleid volgt de feiten uit de publieke documentatie van het OpenBao-project.
OpenBao valt onder eigen beheer: versies binnen het versiebeleid van het project, beveiligingsupdates binnen de termijnen van het SAK Patch Management en een onderhoudsplan met contactroute. De jaarlijkse herziening van de baseline beoordeelt of een ondersteuningscontract nodig is.