Wie zich op een applicatiecluster aanmeldt en met welke rechten, hoe toepassingen worden uitgerold, en hoe toepassingen en besturingen aan identiteit, geheimen en certificaten komen.
Nog niet bevestigd door een mens. Eigenaar: vdo89. Bron in de atlas
Dit onderwerp beschrijft de toegang tot een applicatiecluster en wat de toepassingen erin aan vertrouwen krijgen.
Teamleden melden zich aan via de centrale aanmelding, met rechten die per profiel verschillen; in productie schrijft
alleen het Argo CD van het cluster. Toepassingen krijgen een applicatie-identiteit per cluster, naamruimte en
serviceaccount, geheimen uit het geheimenbeheer van de cel en kort geldige certificaten uit de PKI van de cel. De
besturing heeft haar eigen geheimen, zoals de sleutel voor etcd en de toegang tot de werkervirtualisatie.
Waarom zo
Gedeelde accounts en vaste wachtwoorden zijn een bekend knelpunt. Toegang op basis van identiteit, kort geldige
geheimen en certificaten, en rechten die per naamruimte en cluster begrensd zijn, beperken wat een gestolen geheim of
een misbruikte rol waard is. Omdat in productie geen persoon blijvend schrijft, loopt iedere wijziging via versiebeheer
en de uitrol door het platform, en is een ingreep een tijdelijke, goedgekeurde en opgenomen verhoging. Welke route een
toepassing voor haar geheimen gebruikt, is nog een open beslispunt.
Teamleden melden zich aan op de API of console van hun eigen cluster via de ingebouwde OAuth-server van het gastcluster, met Keycloak als OpenID-aanbieder (mappingMethod claim, groups-claim), vastgelegd in de clusterdefinitie, en met meerfactoraanmelding. Toegangstokens verlopen na 15 minuten inactiviteit en gelden ten hoogste 1 uur. Het installatieaccount wordt verwijderd zodra de aanbieder werkt, een tweede beheeridentiteit via de noodroute beschikbaar is en de noodtoegang per cluster is beproefd.
Toelichting
Een externe OpenID-aanbieder rechtstreeks aan de API-server schakelt het installatieaccount en de OAuth-server uit; daarom blijft de ingebouwde OAuth-server in gebruik. De maximale tokenduur volgt de norm dat een ingetrokken recht binnen een uur vervalt. Het verwijderen van het installatieaccount is onomkeerbaar, dus de volgorde ligt vast. De compliancescan en de toets Beheertoegang en noodtoegang tonen de naleving aan.
Teams schrijven blijvend alleen in het profiel ontwikkelen en beproeven, met admin in hun eigen naamruimten. In reguliere en bedrijfskritische productie hebben zij view en grijpen zij alleen in met een verhoging van ten hoogste 4 uur, goedgekeurd door een ander teamlid, alleen vanuit de teampool van de beheerwerkplek en met sessieopname. De verhoogde teamgroep <cel>-<team>-verhoogd krijgt admin plus pods/exec en pods/portforward en komt alleen mee via de aanmeldroute van de teampool.
Toelichting
Zo zijn er geen persoonlijke schrijfrechten in productie. Groepen uit Keycloak zijn gekoppeld aan ClusterRoles. De verkeersverdeling filtert niet: gebruik van de verhoogde groep van buiten de teampool is een aanvaard restrisico, dat een detectieregel binnen 1 uur meldt. Rolbindingen en detectieregels tonen de naleving aan.
Platformbeheerders lezen alle clusters. Clusterbeheerrechten op een applicatiecluster zijn een platformbrede verhoging, binnen 15 minuten goedgekeurd door een tweede persoon.
Ieder cluster heeft een tweede beheeridentiteit via de noodroute, onafhankelijk van de toegangsvoorziening, met de gegevens in de kluis. Twee personen halen haar samen uit de kluis, het gebruik wordt bij het SOC gemeld en na gebruik wordt zij vervangen.
Toepassingen worden per cluster uitgerold door een eigen Argo CD in een platformnaamruimte, begrensd tot de teamnaamruimten. In reguliere en bedrijfskritische productie rolt alleen dat Argo CD uit, vanaf de beschermde hoofdtak van de opslagplaats van de toepassing in GitLab, en alleen op objecten in de teamnaamruimten, niet op naamruimten, rollen, netwerkbeleid of quota. Het leest die opslagplaats met een leestoken van het team per cluster, dat het team in zijn eigen pad in het geheimenbeheer zet, als beheerd langlevend geheim registreert en iedere 30 dagen vervangt.
Toelichting
Zo rolt het platform uit met zijn eigen identiteit, zonder persoonlijke schrijfrechten in productie en zonder platformtoegang tot de opslagplaatsen van teams; de toelatingscontrole blijft de grens. Alternatieven: uitrol met eigen schrijfrechten, wat alleen in ontwikkelen en beproeven past, of uitrol via het Argo CD van het vlootbeheer, waarmee de inhoud van teams bij een vlootbrede rol komt. Het langlevende leestoken is een aanvaard restrisico: het mag alleen lezen en wordt iedere 30 dagen vervangen. Een rechtenrapport en een negatieve proef tonen de begrenzing aan.
Ieder cluster kent een vast stel technische identiteiten, elk met een eigenaar en minimale rechten: de uitrolidentiteit van het vlootbeheer voor de standaardinrichting en rolbindingen, die van het eigen Argo CD, de geheimenkoppeling per naamruimte, de back-upgebruiker, de CephX-gebruikers en de leesrobot van de containerregistry. De leesrobot mag alleen lezen en is het enige langlevende robotaccount.
De vertrouwensgrens ligt tussen afnemers bij het cluster, binnen een team bij de naamruimte en tussen team en platform bij de standaardinrichting. Vlootbeheer en versiebeheer van het platform lezen geen opslagplaatsen van teams.
Iedere werklast heeft een applicatie-identiteit per cluster, naamruimte en serviceaccount, uitgegeven door Red Hat Zero Trust Workload Identity Manager volgens SPIFFE. Het vertrouwensdomein (trustDomain) is het domein van de cel, gelijk aan dat van het dienstennetwerk; clusterName is de clusternaam, en de SPIFFE-ID bevat cluster, naamruimte en serviceaccount. Voor een dienst in bedrijfskritische productie registreert de bron de identiteit uit beide cellen. Alleen platformbeheer wijzigt de objecten van de identiteitsvoorziening.
De objecten ZeroTrustWorkloadIdentityManager, SpireServer, SpireAgent, SpiffeCSIDriver en SpireOIDCDiscoveryProvider hebben alle de naam cluster; trustDomain en clusterName zijn na het aanmaken onveranderbaar. Versie 1.1 is volledig ondersteund tot 16 november 2026. Een ondersteunde opvolger is een acceptatiecriterium, met als terugvaloptie aanmelding met het serviceaccount bij het geheimenbeheer en certificaten van cert-manager. De toets Toegang op applicatie-identiteit beproeft de identiteit.
De versleutelingssleutel, de infra-kubeconfig, het pull-geheim en de certificaten van een gehost cluster staan in het geheimenbeheer onder platform/<cluster>/, de koppelgegevens van de opslag onder platform/<cluster>/opslag. Bij vervanging van de versleutelingssleutel wordt de nieuwe de activeKey en de vorige de backupKey; oudere versies blijven bewaard zolang back-ups ze nodig hebben.
Toelichting
Dat de besturing een nieuwe infra-kubeconfig zonder onderbreking gebruikt, toont een vervangingsproef aan.
Het toegangsbewijs op de werkervirtualisatie (de infra-kubeconfig) en het pull-geheim worden iedere 30 dagen vervangen, uiterlijk na 90 dagen, en binnen 24 uur nadat een mogelijke compromittering is vastgesteld. Een vervanging is pas af als de besturing het nieuwe toegangsbewijs gebruikt en het oude niet meer werkt.
Geheimen komen in een applicatiecluster alleen binnen via de geheimenkoppeling, per naamruimte beperkt tot de eigen paden; handmatig aangemaakte clustergeheimen zijn er niet. Tijdelijke inloggegevens gelden 1 uur en zijn verlengbaar tot ten hoogste 24 uur. Iedere opvraging wordt vastgelegd, en de vervanging gebeurt vanuit het geheimenbeheer.
Toelichting
Dit is een open beslispunt. Het domein geheimen beschrijft ook een route waarin een toepassing een geheim zelf ophaalt met haar applicatie-identiteit en het alleen in het geheugen houdt, en de terugvaloptie voor de applicatie-identiteit laat toepassingen zich met hun serviceaccount bij het geheimenbeheer aanmelden. Die routes spreken deze regel tegen; het besluit legt vast welke route geldt. Een geweigerde opvraging uit een andere naamruimte toont de begrenzing aan.
External Secrets Operator (ExternalSecretsConfig met de naam cluster) levert beheerde langlevende geheimen via de vault-provider met Kubernetes-authenticatie per cluster, ieder uur ververst. Per teamnaamruimte is er een ClusterSecretStore met een voorwaarde op die naamruimte en een eigen rol in OpenBao, zodat een team alleen zijn eigen paden kan ophalen. Netwerkbeleid staat uitgaand verkeer naar OpenBao toe; ander uitgaand verkeer is standaard geweigerd.
Toelichting
Zo is de toegang per toepassing begrensd. Alternatief: één koppeling voor alles; dan kan een toepassing de geheimen van een andere ophalen. De begrenzing per naamruimte is een acceptatiecriterium, met als terugvaloptie een SecretStore per teamnaamruimte.
Tijdelijke inloggegevens komen via de agent-injector van OpenBao, die via beleid in alle teamnaamruimten beschikbaar is; hij verlengt leases en vervangt inloggegevens zonder onderbreking. External Secrets levert alleen beheerde langlevende geheimen.
Toelichting
De agent-injector is een acceptatiecriterium, met als terugvaloptie de CSI-provider van OpenBao. De koppeling is getest met HashiCorp Vault en moet met OpenBao in de leeromgeving zijn aangetoond.
Een gecompromitteerd geheim wordt ingetrokken, binnen 24 uur vervangen en nooit hersteld, en lopende sessies worden beëindigd. Platformbeheer doet dat samen met het applicatieteam en oefent het ieder half jaar.
Certificaten komen via cert-manager, met een ClusterIssuer naar de PKI onder de tussen-CA van de cel, en alleen voor eigen namen: ieder cluster heeft een eigen PKI-rol. Voor een dienstnaam in bedrijfskritische productie komt het certificaat onder de tussen-CA ‘vloot’, voor een publieke naam uit de externe PKI. Werklastcertificaten gelden 24 uur, certificaten van diensten ten hoogste 90 dagen, en alle worden automatisch vernieuwd bij twee derde van de looptijd.
Toelichting
De naambeperking van de tussen-CA scheidt alleen de cellen; de PKI-rol per cluster voorkomt dat een cluster een certificaat voor een ander cluster krijgt. Alternatief: één uitgever voor alles. Een certificaatoverzicht en een negatieve proef tonen de begrenzing aan. Een publiek certificaat plaatst een draaiboek als geheim in de naamruimte van de route.
De etcd-sleutel van een cluster wordt jaarlijks vervangen, certificaten worden automatisch vernieuwd en publieke certificaten per draaiboek; het leestoken vervangt het team zelf. CephX-sleutels worden alleen na een incident vervangen en bij beëindiging ingetrokken. Platformbeheer oefent de vervanging ieder half jaar, met PKI-beheer.
De cryptografie volgt per pad de cryptografietabel van RWS, zonder MD5, en is voor alle profielen gelijk, zonder FIPS-modus; het cryptografieoverzicht toont dat. Bij TLS 1.3 kiezen API-server, kubelet en ingangscontroller zelf de hybride quantumveilige sleuteluitwisseling X25519MLKEM768; etcd niet.
Toelichting
Het TLS-profiel is Modern (alleen TLS 1.3) waar alle clients het ondersteunen, anders Intermediate. Het dienstennetwerk zet de quantumveilige sleuteluitwisseling bij zijn ingebruikname aan met COMPLIANCE_POLICY pqc.