Mit Sammlungen den Überblick behalten
Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.
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 ein mehrschichtiges Sicherheitskonzept („Defense in Depth“) zu ermöglichen.
Was Sie bedenken sollten
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:
Schreiben von Messwerten in Stackdriver
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.
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. Stellen Sie Kf in einem dedizierten Projekt ohne Zugriff auf Produktionsressourcen bereit. Entwickler brauchen 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. Verwenden Sie Kubernetes-Ressourcenkontingente.
[[["Leicht verständlich","easyToUnderstand","thumb-up"],["Mein Problem wurde gelöst","solvedMyProblem","thumb-up"],["Sonstiges","otherUp","thumb-up"]],[["Schwer verständlich","hardToUnderstand","thumb-down"],["Informationen oder Beispielcode falsch","incorrectInformationOrSampleCode","thumb-down"],["Benötigte Informationen/Beispiele nicht gefunden","missingTheInformationSamplesINeed","thumb-down"],["Problem mit der Übersetzung","translationIssue","thumb-down"],["Sonstiges","otherDown","thumb-down"]],["Zuletzt aktualisiert: 2025-08-31 (UTC)."],[],[],null,["# Security overview\n\nKf aims to provide a similar developer experience to Cloud Foundry, replicating the build, push, and deploy lifecycle. It does this by building a developer UX layer on top of widely-known, broadly used and adopted technologies like Kubernetes, Istio, and container registries rather than by implementing all the pieces from the ground up.\n| **Note:** Kf should be used in a Google Cloud project dedicated to your evaluation. See [Important considerations](#important_considerations) for more information.\n\nWhen making security decisions, Kf aims to provide complete solutions that are native to their respective components and can be augmented with other mechanisms. Breaking that down:\n\n- **Complete solutions** means that Kf tries not to provide partial solutions that can lead to a false sense of security.\n- **Native** means that the solutions should be a part of the component rather than a Kf construct to prevent breaking changes.\n- **Can be augmented** means the approach Kf takes should work seamlessly with other Kubernetes and Google Cloud tooling for defense in depth.\n\nImportant considerations\n------------------------\n\nIn addition to the [Current limitations](#current_limitations) described below, it is important that you read through and understand the items outlined in this section.\n\n### Workload Identity\n\nBy default, Kf uses [Workload Identity](/kubernetes-engine/docs/how-to/workload-identity) to provide secure delivery and rotation of the Service Account credentials used by Kf to interact with your Google Cloud project. Workload Identity achieves this by mapping a Kubernetes Service Account (KSA) to a Google Service Account (GSA). The Kf controller runs in the `kf` namespace and uses a KSA named `controller` mapped to your GSA to do the following things:\n\n1. Write metrics to Stackdriver\n2. When a new Kf space is created (`kf create-space`), the Kf controller creates a new KSA named `kf-builder` in the new space and maps it to the same GSA.\n3. The `kf-builder` KSA is used by Tekton to push and pull container images to Google Container Registry (gcr.io)\n\nThis diagram illustrates those interactions:\n\n### Current limitations\n\n- Kf doesn't provide pre-built RBAC roles. Until\n Kf provides this, use\n [RBAC](/kubernetes-engine/docs/how-to/role-based-access-control).\n\n- A developer pushing an app with Kf can also create\n Pods (with `kubectl`) that can use the `kf-builder` KSA with the permissions\n of its associated GSA.\n\n- Deploying to Kf requires write access to a container\n registry. Deploy Kf in a dedicated project without\n access to production resources. Grant developers access to push code to the\n Artifact Repository by\n [granting them `roles/storage.admin`](/container-registry/docs/access-control)\n on the project or buckets that Artifact Repository uses.\n\n- Kf uses the same Pod to fetch, build, and store images.\n Assume that any credentials that you provide can be known by the authors and\n publishers of the buildpacks you use.\n\n- Kf doesn't support quotas to protect against noisy\n neighbors. Use Kubernetes\n [resource quotas](https://kubernetes.io/docs/concepts/policy/resource-quotas/).\n\nOther resources\n---------------\n\n### General\n\n- [GKE security overview](/kubernetes-engine/docs/concepts/security-overview)\n- [GKE cluster multi-tenancy](/kubernetes-engine/docs/concepts/multitenancy-overview)\n- [Workload Identity](/kubernetes-engine/docs/how-to/workload-identity)\n- [GKE and IAM policies](/kubernetes-engine/docs/how-to/iam)\n\n### Recommended protections\n\n- [Protecting cluster metadata](/kubernetes-engine/docs/how-to/protecting-cluster-metadata)\n- [Role-based access control](/kubernetes-engine/docs/how-to/role-based-access-control)\n\n### Advanced protections\n\n- [GKE Sandbox](/kubernetes-engine/docs/how-to/sandbox-pods)\n- [Network policies](/kubernetes-engine/docs/how-to/network-policy)"]]
