Maak Je Pipelines Waterdicht: Best Practices voor Reliability en Security

CI/CD-pipelines vormen het kloppend hart van elke moderne DevOps-omgeving. Ze zorgen voor een soepele softwarelevering, als een goed geoliede machine. Maar zelfs de beste machines hebben regelmatig onderhoud en veiligheidsmaatregelen nodig om storingen te voorkomen. 

In de wereld van CI/CD zijn die maatregelen je betrouwbaarheids- en securitystrategieën. Een slecht ontworpen pipeline kan leiden tot allerlei onaangename verrassingen: deployment errors, beveiligingslekken en veel slapeloze nachten. In deze blogpost delen we inzichten uit de praktijk, gebaseerd op onze ervaring, om je te helpen robuuste CI/CD-workflows te bouwen en te optimaliseren. 

Reliability: Hoe Je Pipelines Bouwt Waarop Je Kunt Vertrouwen 

Betrouwbare pipelines ontstaan niet vanzelf. Het vereist zorgvuldige planning en een toewijding om risico’s te minimaliseren en consistente prestaties te garanderen. Hier zijn enkele belangrijke lessen die we hebben geleerd bij het opzetten van betrouwbare pipelines. 

Ten eerste: behandel je actions en steps als elk ander stuk code: voorzie ze van een versie! Of je nu GitHub Actions of Azure Pipelines gebruikt (we gaan hier later dieper op in), het vastpinnen van je actions en steps aan specifieke tags biedt een basisniveau van zekerheid. Voor maximale zekerheid dat de inhoud van de action ongewijzigd blijft, is het echter aan te raden om vast te pinnen aan een commit SHA, omdat deze immutable zijn. 

Vertrouw bij het versioneren niet alleen op main of latest – dit zijn bewegende doelen. Gebruik in plaats daarvan vaste versies om te garanderen dat je pipeline exact de code gebruikt die je hebt getest en goedgekeurd. GitHub heeft bijvoorbeeld onlangs aangekondigd dat de ubuntu-latest tag overschakelt van ubuntu-22.04 naar ubuntu-24.04, wat problemen kan veroorzaken die je eenvoudig kunt vermijden. 

Net als je actions en steps, moet je ook de versie specificeren van de runners (GitHub Actions) of agents (Azure Pipelines) die je pipelines uitvoeren. Dit betekent dat je je pipelines configureert om specifieke versies van de runner- of agent image te gebruiken, vergelijkbaar met hoe je actions en steps aan tags of commit SHA’s vastpint. Specificeer exact de versie die je wilt gebruiken. Dit ogenschijnlijk kleine detail kan compatibiliteitsproblemen voorkomen die worden veroorzaakt door updates van de onderliggende infrastructuur. 

Naast versiebeheer zijn code reviews niet alleen voor applicatiecode. Je pipelines verdienen dezelfde mate van aandacht. Eis peer reviews en goedkeuringen voor alle pipeline wijzigingen. Dit extra paar ogen kan potentiële fouten opvangen, consistentie waarborgen en de best practices van je team versterken.  

Als je GitHub Actions gebruikt, overweeg dan om GitHub Apps te gebruiken voor authenticatie in plaats van Personal Access Tokens (PAT’s). In tegenstelling tot PAT’s verlopen GitHub Apps niet, waardoor je niet steeds tokens hoeft te vernieuwen en verstoringen van je pipelines worden voorkomen. Bovendien zijn de tokens die door GitHub Apps worden gegenereerd minder gevoelig voor lekken. Let op: het is cruciaal om de private key die aan je GitHub App is gekoppeld veilig te beheren, omdat een gelekte private key een aanzienlijk risico vormt. 

Voor belangrijke pipelines of custom-ontwikkelde actions, overweeg het toevoegen van unit tests. Ja, pipelines kunnen ook unit tests hebben! Deze extra validatielaag verifieert dat je workflows werken zoals bedoeld en vangt potentiële problemen op voordat ze de productie bereiken. Dit biedt niet alleen bescherming voor je pipelines, maar ook voor alle code of infrastructuur die binnen je CI/CD-workflows wordt beheerd. 

