GitHub führt cache-mode allgemein ein, eine Einstellung, die dem Cache von Actions-Workflows das Prinzip der geringsten Rechte auferlegt. Der Zweck ist handfest: Cache-Poisoning über Branch-Grenzen hinweg schließen, ohne die Build-Zeiten zu verlängern.
Ein geteilter Cache ist eine Angriffsfläche
Der Actions-Cache beschleunigt die Continuous Integration, indem er Abhängigkeiten und Artefakte zwischen Läufen aufbewahrt. Seine Suchlogik überschreitet Branch-Grenzen: Ein Lauf stellt zuerst einen Eintrag aus dem eigenen Branch wieder her, greift dann auf den Standard-Branch zurück und bei einem Pull-Request-Auslöser auf den Basis-Branch, auch aus einem geforkten Repository. Diese weite Reichweite ist bequem, öffnet aber eine Lücke: Ein nicht vertrauenswürdiger Beitrag kann einen Cache-Eintrag schreiben, den später ein vertrauenswürdiger Workflow wiederverwendet. Das ist Cache-Poisoning, jahrelang mit sorgfältig präfixierten Schlüsseln und selbstgebauten Prüfungen auf den am stärksten gehärteten selbstgehosteten Servern behandelt.
Vier Modi, zwei Standardwerte
Die Einstellung besteht aus einem Schlüsselwort, das beschreibt, was ein Lauf mit dem Cache tun darf. Zwei Standardwerte greifen automatisch, je nachdem, wie vertrauenswürdig der Auslöser ist.
| Modus | Wiederherstellen | Schreiben | Standard für |
|---|---|---|---|
read | ja | nein | wenig vertrauenswürdige Ereignisse (pull_request_target) |
write | ja | ja | vertrauenswürdige Ereignisse (push) |
write-only | nein | ja | Cache-Vorwärmung |
none | nein | nein | vollständige Isolation |
Pro Workflow oder pro Job setzen
Der Schlüssel steht am gesamten Workflow oder an einem einzelnen Job, wobei der Job-Wert den Workflow-Wert übersteuert. Das empfohlene Muster: den Workflow auf reines Wiederherstellen stellen und Schreibrechte nur Jobs gewähren, die von einem vertrauenswürdigen Branch ausgelöst werden.
name: CI
on: [push, pull_request]
# Default for every job: restore from cache, never write to it
cache-mode: read
jobs:
test:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: actions/cache@v4
with:
path: ~/.npm
key: npm-${{ hashFiles('package-lock.json') }}
- run: npm ci && npm test
warm-cache:
if: github.ref == 'refs/heads/main'
runs-on: ubuntu-latest
# Only trusted pushes to main are allowed to repopulate the cache
cache-mode: write
steps:
- uses: actions/checkout@v4
- uses: actions/cache@v4
with:
path: ~/.npm
key: npm-${{ hashFiles('package-lock.json') }}
- run: npm ciEin Job, der nie in den Cache schreiben muss, sollte es auch nie dürfen.
Vererbung in wiederverwendbaren Workflows
Der Modus wird vom Cache-Dienst erzwungen, nicht nur vom Runner. Er wird an wiederverwendbare Workflows weitergereicht: Ein aufgerufener Workflow erhält nie mehr Zugriff, als sein Aufrufer gewährt. Teams, die ihre Integrationskette in gemeinsamen Workflows bündeln, erben so eine konsistente Rechteobergrenze, ohne auf die Wachsamkeit jedes nutzenden Repositorys angewiesen zu sein.
write oder write-only bei einem wenig vertrauenswürdigen Ereignis zu deklarieren, öffnet genau das Risiko wieder, das die Einstellung schließen soll. GitHub fügt in diesem Fall eine Warnannotation hinzu; ein Workflow ohne Angabe behält die sicheren Standardwerte.
Das Wesentliche
Die Cache-Zugriffssteuerung steht jetzt in jedem Tarif ohne Vorkonfiguration bereit. Gut abgestimmte Projekte werden keine Änderung bemerken, da die Standardwerte der bereits geltenden Vertrauenslogik folgen. Der Gewinn liegt bei allen, die mit heiklen Auslösern oder externen Beiträgen arbeiten: Sie bekommen endlich einen ausdrücklichen Regler statt eines selbstgebauten Behelfs. Die eigenen CI-Workflows auf Jobs zu prüfen, die ohne Not schreiben, dauert wenige Minuten und entfernt eine ganze Angriffsklasse.
Mir sind mehr als eine Pipeline begegnet, in der ein Pull-Request-Job in denselben Cache schreiben konnte wie der Hauptbranch, allein durch vererbte Konfiguration. Wir haben das von Hand geflickt, mit präfixierten Schlüsseln und einer guten Portion Hoffnung. Ein deklarativer, dienstseitig erzwungener Modus ist genau das Detail, das die Gelassenheit eines Security-Reviews verändert. Ich stelle meine Repositories diese Woche standardmäßig auf read. — Simon Janvier
Zum Weiterlesen: die offizielle Ankündigung im GitHub Changelog und die Dokumentation zum Dependency-Caching.
