Versionsverwaltung: GitLab 14.5 entlässt den Kubernetes-Agenten in die Freiheit
Die CI/CD-Plattform bringt neue Security-Features und erweitert den Kubernetes-Agenten auf die Free-Editionen.
(Bild: Romolo Tavani/Shutterstock.com)
Pünktlich ist GitLab 14.5 mit über 40 Neuerungen erschienen. Das November-Release widmet sich unter anderem der Anbindung an die Container-Orchestrierung Kubernetes und führt Sicherheitsscans für Infrastructure as Code (IaC) ein. Für Premium- und Ultimate-Nutzer gibt es zusätzliche Features wie die Verwaltung von Merge Requests auf dem Gruppenlevel.
Kubernetes-Agent fĂĽr alle Nutzer
GitLab 14.5 stellt den GitLab Kubernetes Agent, der bisher nur für zahlende Nutzerinnen und Nutzer verfügbar war, auch für GitLab Free zur Verfügung. Das gilt sowohl für die SaaS-Edition (Software as a Service) als auch für die auf eigenen Servern gehostete (self-managed). Der GitLab Kubernetes Agent war erstmals in GitLab 13.4 mit an Bord und dient dem Orchestrieren von Kubernetes-Clustern. Die zertifikatbasierte Anbindung an Kubernetes entfällt zugunsten des Agenten, da diese laut GitLab potenzielle Sicherheitsrisiken mit sich brachte.
Allerdings macht GitLab nicht alle Funktionen des Kubernetes-Agenten frei verfügbar, sondern diese bleiben teilweise den kostenpflichtigen Editionen vorbehalten – unter anderem Sicherheitswarnungen und GitOps-Deployments. Details zur Verfügbarkeit der Features finden sich in der Dokumentation.
Neue Sicherheitsfunktionen
Ebenfalls fĂĽr alle GitLab-Nutzer steht das neue Security-Scanning von Konfigurationsdateien fĂĽr Infrastructure as Code (IaC) zur VerfĂĽgung. Es basiert auf dem Open-Source-Projekt Keeping Infrastructure as Code Secure (KICS) und besitzt eine mit GitLab SAST (Static Application Security Testing) vergleichbare Funktionsweise. Die IaC-Security-Scans lassen sich derzeit auf Terraform-, Ansible-, AWS-CloudFormation- und Kubernetes-Dateien ausfĂĽhren.
Einzig Ultimate-Nutzern erlaubt GitLab, die Regeln für Vulnerability Checks feiner abzustufen. Damit lässt sich nun definieren, welche Scanner, Schweregrade und Arten von Schwachstellen beim Auslösen einer Regel zu berücksichtigen sind. Zudem lässt sich eine Mindestanzahl der so definierten Schwachstellen festlegen, ab der ein Merge Request eine Zustimmung (Approval) erfordert. Das soll Entwicklungs- und Security-Teams entlasten.
Für das nächste Release plant das GitLab-Team bereits weitere Security-Features: So sollen Nutzerinnen und Nutzer der Ultimate-Edition manuelle Vulnerability-Aufzeichnungen erstellen sowie benutzerdefinierte Regeln der Analyzer für SAST und Secret Detection festlegen können.
Weitere Neuerungen
In den Premium- und Ultimate-Editionen lassen sich auf dem Gruppenlevel Werte festlegen, um Merge Requests durchzuführen. Diese Werte gehen auf alle Projekte über, die sich in der jeweiligen Gruppe befinden, sodass ein manuelles Überprüfen der Einstellungen in den einzelnen Projekten entfällt. Zunächst in Version 13.9 eingeführt, war das Feature bisher standardmäßig deaktiviert und verbarg sich hinter dem Flag group_merge_request_approval_settings_feature_flag. In GitLab 14.5 ist es standardmäßig aktiviert.
Auch die Usability hat das GitLab-Team mit Neuerungen bedacht, unter anderem tauchen Jobs auf der CI/CD-Seite nun in chronologischer Reihenfolge auf. Die UI Polish Gallery zeigt eine grafische Ăśbersicht der Neuerungen am User Interface.
Alle weiteren Informationen zu GitLab 14.5 bietet ein Blogeintrag.
(mai)
