Kubernetes

Zugriff auf private Cluster ohne Bastion

Ein Agent läuft im Cluster als Routing-Gerät. Entwicklerinnen und CI erreichen Dienste und die API über ihren Namen. Die Identität entscheidet, nicht eine Adresse.

Kostenlos starten Dokumentation lesen

Kostenloser Tarif · Ohne Kreditkarte · Ein Agent im Cluster zählt als ein Gerät

Das Problem

Um einen privaten Cluster wächst meist eine Bastion

Sperren Sie die API ab, baut jemand einen Weg zurück hinein.

Das Problem

Eine Bastion vor der API

Eine weitere Box zum Patchen, ein weiterer Satz SSH-Schlüssel und eine Allow-Liste, die veraltet.

Was an die Stelle tritt

Ein Agent im Cluster

Der Cluster tritt demselben Netzwerk bei wie die Menschen, die ihn nutzen. Kein Zwischenschritt, also kein Sprungserver.

Das Problem

Ein öffentlicher Endpunkt für CI

Die API liegt auf einer öffentlichen Adresse, damit die Pipeline sie erreicht. Scanner finden sie zuerst.

Was an die Stelle tritt

Nur ausgehend, auch für CI

Der Runner tritt mit einem wiederverwendbaren Registrierungsschlüssel bei, auf dem temporäre Geräte eingeschaltet sind. Sein Eintrag verschwindet, sobald er sich nicht mehr verbindet. Nichts auf dem Weg hat eine öffentliche Adresse.

So funktioniert es

Einen Agent betreiben, eine Regel schreiben

Keine Änderung am Cluster-Netzwerk und kein Ingress für den administrativen Zugriff.

Einen Agent im Cluster betreiben

Ein Container führt den Agent aus, mit einem persistenten Volume für seine Identität, registriert über einen Registrierungsschlüssel. Er wählt sich nach außen, es öffnet sich kein eingehender Port.

Mehr erfahren

Über den Namen erreichen

API-Server und jeder Dienst sind benannte Ressourcen, kein Pod-CIDR. Sie werden im Netzwerk über ihren Namen aufgelöst; kein Port-Forward, das im Terminal offen bleibt.

Mehr erfahren