Onderwerp
Nog niet bevestigd door een mens. Eigenaar: vdo89. Bron in de atlas
Ondertekening maakt de herkomst van software controleerbaar. Een onafhankelijke besturing van het platform tekent het resultaat van iedere bouw of toelating, met de onderdelenlijst en de herkomstverklaring, en registreert dat in een eigen transparantielogboek. Dit onderwerp legt vast wie tekent, met welke sleutels, waar de ondertekenvoorziening staat en in welke formaten handtekeningen en attesten worden bewaard.
Een bouwtaak voert ongecontroleerde code uit; als zij zelf zou tekenen, zou een handtekening niets bewijzen. Daarom tekent een besturing buiten de naamruimten van teams, met sleutels die het geheimenbeheer niet verlaten en per ruimte verschillen. Het eigen transparantielogboek maakt misbruik zichtbaar zonder internettoegang. Ondertekenen zonder langlevende sleutel volgt in groeipadstap 2, na kwalificatie, omdat de benodigde onderdelen eerst moeten zijn beproefd.
De sleutelopslag, de terugvalopties en de formaten zijn een voorstel.
Het platform verklaart de herkomst, niet de bouwtaak: een onafhankelijke besturing van het platform ondertekent resultaat, onderdelenlijst en herkomstverklaring. Geen bouwtaak of pijplijn van een team heeft een ondertekensleutel.
Een herkomstverklaring is alleen iets waard als een besturing die de bouwtaak niet kan beïnvloeden, haar afgeeft.
Iedere vrijgegeven versie van eigen software en van software van derden heeft een handtekening, een onderdelenlijst en een herkomstverklaring of toelatingsattest, en die zijn vóór de vrijgave geregistreerd in het transparantielogboek.
De controle in de containerregistry, het transparantielogboek en de toets Herleidbaarheid van software tonen het aan. De belofte Herleidbare software en gerichte reparaties rust erop.
In de eerste levering tekent de Chains-besturing van OpenShift Pipelines, buiten de naamruimten van teams, met een bouwsleutel die alleen zij kan gebruiken. In groeipadstap 2 volgt, na kwalificatie in de leeromgeving, ondertekenen zonder langlevende sleutel: de pijplijn vraagt met haar eigen applicatie-identiteit een kortlevend ondertekencertificaat aan bij de ondertekenvoorziening, zodat iedere handtekening herleidbaar is tot de bouw die haar zette.
Zie groeipadstap 2. Tot de overgang registreert de ondertekenvoorziening de handtekeningen en geeft zij tijdstempels.
De Chains-besturing in de naamruimte openshift-pipelines tekent via de sleutelbeheerkoppeling (KMS) met de niet-exporteerbare bouwsleutel in de transit-engine van OpenBao in cel 1, zodat de sleutel het geheimenbeheer niet verlaat. Chains legt de herkomst van taak- en pijplijnresultaten vast in het formaat in-toto, slaat die als OCI-artefact op en registreert haar in het transparantielogboek.
Red Hat documenteert voor Chains alleen de formaten in-toto en slsa/v1, die hetzelfde opleveren. Ondertekenen via de transit-engine is een voorwaarde bij de acceptatie. Lukt het niet, dan tekenen Chains en de toelatingsroute met een sleutel in een clustergeheim van hun eigen naamruimte, als goedgekeurde uitzondering met einddatum.
Vanaf groeipadstap 2 tekent Chains sleutelloos tegen de Fulcio van Trusted Artifact Signer, met de SPIFFE-identiteit van de pijplijn uit Zero Trust Workload Identity Manager op het bouwcluster. De knooppunten krijgen dan FulcioCAWithRekor in plaats van een publieke sleutel. De overgang loopt per uitrolgolf; de bouwsleutel blijft voor de versies die ermee zijn ondertekend.
Sleutelloos ondertekenen schrapt de langlevende ondertekeningssleutel, maar de sleutels van Fulcio, Rekor en TUF blijven te beschermen; de operator vervangt ze niet zelf, de beveiligingsbeheerder doet dat. Slaagt de kwalificatie vóór groeipadstap 2 niet, dan blijft de bouwsleutel in gebruik.
Fulcio tekent met een eigen tussen-CA ‘ondertekening’ van PKI-beheer onder de interne RWS-PKI, met een naambeperking tot het SPIFFE-vertrouwensdomein van het bouwcluster. De sleutel staat in het geheimenbeheer van cel 1 en is alleen bruikbaar voor Fulcio; de tussen-CA komt vóór de overgang in de vertrouwensbasis.
Zo blijft de tussen-CA per cel ongemoeid. Vervanging gaat zoals bij een tussen-CA per cel; zie het domein geheimen.
syft maakt een onderdelenlijst in CycloneDX; de bouwtaak hangt haar ongetekend aan het beeld in de quarantaine, en de Chains-besturing tekent haar als attest mee. Zo heeft geen teamnaamruimte een sleutel nodig.
Dat Chains de onderdelenlijst meetekent, is een voorwaarde bij de acceptatie; de terugvaloptie is dat Chains het inhoudskenmerk van de lijst opneemt in de herkomstverklaring die zij tekent.
Iedere ruimte heeft één eigen sleutel, zonder overlap: de bouwsleutel alleen voor vrijgegeven eigen software, de toelatingssleutel alleen voor software van derden en de sleutel van de leverancier voor de spiegel. Op ieder controlepunt geldt één beleid per ruimte.
Een gelekte sleutel raakt zo één route. Afgewezen: één sleutel voor bouw en toelating; één lek opent dan beide routes, en het beleid kan de ruimtes niet scheiden.
De ondertekeningssleutels zijn niet-exporteerbaar en ieder door één identiteit bruikbaar: de Chains-besturing alleen de bouwsleutel, de toelatingsidentiteit alleen de toelatingssleutel, zodat geen bouwtaak of pijplijn van een team er een kan gebruiken. Alleen de beveiligingsbeheerder maakt en vervangt een ondertekeningssleutel, met een verhoging via de beheerwerkplek; iedere andere poging wordt geweigerd en staat in de audit van OpenBao.
Een ongebruikelijke opvraging valt onder de detectieregel voor ongebruikelijke opvraging van geheimen.
Een ondertekeningssleutel wordt jaarlijks en na een incident vervangen. De nieuwe publieke sleutel staat in de vertrouwensbasis voordat ermee wordt getekend; de oude blijft erin tot de laatste daarmee ondertekende versie weg is.
Het draaiboek voor sleutelvervanging wordt geoefend.
De ondertekenvoorziening, Red Hat Trusted Artifact Signer met een eigen transparantielogboek, draait als geïsoleerde dienst op het vlootcluster, buiten de naamruimten van teams. Clusters controleren handtekeningen zonder internet, en de metagegevens van de ondertekening blijven bij RWS.
Het is een vlootbrede rol met eigen maatregelen. Afgewezen: het publieke transparantielogboek van Sigstore, dat internettoegang vraagt en metagegevens buiten RWS brengt, en ondertekenen met alleen sleutels, waarbij misbruik van een sleutel onzichtbaar blijft.
Trusted Artifact Signer staat in eigen naamruimten op het vlootcluster vl-01, zonder toegang voor teams: Rekor met externe opslag, een tijdstempeldienst, TUF en Fulcio, dat vanaf groeipadstap 2 in gebruik is. De opstelling is hoog beschikbaar, met drie werkerknooppunten, een externe PostgreSQL-database op CloudNativePG en aanmelding via OIDC met Keycloak.
De hoge beschikbaarheid vraagt OpenShift 4.17 of hoger en drie werkerknooppunten.
Chains registreert iedere handtekening en verklaring in de Rekor van Trusted Artifact Signer; de vrijgave volgt pas na een bevestigde registratie. Mislukt de ondertekening of de registratie, dan blijft het beeld in de quarantaine.
Zo wordt misbruik van een ondertekensleutel zichtbaar. Het team krijgt een melding van een mislukte ondertekening of registratie, bij herhaling ook platformbeheer. In groeipadstap 2 toont de toets Herstel na een aanval met een gecompromitteerd vlootbeheer dat misbruik van de ondertekening in het logboek zichtbaar wordt.
Valt de ondertekenvoorziening uit, dan is er geen registratie en dus geen vrijgave; bestaande handtekeningen blijven controleerbaar via de bundel bij het beeld. Gaan logboekgegevens verloren, dan volgt herstel uit de back-up, anders een nieuw logboek met een nieuwe sleutel in de vertrouwensbasis; de oude sleutel blijft daarin staan.
De ondertekenvoorziening herstelt met het vlootcluster, met haar gegevens volgens het back-upschema. Het draaiboek wordt in de leeromgeving beproefd.
Beelden en artefacten volgen de OCI-specificatie, attesten het formaat in-toto, eigen onderdelenlijsten CycloneDX en handtekeningen de bundel van Sigstore.
Trusted Profile Analyzer leest daarnaast SPDX. Zie de ontwerpkeuze Open standaarden en overdraagbare configuratie.
Aanvullende handtekeningen en attesten staan in het oude bundelformaat, omdat de Policy Controller van Trusted Artifact Signer 1.4 geen OCI 1.1-referrers leest en de nieuwe handtekeningen van Cosign 3 niet vindt. De overstap naar het nieuwe formaat volgt pas als alle controleurs dat lezen.
Het bundelformaat is een grens van het product; zie eerst controleurs, dan ondertekenaars.