Beveiliging bij runnerhut

Isolatie

• Eén taak, één microVM, met een eigen kernel – nooit een container op een gedeelde kernel
• De VM wordt vernietigd aan het einde van de taak; schijven worden cryptografisch gewist en niet hergebruikt
• Cacheobjecten worden gecodeerd en per repository gelimiteerd
• Geen operatorshell-toegang tot actieve taak-VM's

Naleving

• SOC 2 Type 2, jaarlijks gecontroleerd, rapport beschikbaar onder geheimhoudingsverklaring
• Jaarlijkse penetratietest door derden
• AVG DPA met gepubliceerde subverwerkers en een opzegtermijn van 30 dagen
• Gegevenslocatie in de EU en de VS voor rekenkracht, cache, logs en statistieken

Toegang en identiteit

• Kan worden geïntegreerd als een GitHub App met specifieke installatietokens - nooit een persoonlijk toegangstoken
• SAML- en OIDC SSO met SCIM-inrichting
• Alleen-toevoegend auditlogboek met SIEM-export
• Standaard beleid voor uitgaand weigeren beschikbaar per hardlopergroep

Wat een gecompromitteerde baan wel en niet kon bereiken

De moeite waard om duidelijk te stellen, omdat het de vraag is die een recensent feitelijk stelt. Een taak draait in zijn eigen microVM met zijn eigen kernel, dus ontsnappen naar de host is de harde grens in plaats van een containernaamruimte. Het kan het netwerk bereiken, tenzij een uitgaand beleid dit beperkt. Daarom is het standaard weigeren van uitgaand verkeer belangrijker dan de meeste controles. Het kan de cache van een andere tenant niet lezen, omdat cacheobjecten per repository worden gecodeerd. Het kan niet blijven bestaan, omdat de VM en de bijbehorende schijf aan het einde van de taak worden vernietigd.

Waar het restrisico feitelijk zit

• Jouw workflow: GITHUB_TOKEN met teveel toestemming, acties van derden losgemaakt, pull_request_target met een checkout van het PR-hoofd
• Uw afhankelijkheden: een gecompromitteerd post-install-script wordt uitgevoerd met welke netwerktoegang de runner ook heeft
• Jouw geheimen: alles wat in een taak wordt gedecodeerd, is zichtbaar voor de code die in die taak wordt uitgevoerd, inclusief code die is ingetrokken

We kunnen de tweede en derde beperken met uitgaand beleid en kortstondige inloggegevens. De eerste is van jou, en de beveiligingschecklist van GitHub Actions behandelt deze in vijf wijzigingen.