Security: Bescherm Je CI/CD Workflows 

Je pipelines verwerken gevoelige gegevens en hebben toegang tot je infrastructuur, dus het is essentieel dat ze goed beveiligd zijn. 

In GitHub Actions is het belangrijk om voorzichtig te zijn met third-party actions. We raden aan om het gebruik te beperken tot actions die door GitHub zijn geverifieerd, of nog beter, om een allow list van goedgekeurde actions binnen je organisatie te maken. Dit minimaliseert het risico op het uitvoeren van niet-vertrouwde of mogelijk schadelijke code. Als je een Github Enterprise gebruiker bent, kun je dit hier instellen: 

Houd altijd het principe van least privilege in gedachten als het gaat om pipeline permissions. Verleen alleen de absolute minimale toegang die je pipelines nodig hebben om te functioneren. Tools zoals de Monitor en Advisor Actions van GitHub kunnen je helpen om het juiste niveau van toegang te bepalen en het gebruik ervan bij te houden. 

Tot slot is secret scanning onmisbaar om te voorkomen dat gevoelige informatie in je repositories terechtkomt. Als je Azure Pipelines gebruikt, integreer dan secret scanning in je pipelines om automatisch geheimen te detecteren en te markeren die per ongeluk in je code zijn geslopen. Met GitHub Advanced Security (ook beschikbaar voor Azure DevOps) kun je een stap verder gaan: je kunt commits die geheimen bevatten blokkeren, zodat ze niet in versiebeheer terechtkomen en blootstelling wordt voorkomen. 

GitHub Actions vs. Azure Pipelines 

Hoewel de meeste best practices in het algemeen gelden, hebben GitHub Actions en Azure Pipelines elk hun eigenaardigheden en terminologie, met name in hoe ze deployments structureren. Beide platforms gebruiken bijvoorbeeld het concept van environments (zoals development, testing, production), maar implementeren deze verschillend. Azure Pipelines gebruikt het concept “stages” om jobs te groeperen, en environments worden binnen deze stages gedefinieerd. In GitHub Actions worden environments meestal op jobniveau gedefinieerd, zonder expliciete stages. 

Hoe je ze ook noemt, het is cruciaal om control gates of checks in elke stage/environment te implementeren. Dit zorgt ervoor dat deployments alleen doorgaan wanneer aan specifieke voorwaarden is voldaan, zoals het slagen van tests of het ontvangen van goedkeuringen. Dit helpt voorkomen dat ongeteste of niet-goedgekeurde wijzigingen je gebruikers bereiken. 

GitHub Actions is over het algemeen transparanter met zijn actions, omdat ze vaak open-source en openbaar auditbaar zijn. Azure DevOps extensions kunnen wat meer gesloten zijn, hoewel veel tegenwoordig naar openbare GitHub repositories linken. Ongeacht het platform is het cruciaal om te begrijpen wat je actions of steps daadwerkelijk doen om security en betrouwbaarheid te waarborgen. Vertrouw niet blindelings op iets! 

Wil je een diepgaandere vergelijking? We hebben de verschillen tussen GitHub en Azure DevOps behandeld in een eerdere blogpost, “Azure DevOps vs. GitHub: Which Should You Choose?“. Lees het als je dieper in de nuances van elk platform wilt duiken. 

Conclusie 

Betrouwbare en veilige pipelines zijn essentieel voor elke succesvolle DevOps-organisatie. Door de praktijken die we hebben besproken te implementeren, bouw je robuuste CI/CD-workflows waarop je kunt vertrouwen. 

In de volgende blogpost verschuiven we onze focus van security en betrouwbaarheid naar snelheid, en delen we efficiëntietips om je pipelines een boost te geven en je opleveringsproces te versnellen. 

Wil je GitHub Actions of Azure DevOps in je workflow integreren? Stuur ons een bericht, we helpen je graag!