Security-Anbieter KnowBe4 hostet seinen Code selbst und deployt schneller

Security Awareness Training im globalen Maßstab

KnowBe4, Inc. betreibt die weltweit größte Plattform für Security Awareness Training und simulierte Phishing-Angriffe. Mit interaktiven On-Demand-Schulungen hilft KnowBe4 Zehntausenden Organisationen, sich gegen Social Engineering zu wappnen. Im Gartner Magic Quadrant 2019 für Security Awareness CBT wurde KnowBe4 in den Kategorien "Ability to Execute" und "Completeness of Vision" am höchsten bewertet.

Komplexe Toolchain bremst Innovation und Releases

Das Engineering-Team von KnowBe4 hat in seiner Deployment-Toolchain drei getrennte Tools eingesetzt: eines für das Code-Management, eines für das Testen und eines für das Deployment. Die Arbeit war dadurch über mehrere Systeme verstreut. Jedes Tool hatte für sich seinen Wert, doch die fehlende Integration hat für zusätzlichen Aufwand und Stress gesorgt. "Jedes Deployment hat Jobs in unterschiedlichen Tools angestößen. Tests liefen an einer Stelle, Deployments an einer anderen. Wir hatten ständig Kontextwechsel, und weil alles parallel lief, kam nie eine wirklich durchgängige Pipeline zustande", sagt Alex Callihan, VP of Platform Engineering bei KnowBe4. "Tests konnten fehlschlagen, obwohl das Deployment schon längst durch war. Genau das war das Problem. Mit GitLab haben wir diesen Prozess in einem einzigen Tool zusammengeführt und sichergestellt, dass die Pipeline in der richtigen Reihenfolge abläuft."

Außerdem wollte das Team die Kosten senken, die der Betrieb von drei Plattformen pro Toolchain verursacht hat. Beim bisherigen Test-Tool hat jede zusätzliche parallele Testkapazität extra gekostet. Wer skalieren wollte, musste also jedes Mal die Mehrkosten einkalkulieren. "Bei unserem alten Test-Tool mussten wir alles auf die Spitzenlast auslegen. Brauchten wir auch nur einmal 50 parallele Tests, mussten wir für 50 zahlen, und zwar rund um die Uhr, jeden Tag. Bei 50 parallelen Tests waren das rund 50 Dollar pro Test und Monat, obwohl wir diese Kapazität außerhalb unserer Kernarbeitszeiten kaum gebraucht haben", sagt Matthew Duren, Principal Site Reliability Engineer.

KnowBe4 hat deshalb nach einem einzigen Tool mit durchgängiger Transparenz gesucht. Ohne ständige Kontextwechsel zwischen verschiedenen Tools, so die Überlegung, würde auch die Deployment-Geschwindigkeit deutlich steigen. Weitere Anforderungen an die neue Lösung:

• Selbstverwalteter Betrieb (Self-Managed)
• Hosting in AWS
• Integration mit Jira, Docker und weiteren Tools nach Bedarf
• Skalierbarkeit der Git-Lösung im Gleichschritt mit Belegschaft und Services

Erster Release noch während des Proof of Concept

Duren und Callihan kannten GitLab bereits aus der kostenlosen Version. Diese Vertrautheit mit der Plattform hat den Ausschlag gegeben, GitLab den Stakeholdern vorzuschlagen.

Die beiden wollten, dass das übrige Unternehmen das volle Leistungsspektrum der Plattform kennenlernt. Für den Proof of Concept haben sie deshalb ein einzelnes Produkt aus ihrer Projektliste gewählt, das innerhalb eines Monats ausgeliefert werden musste. "Wir haben zufällig ein Produkt gewählt, das in einem Monat fertig sein musste. Ausgeliefert haben wir es auf GitLab, noch während der Testphase", so Callihan.

