Sicherheit

Kf soll eine ähnliche Entwicklungsumgebung wie Cloud Foundry bieten und den Build-, Push- und Deployment-Lebenszyklus replizieren. Dabei wird eine UX-Entwicklungsebene auf der Grundlage bekannter, weit verbreiteter und übernommener Technologien wie Kubernetes, Istio und Container Registrys erstellt, anstatt alle Teile von Grund auf zu implementieren.

Für Sicherheitsentscheidungen möchte Kf vollständige, für die jeweiligen Komponenten native Lösungen bereitstellen, die mit anderen Mechanismen erweitert werden können. Dies bedeutet im Einzelnen:

  • Vollständige Lösungen bedeutet, dass Kf versucht, keine partiellen Lösungen bereitzustellen, die ein falsches Gefühl von Sicherheit vermitteln.
  • Nativ bedeutet, dass die Lösungen ein Teil der Komponente und kein Kf-Konstrukt sein sollten, um funktionsgefährdende Änderungen zu vermeiden.
  • Möglichkeit der Erweiterung bedeutet, dass das Kf-Konzept nahtlos in andere Kubernetes- und Google Cloud-Tools eingebunden werden kann, um einen tief greifenden Schutz zu ermöglichen.

Wichtige Aspekte

Zusätzlich zu den unten beschriebenen aktuellen Einschränkungen ist es wichtig, dass Sie die in diesem Abschnitt beschriebenen Punkte lesen und verstehen.

Workload Identity

Standardmäßig nutzt Kf Workload Identity, um eine sichere Bereitstellung und Rotation der Anmeldedaten für das Dienstkonto zu ermöglichen, die von Kf für die Interaktion mit Ihrem Google Cloud-Projekt verwendet werden. Workload Identity erreicht dies, indem es ein Kubernetes-Dienstkonto (KSA) einem Google-Dienstkonto (GSA) zuordnet. Der Kf-Controller wird im Namespace kf ausgeführt und verwendet ein Ihrer GSA zugeordnetes KSA namens controller für folgende Aufgaben:

  1. Schreiben von Messwerten in Stackdriver
  2. Wenn ein neuer Kf-Bereich (kf create-space) erstellt wird, erstellt der Kf-Controller in diesem Bereich ein neues KSA mit dem Namen kf-builder und ordnet es demselben GSA zu.
  3. Das KSA kf-builder wird von Tekton verwendet, um Container-Images per Push und Pull an Google Container Registry (gcr.io) zu übertragen und daraus abzurufen.

Dieses Diagramm veranschaulicht diese Interaktionen:

Aktuelle Einschränkungen

  • Kf bietet keine vordefinierten RBAC-Rollen. Verwenden Sie RBAC so lange, bis die Bereitstellung durch Kf erfolgt.

  • Ein Entwickler, der eine Anwendung mit Kf per Push überträgt, kann auch Pods (mit kubectl) erstellen, die das kf-builder-KSA mit den Berechtigungen des zugehörigen GSA verwenden können.

  • Für die Bereitstellung in Kf ist Schreibzugriff auf eine Container-Registry erforderlich. Bereitstellen von Kf in einem dedizierten Projekt ohne Zugriff auf Produktionsressourcen. Gewähren Sie Entwicklern Zugriff, um per Push Code in das Artefakt-Repository zu übertragen. Gewähren Sie ihnen dazu roles/storage.admin für das Projekt oder für Buckets, die vom Artefakt-Repository verwendet werden.

  • Kf verwendet zum Abrufen, Erstellen und Speichern von Images denselben Pod. Es wird davon ausgegangen, dass die angegebenen Anmeldedaten den Autoren und Publishern der von Ihnen verwendeten Buildpacks bekannt sein dürfen.

  • Kf unterstützt keine Kontingente zum Schutz vor „Noisy Neighbor“-Effekten. Kubernetes-Ressourcenkontingente verwenden.

Andere Ressourcen

Allgemein

Erweiterte Sicherheit