Pipelines erhalten nur die Secrets, die Sie freigeben
Ein Service-Token entsteht in Ihrem Browser und wird einmal angezeigt, der Server behält nur seine öffentlichen Schlüssel. Geben Sie ihm die Umgebungen frei, die eine Pipeline braucht, und fügen Sie eine OIDC-Bindung hinzu, damit es nur im richtigen Repository und Branch funktioniert.
- Tokens lesen nur, was Sie freigeben
- OIDC-Bindung für GitHub, GitLab und Bitbucket
- Die Produktion kann ganz außerhalb von CI bleiben
Ein Token, das nicht mehr öffnet, als Sie ihm gegeben haben
Ein crunu_svc_-Token wird vollständig im Browser des Admins erzeugt und einmal angezeigt. Es liest nur die Umgebungen, die Sie freigeben: Ein Token für development erhält den Schlüssel von production nie.
- Lease, Nutzungen und NetzwerkeGeben Sie einem Token eine Lease, ein Nutzungslimit von 1 bis 1.000.000 Nutzungen und die Netzwerke, aus denen es kommen darf.
- An Ihr Repository gebundenMit einer OIDC-Bindung funktioniert das Token nur zusammen mit dem Token Ihres CI-Anbieters für das Repository, den Branch und die Deployment-Umgebung, die Sie gewählt haben. Ein erneut vorgelegtes Token des Anbieters wird abgewiesen.
- Jede Nutzung wird protokolliertAnmeldungen und Abweisungen von Tokens erscheinen im Audit-Log, und ein erneut vorgelegtes CI-Token löst eine Warnung aus.
Drei Zeilen in der Pipeline
Hinterlegen Sie das Token in den geheimen Variablen Ihres CI als CRUNU_TOKEN, installieren Sie eine festgelegte Version von crunu und führen Sie den Schritt über crunu run aus. Die Variablen werden im Arbeitsspeicher entschlüsselt, auf die Festplatte wird nichts geschrieben.
- Feste Version, geprüfte InstallationDie App zeigt den Installationsbefehl mit exakten Prüfsummen aus dem signierten Release-Manifest.
- Fertige BausteineEine GitHub Action, ein GitLab-Template und eine Bitbucket-Pipe installieren eine festgelegte Version und prüfen ihre SHA-256-Prüfsumme.
- Exit-Codes werden durchgereicht
crunu rungibt den Exit-Code des gestarteten Programms zurück, ein fehlschlagender Test lässt den Schritt also weiterhin scheitern.
Was jedes CI-System prüfen kann
In GitHub Actions, GitLab CI und Bitbucket Pipelines findet der Agent das Token des CI-Anbieters selbst. Jedes andere CI funktioniert mit einem Token in seinen Secrets.
| CI-System | Die OIDC-Bindung prüft | Einbindung |
|---|---|---|
| GitHub Actions | Repository, Ref, Deployment-Umgebung | Action setup-crunu, in Ihr Repository kopiert |
| GitLab CI | Projektpfad, Ref, Ref-Typ, Deployment-Umgebung | Vorlagen .crunu und .crunu-oidc |
| Bitbucket Pipelines | Repository, Branch, Deployment-Umgebung | Eine Pipe für crunu run, das Image bauen Sie selbst |
| Beliebiger OIDC-Anbieter | Beliebiger Aussteller, Schlüssel über OIDC Discovery | Token und crunu run |
| Jedes CI ohne OIDC | Nur das Token | Token und crunu run |
Halten Sie die Produktion aus der Pipeline heraus
Die empfohlene Einrichtung schickt Produktions-Secrets nie durch CI. Der Agent läuft auf der Produktionsmaschine, und die Pipeline startet den Dienst nur neu.
- Die Maschine holt sich ihre Werte selbstDer Produktionsserver ist als Maschine registriert und erhält seine Umgebung direkt.
- CI startet nur neuDer Deploy-Schritt startet den Dienst neu.
crunu run --restart on-changestartet ihn außerdem neu, wenn sich Werte ändern. - Wenn CI doch an die Produktion mussVerwenden Sie ein eigenes Produktions-Token mit OIDC-Bindung, freigegeben von einem Owner, und jede Auslieferung steht im Audit-Log.
Was Sie vor dem Anbinden wissen sollten
Tokens halten die Produktion außer Reichweite. Manche Teile der CI-Anbindung sind noch Rezepte statt Schaltflächen.
- Die Bausteine stehen in keinem MarketplaceKopieren Sie die GitHub Action in Ihr Repository, und bauen und veröffentlichen Sie das Image der Bitbucket-Pipe selbst.
- Keine eingebaute Synchronisierung mit PlattformenKeine Integration überträgt Werte nach Vercel, Cloudflare, AWS Secrets Manager oder GitHub Secrets. Der dokumentierte Weg ist ein Rezept mit crunu run.
- Der Schritt liest, was er bekommtAlles, was im Job läuft, sieht die Variablen, die es erhält. Geben Sie so wenige Umgebungen wie möglich frei.
- Produktions-Tokens bindenEin Token ohne OIDC-Bindung funktioniert von jeder erlaubten Adresse aus, bis es widerrufen wird oder seine Lease oder sein Nutzungslimit erreicht.
Häufige Fragen
Noch etwas anderes? Schreiben Sie an support@crunu.com
Kann ein nach außen gelangtes Token die Produktion lesen?
Nur, wenn Sie ihm production freigegeben haben. Ein Token für development erhält den Schlüssel von production nie. Mit einer OIDC-Bindung funktioniert ein nach außen gelangtes Token überhaupt nicht ohne das Token Ihres CI-Anbieters für das richtige Repository und den richtigen Branch.
Brauche ich OIDC?
Nein. Jedes CI kann ein Service-Token verwenden, das in seinen Secrets hinterlegt ist. OIDC fügt eine zweite Prüfung hinzu, die das Token an Ihr Repository und Ihren Branch bindet.
Wo wird das Token gespeichert?
In den geheimen Variablen Ihres CI. Der Server behält nur die öffentlichen Schlüssel des Tokens. Deshalb wird es einmal angezeigt und lässt sich nicht wiederherstellen.
Lässt sich ein Token auf wenige Nutzungen beschränken?
Ja. Legen Sie ein Nutzungslimit zwischen 1 und 1.000.000 Nutzungen fest, dazu eine Lease und erlaubte Netzwerke.
Kann Crunu Variablen nach Vercel oder Cloudflare übertragen?
Nicht über eine eingebaute Synchronisierung. Sie können es aus einem Pipeline-Schritt mit crunu run und dem Befehl der Plattform erledigen, mit einem OIDC-gebundenen Token.
Holen Sie Produktions-Secrets aus Ihrer Pipeline
Erstellen Sie ein Token für eine einzelne Staging-Umgebung und führen Sie Ihre Tests mit crunu run aus.