Den Stakeholdern war vor allem wichtig, dass der Code aus Sicherheitsgründen im Haus bleibt. Genau das hat GitLab möglich gemacht. "Mit dem Wachstum unseres Unternehmens ist die Einhaltung mehrerer Compliance-Standards zu einem zentralen Ziel unserer Entwicklungs- und Informationssicherheits-Teams geworden. Die Sicherheitsfunktionen von GitLab und die Möglichkeit, die Plattform in unserer eigenen Infrastruktur zu hosten, waren ein starkes Argument für die Freigabe des Proof of Concept", sagt Callihan.

Effizienter Betrieb, integrierte Sicherheit, mehr Deployments

GitLab ist das Herzstück des Software-Entwicklungszyklus bei KnowBe4. Entwickler(innen) legen zunächst in GitLab einen Feature-Branch vom master-Branch an. Anschließend stellen sie über GitLab-Pipelines bei Bedarf eine eigene Entwicklungsumgebung bereit. Sobald die Qualitätssicherung die Entwicklungsumgebung als funktionsfähig bestätigt hat, erstellen sie einen Merge Request für den master-Branch. Alle Commits durchlaufen Test-Pipelines, bis der Merge Request genehmigt und schließlich gemergt ist. Nach dem Merge startet eine Pipeline, die das Docker-Image baut und in AWS bereitstellt. Danach folgt eine Deployment-Phase, die mit Terraform das jeweils neueste Image in die Produktion bringt. Orchestriert wird all das von GitLab Runnern in AWS, vollständig protokolliert und nachvollziehbar. Jede Anwendung geht heute mehr als fünfmal täglich in Produktion, in den Entwicklungsumgebungen sogar mehr als 20-mal. Über alle Anwendungen hinweg laufen täglich Hunderte bis Tausende Test-Jobs.

Die Teams haben den Entwicklungszyklus für mehr als 60 Microservices standardisiert. "Dank dieser Standardisierung ist es sehr einfach, neue Projekte zu starten oder Fehler in bestehenden zu beheben. Jeder bei uns weiß, wie ein Projekt gebaut, released und ausgeliefert wird, egal welche Codebasis oder welches Design dahintersteckt", sagt Callihan. "Mit Docker, Terraform und GitLab, zusammengeführt in GitLab-Pipelines, haben wir ein äußerst effizientes System aufgebaut." Durch mehrere parallele Test-Pipelines sowie selbst bereitgestellte und automatisch skalierende Runner hat das Team außerdem die Zeit bis zur Produktion verkürzt.

Die Continuous Integration von GitLab hilft, Bugs abzufangen, bevor Code in die Produktion gelangt. Sicherheitsmodule sind fest in die Test-Pipelines eingebunden: Schlagen sie an, gilt das als fehlgeschlagener Test, die Pipeline bricht ab und anfälliger Code wird gar nicht erst deployt. Mehr zu integrierten Sicherheitspraktiken im DevSecOps-Ansatz.

Da KnowBe4 bereits eine moderne Architektur hatte, konnte GitLab dem Unternehmen helfen, schneller auszuliefern und auch spezielle Anforderungen umzusetzen. Alle Teams arbeiten heute mit demselben Tooling zusammen, ob bei Code Reviews, Pipelines oder Code Ownership. Die Einführung ist unkompliziert verlaufen, weil das Tool einfach zu bedienen ist. Auch die YAML-Konfiguration von GitLab haben alle Teams schnell übernommen.

"Seit das Test-, Build- und Deployment-Tooling direkt in den Anwendungs-Repositories liegt, können Entwickler(innen) ihre eigenen Deployment-Pipelines aufbauen und verwalten. Das SRE-Team muss die Änderungen nur noch prüfen und freigeben", sagt Duren. "Mit dieser vergleichsweise einfachen Umstellung deployen wir Änderungen deutlich häufiger, als es sonst möglich gewesen wäre. Wir haben einen großen Engpass beseitigt, den Entwicklungszyklus beschleunigt und für reibungslosere Abläufe zwischen unserem Team und dem übrigen F&E-Bereich gesorgt."

Noch mehr GitLab-Erfolgsgeschichten

Wie Unternehmen aus dem DACH-Markt GitLab in der Praxis einsetzen: Hier weiterlesen