GitHub Actions-cache beveiligen

Een dependencycache versnelt builds door bestanden tussen jobs en workflowruns te hergebruiken. Diezelfde opslag kan beveiligingsgrenzen oversteken. Wanneer een job met weinig vertrouwen inhoud kan opslaan onder een key die later door een vertrouwde release wordt hersteld, kan ongecontroleerde data invloed krijgen op code met deploymentcredentials of productieartefacten.

GitHub beschermt triggers met een lager vertrouwensniveau standaard met alleen-lezen toegang. Een expliciete instelling voor schrijven of alleen schrijven kan die bescherming echter overschrijven. GitHub plaatst dan een waarschuwing in de workflow. De uiteindelijke beoordeling blijft bij het team, want alleen daar is bekend welke code draait, welke cachekeys overlappen en welke bevoegdheden de volgende job heeft.

Cache poisoning beperkt zich niet tot een zichtbare cache-action. Integraties van package managers, setup-actions en herbruikbare workflows kunnen de Actions-cache namens een job gebruiken. Een goede controle begint daarom bij de effectieve rechten en alle gebruikers van de opgeslagen data, niet bij één opvallende YAML-stap.

Classificeer eerst iedere job. Een validatiejob voor een externe bijdrage kan genoeg hebben aan een alleen-lezen dependencycache, of helemaal geen gedeelde cache wanneer herstelde data gevoelige analyse kan beïnvloeden. Een vertrouwde build op de hoofdbranch kan lees- en schrijftoegang nodig hebben om een cache voor latere runs te publiceren. Een producer die nooit eerdere data mag gebruiken, kan alleen-schrijven krijgen, mits de cachekeys zorgvuldig zijn ontworpen.

Houd cacherechten los van repository- en deploymentrechten. Een job die productie kan deployen, hoeft niet automatisch naar de cache te schrijven omdat beide taken na een merge plaatsvinden. Door build, validatie en release te scheiden, wordt duidelijk waar onvertrouwde inhoud stopt en welke stap het artefact maakt dat productie bereikt.

Leg voor herbruikbare workflows een expliciet contract vast. De aanroepende workflow bepaalt de maximale cachetoegang, terwijl de gedeelde workflow beschrijft welke jobs herstellen of opslaan. Zo kan een latere wijziging aan de gedeelde workflow niet ongemerkt het cachegedrag verruimen voor iedere repository die haar gebruikt.

Inventariseer eerst het huidige cachegebruik. Noteer workflowtriggers, aanroepen naar herbruikbare workflows, cache-actions, caching via package managers en keys die branches of events met elkaar delen. Breng daarna de huidige effectieve standaard van GitHub in kaart. Zo worden workflows zichtbaar die op schrijfrechten vertrouwen zonder die uit te spreken.

Voer cache-mode gefaseerd in. Begin bij jobs waarvan de juiste rechten geen twijfel oproepen en controleer daarna de workflowlogs op overgeslagen restores en saves. GitHub behandelt een geblokkeerde restore als een cache miss en een geblokkeerde save als informatie. De workflow kan dus groen blijven terwijl de buildtijd of actualiteit van de cache verandert. Valideer daarom ook gedrag en doorlooptijd.

Test na de uitrol de vertrouwensgrens met representatieve pull requests en releases vanaf de hoofdbranch. Bevestig dat onvertrouwde runs geen cache kunnen opslaan die door bevoorrechte jobs wordt gebruikt, dat herbruikbare workflows het bedoelde maximum erven en dat een cache miss nog steeds een volledige build oplevert. Documenteer uitzonderingen zodat gemak de releaseketen later niet ongemerkt verzwakt.