Onderwerp
Nog niet bevestigd door een mens. Eigenaar: vdo89. Bron in de atlas
De toelatingscontrole bepaalt of software op een cluster mag starten. Twee controlepunten doen dat afzonderlijk: de Policy Controller bij de toelating tot het cluster en CRI-O op het knooppunt bij het ophalen van het beeld. Beide toetsen de handtekening tegen een vertrouwensbasis die het vlootbeheer op ieder cluster uitrolt.
Dit onderwerp legt het beleid per ruimte vast, de vertrouwensbasis en haar geldigheid, de standen melden en afdwingen, en wat wordt gemeld en beproefd.
Eén controlepunt kan uitvallen of worden omzeild; twee onafhankelijke punten maken een omweg buiten de pijplijn zinloos. Omdat de controle werkt met een vertrouwensbasis die het cluster al heeft, blijft een cel ook zonder vlootcluster of andere cel toegelaten software starten. Een einddatum op die vertrouwensbasis zorgt dat een ingetrokken sleutel ook op een onbereikbaar cluster vervalt, en weigeren bij storing voorkomt dat een storing de controle stil uitschakelt.
De beleidsobjecten, termijnen en terugvalopties zijn een voorstel.
Op een cluster start alleen software uit de ruimtes vrijgegeven, derden of spiegel van de containerregistry van de eigen cel, met een geldige handtekening van het platform of, voor platformsoftware in de spiegel, van de leverancier.
De controle geldt op het vlootcluster, de platformclusters en alle gehoste clusters, waaronder bouwcluster, portaalcluster en herstelomgeving; ieder nieuw cluster heeft haar vanaf zijn aanmaak. Een team kan de toelatingscontrole niet uitschakelen.
Twee onafhankelijke controlepunten toetsen ieder voor zich de handtekening: de toelatingscontrole bij de toelating tot het cluster, met de Policy Controller van Trusted Artifact Signer, en het knooppunt bij het ophalen van het beeld. Ieder cluster heeft daarom twee beleidsvormen.
Zo is één controlepunt niet de enige grens, en werkt een omweg buiten de pijplijn niet. Iedere negatieve proef loopt bij de toelatingscontrole en, afzonderlijk, bij het ophalen op het knooppunt.
De Policy Controller heeft per ruimte van de containerregistry van de cel één ClusterImagePolicy (policy.sigstore.dev/v1beta1) in de stand afdwingen, met één sleutel en de sleutel van Rekor uit de vertrouwensbasis: voor vrijgegeven de publieke bouwsleutel, voor derden de toelatingssleutel en voor de spiegel de sleutel van de leverancier waar die zo tekent. Het beleid eist een herkomst- of toelatingsattest, en zonder passend beleid weigert de controle.
Een handtekening zonder herkomst volstaat dus niet. Gecontroleerd met het nalevingsoverzicht van het beleid en de acceptatieproef Softwareketen.
Op de knooppunten controleert CRI-O met een ClusterImagePolicy (config.openshift.io/v1) per vrijgegeven ruimte: de bijbehorende publieke sleutel als vertrouwensbasis, het voorvoegsel van die ruimte als reikwijdte en een RemapIdentity naar het quarantainevoorvoegsel van de cel waarin is getekend. De spiegel valt onder het ongewijzigde standaardbeleid ‘openshift’ en, voor operators, een eigen beleid met RemapIdentity. De beeldconfiguratie staat alleen de spiegel en de eigen containerregistry toe.
Een eigen beleid heet nooit ‘openshift’. De ClusterImagePolicy is onderdeel van OpenShift 4.22 en algemeen beschikbaar sinds 4.20. De werking met RemapIdentity in gehoste clusters is een voorwaarde bij de acceptatie; lukt dat niet, dan ontbreekt daar de controle bij het ophalen, als uitzondering met compenserende maatregel en einddatum, en blijft de toelatingscontrole afdwingen. Vanaf groeipadstap 2 krijgen de knooppunten FulcioCAWithRekor in plaats van een publieke sleutel.
De Policy Controller draait in twee exemplaren per cluster, in verschillende rekken, en weigert bij een storing. Hij controleert de naamruimten met het label policy.rhtas.com/include; dat label staat op alle naamruimten van teams, ook op die met platformsoftware van het ontwikkelteam, en wordt teruggezet als het verdwijnt.
Een storing schakelt de controle zo niet stil uit: alleen gelabelde naamruimten merken haar, platformnaamruimten niet, en het knooppunt blijft controleren. Twee exemplaren die zonder passend beleid weigeren, zijn een voorwaarde bij de acceptatie; de terugvaloptie is één exemplaar dat bij storing weigert, met een beleid voor iedere ruimte. Afgewezen: doorlaten bij een storing, zoals Advanced Cluster Security in het profiel ontwikkelen en beproeven doet; een storing zou dan de controle op herkomst stil uitschakelen.
Voor de controle zelf is geen netwerkverbinding nodig: toelatingscontrole en knooppunt controleren tegen de vertrouwensbasis op het cluster en de bundel met handtekening en attesten bij het beeld.
De vertrouwensbasis bestaat uit de publieke bouwsleutel, de publieke toelatingssleutel, de sleutel van Rekor en later de tussen-CA ‘ondertekening’ van Fulcio. Het vlootbeheer rolt haar uit op ieder cluster; de laatst ontvangen versie geldt binnen haar geldigheidsduur. Bij herstel van een cel krijgt ieder cluster de vertrouwensbasis voordat de eerste werklast van een team start.
Vloot en cel delen alleen de vertrouwensbasis. Zij staat in de opslagplaats Beleid en gaat mee in de herstelkern.
De vertrouwensbasis is 30 dagen geldig en wordt wekelijks opnieuw uitgegeven. Na die einddatum weigert de Policy Controller; is zij ouder dan 8 dagen, dan volgt een melding dat de wekelijkse vernieuwing is gemist.
Ruim genoeg om het vlootbeheer te herstellen, kort genoeg om een ingetrokken sleutel te laten vervallen. Afgewezen: een vertrouwensbasis zonder einddatum, waarbij een ingetrokken sleutel geldig blijft op een cluster dat het vlootbeheer niet bereikt. Het weigeren na de einddatum is een voorwaarde bij de acceptatie; de terugvaloptie is een taak van het platform op het cluster zelf die het toelatingsbeleid dan op weigeren zet.
De toelatingscontrole werkt zonder vlootcluster en zonder de andere cel, op de laatst ontvangen vertrouwensbasis zolang die geldig is, en weigert daarna. Al toegelaten toepassingen blijven dan starten, mits de containerregistry van de cel, de naamvoorziening en de geheimen beschikbaar zijn; nieuwe versies kunnen dan niet worden ondertekend.
De toetsen Uitval van het vlootbeheer en Toelatingscontrole van software beproeven dit.
Het vlootbeheer rolt de toelatingscontrole op ieder cluster eerst uit in de stand melden, gedurende een proefperiode met einddatum, en zet haar na beproeving op afdwingen: eerst in de proefgroep, dan per uitrolgolf. Een wijziging van toelatingsbeleid of vertrouwensbasis volgt dezelfde volgorde.
Beproefd in de toets Gefaseerde uitrol met proefgroep. Een nieuw cluster gaat pas naar de afnemer als het nalevingsoverzicht ‘voldoet’ toont.
De toelatingscontrole staat alleen op melden in de proefperiode en als terugvaloptie voor de golf die een uitrol raakt. Na het afdwingen kan melden alleen als goedgekeurde uitzondering met einddatum voor een benoemd cluster of beeld, ten hoogste 14 dagen; het knooppunt blijft dan afdwingen.
De bevoegde verantwoordelijke besluit over de uitzondering, die in het uitzonderingsregister staat. Gecontroleerd met het uitrolverslag, het register en de melding van iedere toelating met waarschuwing.
Weigert de toelatingscontrole ten onrechte software, dan gaat het beleid voor de betrokken software of clusters tijdelijk terug naar melden, als goedgekeurde uitzondering met einddatum; de controle bij het ophalen op het knooppunt blijft werken. Een ongeldige versie wordt ingetrokken door in de gewenste inrichting het vorige inhoudskenmerk terug te zetten, mits die versie nog is vrijgegeven; de clusters keren dan cluster voor cluster terug tot het vlootbeheer geen afwijking meer meldt.
Iedere weigering en iedere toelating met waarschuwing gaat naar het SOC, onder de detectieregel voor een poging om niet-ondertekende of onbekende software te starten. Uitval van de controle, een stille logbron of een verwijderde toelatingswebhook valt onder de detectieregel voor uitval of uitschakeling van een beveiligingsvoorziening. Weigeringen staan in de audit van de clusterbesturing en in het logboek van CRI-O op het knooppunt.
Het SOC volgt beide detectieregels op; reactietijden en drempels staan bij de meetwaarden.
Bij de acceptatie weigeren en melden beide controlepunten afzonderlijk: een niet-ondertekend beeld, een beeld uit de quarantaine of uit een andere containerregistry, een beeld in een ruimte met de sleutel van een andere ruimte en een beeld van derden vóór de toelating of na de einddatum, ook als de ondertekenvoorziening onbereikbaar is. Een toegelaten beeld van derden start wel.
Dit is de toets Toelatingscontrole van software, samen met het SOC uitgevoerd in de acceptatieproef Softwareketen.
De toeleveringsketen is beschermd met ondertekende containerbeelden, vertrouwde containerregistries en toelatingscontroles die niet-ondertekende of onveilige artefacten blokkeren. De integriteit van de configuratie wordt bewaakt met compliancecontrole en de machineconfiguratie.
Eisen uit de referentieset securityeisen. Deze keten dekt de eerste; de tweede ligt vooral bij de baseline van de clusters: compliancecontrole tegen het baselineprofiel, integriteitsbewaking van knooppunten en het terugzetten van wijzigingen buiten versiebeheer. Zie het domein vlootbeheer.