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. Analizziamo tutti gli aspetti 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 di 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 progetto Google Cloud. 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 denominatokf-buildernel nuovo spazio e lo mappa alla stessa GSA. - Il token
kf-builderKSA viene utilizzato da Tekton per eseguire il push e il pull delle immagini container in Google Container Registry (gcr.io)
Questo diagramma illustra queste interazioni:
Limitazioni correnti
- Kf non fornisce ruoli RBAC predefiniti.
- Fino a quando Kf non lo fornirà, utilizza RBAC.
- Uno sviluppatore che spinge un'app con Kf può anche creare pod (con
kubectl) che possono utilizzare la KSAkf-buildercon 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.adminnel progetto o nei bucket utilizzati dal repository di artefatti.
- Kf utilizza lo stesso pod per recuperare, compilare 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.
- Utilizza le quote di risorse di Kubernetes.