We kennen allemaal de impact van containertechnologie en hoeveel deze technologie (steeds meer) gebruikt wordt. Ongeveer vijf jaar geleden ben ik begonnen met het gebruik van Azure en Kubernetes.
Ik had nog niet veel ervaring met containers, laat staan met containerbeveiliging. Toen ik eindelijk op het punt kwam dat ik Kubernetes enigszins door had en ermee begon te werken begon ik me ook te verdiepen in het beveiligingsvraagstuk.
Nu mensen en bedrijven steeds meer vertrouwd raken met de technologie hoop ik dat zij ook meer gaan nadenken over de beveiliging met betrekking tot containertechnologie.
Containers zijn standaard NIET veilig!
Bovenstaande afbeelding beschrijft de architectuur van containertechnologie en we kunnen hier vijf kerncomponenten uit afleiden:
- Container Image
- Container Registry
- Container Orchestrator
- Container (Instance van een image)
- Server/ Host/ Node (Besturingssysteem)
In deze blog ga ik dieper in op het eerste component, namelijk de container image en hoe je risico’s kunt beperken door je images te scannen.
Container Image Risico’s
Het eerste belangrijke onderdeel is dus de container image. Het National Institute of Standards and Technology (NIST) beschrijft de volgende risico’s met betrekking tot container images:
- Kwetsbaarheden in images (bijv. het missen van kritieke updates)
- Configuratie fouten in een image (bijv. een image dat als root draait)
- Embedded malware in een image
- Secrets als tekst in een image (bijv. gebruikersnaam/wachtwoord of ssh keys)
- Onbetrouwbare images (bijv. niet officiële images)
Om dieper in te gaan op alle risico’s en tegenmaatregelen die je kunt nemen, kun je de NIST Application Container Security Guide raadplegen. Een van de tegenmaatregelen is het scannen van je container images tijdens build fase, in de registry en als de container met uw applicatie draait.
In deze blog ga ik laten zien hoe je risico’s kunt beperken door je image te scannen tijdens de build fase met Github Actions en door de images in de Azure Container Registry te scannen. Het scannen van je images via Github Actions is eenvoudig in te stellen en kost niets, er is geen Enterprise-product voor nodig.
Images scannen
GITHUB ACTIONS
We zullen Github Actions gebruiken om onze images te scannen. Het Microsoft Azure-team heeft een containerscan action ontwikkeld dat trivy en dockle gebruikt. Deze action scant je images op kwetsbaarheden en adviseert over de best practices met betrekking tot het bouwen van container images.
VEREISTEN
- Je hebt een Github account. Je kunt er hier één aanmaken als je nog geen account hebt.
- Je hebt een Azure account. Je kunt een gratis account aanmaken met $200 aan credits.
- Je hebt git geïnstalleerd.
- Je hebt vscode (of een andere editor) geïnstalleerd.
- Je hebt kennis van/ ervaring met git en met het werken op de command line
- Je hebt kennis van/ ervaring met Github en Github Actions
OPZETTEN OMGEVING
- Maak een nieuwe repository aan in Github
- Clone de repository lokaal
- Voeg de volgende bestanden toe aan de repository
- Push de nieuwe bestanden naar je Github repository
Zodra je de wijzigingen naar Github hebt gepusht, begint de workflow. Ga naar het tabblad Actions en klik op de actieve workflow. Je ziet een resultaat zoals hieronder wanneer het is voltooid:
Als je op vulnerability_scan > vulnerability_scan klikt dan zie je een gedetailleerd overzicht van alle kwetsbaarheden die gevonden zijn:
Als je op [container-scan] testimage: klikt dan krijg je een samenvatting van alle CVE’s per “Severity” en CIS benchmark “Best practices”:
Je kunt zo de CVE’s/ CIS best practices opzoeken en dan krijg je te zien wat de oplossing is (als die er is) om de kwetsbaarheid te verhelpen.
CONFIGURATIE IMAGE SCANNER
Severity-Threshold
Je kunt de scan action configureren door aan te geven vanaf welke severity level er gekeken en teruggekoppeld moet worden. Als je het op Medium zet zie je in de feedback in de action alleen kwetsbaarheden van Medium en hoger. De beschikbare levels zijn UNKNOWN, LOW, MEDIUM, HIGH en CRITICAL.
Continue-on-error
Als je je workflow/ pipeline wilt laten falen als er kwetsbaarheden gevonden zijn die gelijk zijn of hoger dan de “Severity-Thresshold” dan moet je continue-on-error op false zetten. Op die manier kun je er voor zorgen dat een logische volgende stap “Push image naar je registry” niet gebeurd en er dus geen images met een bepaalde severity level in je container registry komen.
De feedback van deze workflow draagt bij aan de Shift Left Security beweging, waarbij we in een zo vroeg mogelijk stadium security gerelateerde bevindingen willen achterhalen en oplossen (waar mogelijk) om zo geld en tijd te besparen!
NEGEREN VAN CVE’S
Mochten er nou toch CVE’s tussen zitten die niet op te lossen zijn en je accepteert de risico’s dan kun je een lijst toevoegen met toegestane CVE’s.
Je maakt het bestand .github/containerscan/allowedlist.yaml aan in je repository en in dat bestand kun je bijvoorbeeld zetten: allowedlist.yaml.
Op het moment van schrijven is er een preview feature waarbij je Defender for DevOps kunt connecten met je Github Actions. De action “microsoft/security-devops-action@preview” gebruikt onder water ook Trivy om je container te scannen.
DEFENDER FOR CONTAINERS
Als je image gebouwd, gescand en naar de container registry is gepusht, dan wil je dat de images ook gescand worden in de registry zelf. Je image kan op het moment van pushen alle kritische updates en geen enkele CVE bevatten, maar dat kan een dag later heel anders zijn. Hiervoor kunnen we Defender for Containers (DfC) gebruiken! DfC gebruikt Qualys om de images te scannen.
Er zijn meerdere situaties waarbij DfC getriggerd wordt om images te scannen, namelijk:
- Bij een push naar de container registry
- Een wekelijkse scan van images die in de afgelopen 30 dagen zijn gepulled
- Bij een import van een image van bijvoorbeeld de Docker Registry naar de Azure Container Registry
- Continue scan
- Is op pull basis (zie wekelijkse scan)
- Een continue scan van images die draaien op je AKS cluster, deze scan werkt alleen als er een security profiel is aangemaakt.
OPZETTEN OMGEVING
- Maak een Azure Container Registry aan en push een image naar de registry
- Volg deze instructie om Defender for Containers aan te zetten
Als je registry is aangemaakt, je image gepusht is en Defender for Containers aan staat dan kun je aan de slag en kun je kijken welke kwetsbaarheden er gevonden zijn door DfC.
Ga in de Azure portal naar de aanbevelingen voor container registry images, je ziet dan onderstaand scherm:
Als je onder “Affected Resources” doorklikt op je Container Registry dan krijg je een overzicht van images die kwetsbaarheden bevatten:
Als je dan op het image en de digest doorklikt dan zie je de exacte CVE’s de gevonden zijn. In de kolom Patch Available zie je ook gelijk of er een oplossing voor de kwetsbaarheid is.
NEGEREN VAN CVE’S
Mochten er nou CVE’s tussen zitten die niet op te lossen zijn en je accepteert de risico’s dan kun je een regel aanmaken in DfC die dan een CVE negeert. Die regel kun je aanmaken op basis van onderstaande parameters:
Samenvatting
Als we naar container technologie kijken dan zijn er vijf core componenten, namelijk container image, container registry, container orchestrator, container instance en container host.
Alle vijf de core componenten brengen risico’s met zich mee. Één van die componenten is de container image zelf met het risico op kwetsbaarheden. Om die kwetsbaarheden zichtbaar te krijgen/maken kun je je image scannen tijdens de bouw fase, in de container registry en als een container instance met je applicatie draait.
In deze korte technische blog heb ik laten zien hoe je je image tijdens de bouw fase kunt scannen door middel van Github Actions en hoe je je image in een container registry kunt scannen met behulp van Defender for Containers.
