· Kubernetes  · 2 Min. Lesezeit

Wenn der einzige Zugang die Rancher-Shell ist

Manche Umgebungen geben keinen direkten Cluster-Zugang her: kein kubeconfig, kein kubectl von außen, nur die Kubectl-Shell in Rancher. Das ist unbequem, aber eine sinnvolle Einschränkung, und man kann sehr sauber damit arbeiten.

Manche Umgebungen geben keinen direkten Cluster-Zugang her: kein kubeconfig, kein kubectl von außen, nur die Kubectl-Shell in Rancher. Das ist unbequem, aber eine sinnvolle Einschränkung, und man kann sehr sauber damit arbeiten.

Es gibt Umgebungen, die keinen direkten Cluster-Zugang herausgeben. Kein kubeconfig zum Herunterladen, kein kubectl vom eigenen Rechner, kein Ping auf die Nodes. Der einzige Weg führt über die Kubectl-Shell in der Rancher-Oberfläche. Das ist beim ersten Mal frustrierend, aber es ist eine bewusste und gute Einschränkung, und ich kann diszipliniert damit arbeiten.

Warum das gut ist

Ein kubeconfig ist ein dauerhafter Generalschlüssel. Es liegt auf einem Laptop, wandert in ein Backup, landet versehentlich in einem Repo. Fällt der Zugang über Rancher, gibt es dieses Artefakt nicht: Jeder Zugriff läuft über die authentifizierte, protokollierte Oberfläche, und der Entzug erfolgt zentral. Die Angriffsfläche schrumpft spürbar, weil es keinen wandernden Schlüssel mehr gibt.

Wie ich damit arbeite

In einer Web-Shell tippe ich nicht mal eben zwanzig Befehle. Die Arbeitsweise, die sich bewährt hat: fertige, vorab geprüfte Copy-Paste-Blöcke, ein Befehl pro Block, damit ich sie einzeln und kontrolliert absetze. Und strikt getrennt: erst die lesenden Befehle (get, describe) zur Diagnose, dann bewusst die schreibende Aktion. Kein kubectl apply aus dem Gedächtnis, kein „schnell mal“ an der Produktion.

Ergebnisse einsammeln ohne Shell

Komme ich nicht direkt in einen Pod, hole ich Ausgaben über den Umweg: ein kurzer Job, der sein Ergebnis in die Termination-Message schreibt, oder die Logs über die Oberfläche. Ich gewöhne mir an, Ausgaben deklarativ und nachvollziehbar einzusammeln, statt interaktiv im laufenden System herumzustochern.

Ehrlich: langsamer, und das ist Teil des Sinns

Diese Arbeitsweise bremst, keine Frage. Aber ein Teil dieser Reibung ist gewollt. Sie zwingt dazu, jeden Schreibzugriff vorher zu durchdenken und zu formulieren, statt im Cluster zu experimentieren. Für Produktionsumgebungen mit echten Daten ist genau das die richtige Reibung. Bequemlichkeit und Sicherheit ziehen hier in verschiedene Richtungen, und in der Produktion gewinnt die Sicherheit.

Sie wollen, dass Zugriffe auf Ihre Systeme nachvollziehbar und eng geführt sind, statt an Schlüsseln zu hängen, die überall herumliegen? Ich richte Zugriffswege ein, die kontrolliert und protokolliert sind, und arbeite selbst diszipliniert darin. Mehr unter IT-Beratung, das Erstgespräch ist unverbindlich.

Alex Jabi, Jabi IT

Alex Jabi

Ich betreue IT, Informationssicherheit und Datenschutz für KMU und Praxen an der Bergstraße und im Odenwald, persönlich, dokumentiert und ohne Cloud-Zwang.

Mehr über mich
Zurück zum Blog

Passende Artikel

Alle Artikel »
Secrets im Git, aber verschlüsselt: SOPS in der Praxis

Secrets im Git, aber verschlüsselt: SOPS in der Praxis

GitOps heißt, alles steht in Git. Passwörter und Token eben nicht, ein Klartext-Secret im Repo ist ein Leak mit Historie. Wie SOPS Secrets verschlüsselt, ohne dass sie undiffbar werden, und wie ein Operator sie im Cluster wieder entschlüsselt.