Scheid automatisering en persoonlijk beheer
Een rapportage-API-pipeline moet een goedgekeurd artefact selecteren en een gecontroleerde release-actie aanroepen. Dat vereist niet automatisch het aanmaken van gebruikers, het wijzigen van facturering of het lezen van elk applicatiegeheim. Begin met een machtigingsinventaris en een beschermde testomgeving; houd inloggegevens buiten documenten, repositories en voorbeeldlogboeken.
Menselijke hersteltoegang moet gescheiden blijven, zodat het intrekken van een deploy-inloggegeven niet het enige onderzoekspad verwijdert. Identificeer een geautoriseerde beheerder en onafhankelijke hostverificatie. Een tweede onbeperkte sleutel is een ander inloggegeven, geen nauwere rol.
Beschrijf de toegestane bewerking precies
| Mogelijkheid | Nodig? | Grens |
|---|---|---|
| Goedgekeurd artefact lezen | Ja | Specifieke repository/versie |
| Release-actie aanroepen | Ja | Vaste app en omgeving |
| Elk runtime-geheim lezen | Vermijden | Gecontroleerde runtime-identiteit |
| Gebruikers of SSH-beleid wijzigen | Nee | Gescheiden beheer |
| Workflowconfiguratie wijzigen | Nee voor runtime-identiteit | Beschermde repository-review |
| Back-ups verwijderen | Nee | Gescheiden herstelmachtigingen |
Valideer de invoer van de release-actie. Een beperkt commando dat willekeurige tekst samenvoegt tot een geprivilegieerde shell, staat nog steeds onbedoeld werk toe. Beoordeel wrapper-gedrag, beschrijfbare paden en artefactvertrouwen samen. Brede sudo-privileges of toegang tot de Docker-socket kunnen de beoogde grens ondermijnen.
Behandel workflowbewerkingen als toegang tot inloggegevens
Iemand die vertrouwde workflowstappen kan wijzigen, kan diens referenties gebruiken of blootstellen. Controleer repositorymachtigingen, beschermde implementatieomgevingen en welke gebeurtenissen taken met verhoogde rechten uitvoeren. Houd productiereferenties weg van niet-vertrouwde pull-requestcode. Geef een workflowtoken alleen de machtigingen die de taak nodig heeft.
GitHub raadt volledige commit-SHA-pinning aan voor onveranderlijke actieselectie. Controleer de geselecteerde actie en latere updates; een versietag kan verschuiven. Voeg geen niet-vertrouwde gebeurtenisgegevens rechtstreeks in inline shellcode in. Het maskeren van bekende geheime waarden is geen garantie tegen openbaarmaking via transformaties, logs of artefacten.
Technische referentie: Veilig gebruik van GitHub Actions.
Gebruik een korte levensduur wanneer de bestemming dit ondersteunt
OpenID Connect kan een ondersteunde bestemming workflowidentiteit laten inruilen voor een kortlevende referentie. Configureer vertrouwenscontroles voor de beoogde repository, branch of omgeving en audience. Dit is noch een universele SSH-vervanging, noch een functie die door de huidige PrivacyNodes-frontend wordt geleverd.
Als je implementatie SSH gebruikt, controleer dan de authorized-key-opties van het geïnstalleerde pakket. Een geforceerd commando alleen verbiedt forwarding niet; beperkingen moeten de beoogde toegangspaden dekken en nog steeds een veilige release-operatie aanroepen. Test in een aparte omgeving. Behoud werkende beheer- en herstelt oegang tijdens het wijzigen van authenticatie, en verifieer een nieuwe onafhankelijke verbinding voordat je de oude methode verwijdert.
Technische referentie: GitHub Actions OpenID Connect · OpenSSH authorized_keys-indeling.
Test toegestaan en verboden werk
Verifieer dat de identiteit het beoogde artefact kan selecteren, de release kan aanroepen en een bruikbaar resultaat kan verkrijgen. Test vervolgens de grenzen: geheimen van een andere applicatie, niet-gerelateerde bestandswijzigingen en willekeurig beheer moeten niet beschikbaar zijn. Neem artefactpaden en argumenten op die de wrapper moet weigeren.
Leg identiteit, scope, vervaldatum waar van toepassing, goedkeurende maintainer en locatie van auditbewijs vast. Bewaar opslagreferenties in plaats van referentiewaarden. Als een test alleen werkt na het verlenen van breed beheer, heroverweeg dan de releaset aak in plaats van die stilzwijgend de permanente rol te maken.
Oefen intrekking en een release met een kapotte pipeline
Bereid een vervanging voor met de gecontroleerde scope, verifieer een testimplementatie, schakel de pipeline om en trek de oude identiteit in. Bevestig dat de vervangen referentie mislukt en dat er geen duplicaat in een andere workflow achterblijft. Alleen een nieuwe sleutel toevoegen verwijdert eerdere toegang niet.
Documenteer hoe een bevoegde maintainer de implementatie stopt en herstelt wanneer CI niet beschikbaar is. Koppel die procedure aan de releaseregistratie en herstelinventaris. Een beperkte referentie beperkt de beoogde bevoegdheid; het maakt een kwaadwillig artefact niet ongevaarlijk.
Officiële referenties
Documentatie is beoordeeld voor dit artikel. Voorbeelden zijn plannings-oefeningen, geen commando's die op een PrivacyNodes-server zijn getest. Controleer de documentatie voor uw geïnstalleerde versie.