Mantieni tutto organizzato con le raccolte
Salva e classifica i contenuti in base alle tue preferenze.
Kf mira a fornire un'esperienza di sviluppo simile a Cloud Foundry, replicando il ciclo di vita di build, push ed esecuzione del deployment. A tal fine, crea un livello UX per gli sviluppatori su tecnologie ampiamente conosciute, utilizzate e adottate come Kubernetes, Istio e i registry dei container, anziché implementare tutti i componenti da zero.
Panoramica sulla sicurezza
Quando prende decisioni in materia di sicurezza, Kf mira a fornire soluzioni complete native dei rispettivi componenti e che possono essere integrate con altri meccanismi. Vediamo nel dettaglio:
Per soluzioni complete si intende che Kf cerca di non fornire soluzioni parziali che possono creare un falso senso di sicurezza.
Nativo significa che le soluzioni devono far parte del componente anziché di un costrutto Kf per evitare modifiche che causano interruzioni.
Può essere aumentato significa che l'approccio adottato da Kf dovrebbe funzionare perfettamente con altri strumenti Kubernetes e Google Cloud per la difesa in profondità.
Considerazioni importanti
Oltre alle limitazioni attuali descritte di seguito, è importante leggere e comprendere gli elementi descritti in questa sezione.
Workload Identity
Per impostazione predefinita, Kf utilizza Workload Identity per fornire il caricamento e la rotazione sicuri delle credenziali dell'account di servizio utilizzate da Kf per interagire con il tuo Google Cloud progetto. Workload Identity lo ottiene mappando un account di servizio Kubernetes (KSA) a un account di servizio Google (GSA). Il controller Kf viene eseguito nello spazio dei nomi kf e utilizza un KSA denominato controller mappato al tuo GSA per eseguire le seguenti operazioni:
Scrivere metriche in Stackdriver
Quando viene creato un nuovo spazio Kf (kf create-space), il controller Kf crea un nuovo KSA denominato kf-builder nel nuovo spazio e lo mappa alla stessa GSA.
Il token kf-builder KSA viene utilizzato da Tekton per eseguire il push e il pull delle immagini container in Google Container Registry (gcr.io)
Uno sviluppatore che spinge un'app con Kf può anche creare pod (con kubectl) che possono utilizzare la KSA kf-builder con le autorizzazioni della GSA associata.
Il deployment in Kf richiede l'accesso in scrittura a un registry dei container.
Esegui il deployment di Kf in un progetto dedicato senza accesso alle risorse di produzione.
Concedi agli sviluppatori l'accesso per eseguire il push del codice nel repository di artefatti concedendo loro il ruolo roles/storage.admin
nel progetto o nei bucket utilizzati dal repository di artefatti.
Kf utilizza lo stesso pod per recuperare, creare e archiviare le immagini.
Supponiamo che le credenziali fornite possano essere conosciute dagli autori e dai publisher dei buildpack che utilizzi.
Kf non supporta le quote per proteggersi dai vicini rumorosi.
[[["Facile da capire","easyToUnderstand","thumb-up"],["Il problema è stato risolto","solvedMyProblem","thumb-up"],["Altra","otherUp","thumb-up"]],[["Difficile da capire","hardToUnderstand","thumb-down"],["Informazioni o codice di esempio errati","incorrectInformationOrSampleCode","thumb-down"],["Mancano le informazioni o gli esempi di cui ho bisogno","missingTheInformationSamplesINeed","thumb-down"],["Problema di traduzione","translationIssue","thumb-down"],["Altra","otherDown","thumb-down"]],["Ultimo aggiornamento 2025-09-04 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\nSecurity overview\n-----------------\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.\n - Until Kf provides this, use [RBAC](/kubernetes-engine/docs/how-to/role-based-access-control).\n- A developer pushing an app with Kf may also create pods (with `kubectl`) that can use the `kf-builder` KSA with the permissions of its associated GSA.\n- Deploying to Kf requires write access to a container registry.\n - Deploy Kf in a dedicated project without access to production resources.\n - Grant developers access to push code to the Artifact Repository by [granting them `roles/storage.admin`](/container-registry/docs/access-control) on the project, or buckets that Artifact Repository uses.\n- Kf uses the same Pod to fetch, build, and store images.\n - Assume any credentials you provide can be known by the authors and publishers of the buildpacks you use.\n- Kf doesn't support quotas to protect against noisy neighbors.\n - Use Kubernetes [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)"]]
