Panoramica sulla sicurezza

Kf punta a offrire un'esperienza di sviluppo simile a quella di Cloud Foundry, replicando il ciclo di vita di build, push e deployment. Per farlo, crea un livello UX degli sviluppatori sulla base di tecnologie ampiamente note, ampiamente utilizzate e adottate come Kubernetes, Istio e i registri di container, anziché implementare tutte le funzionalità da zero.

Nel prendere decisioni in materia di sicurezza, Kf mira a fornire soluzioni complete che siano native dei rispettivi componenti e che possano essere integrate con altri meccanismi. Nel dettaglio:

  • Soluzioni complete significa che Kf cerca di non fornire soluzioni parziali che possono portare a un falso senso di sicurezza.
  • Nativo significa che le soluzioni devono essere una parte del componente piuttosto che un costrutto Kf per evitare modifiche che provocano un errore.
  • Può essere aumentato significa che l'approccio adottato da Kf dovrebbe funzionare perfettamente con altri strumenti Kubernetes e Google Cloud per una difesa in profondità.

Considerazioni importanti

Oltre alle Limitazioni attuali descritte di seguito, è importante leggere e comprendere le informazioni descritte in questa sezione.

Workload Identity

Per impostazione predefinita, Kf utilizza Workload Identity per garantire la consegna e la rotazione sicure delle credenziali dell'account di servizio utilizzate da Kf per interagire con il progetto Google Cloud. A questo scopo, Workload Identity mappa 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 dominio KSA denominato controller mappato a Google Search per eseguire le seguenti operazioni:

  1. Scrivi le metriche in Stackdriver
  2. 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 Google Search Console.
  3. L'Arabia Saudita kf-builder viene utilizzata 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 fornisce questo, utilizza RBAC.

  • Uno sviluppatore che esegue il push di un'app con Kf può anche creare pod (con kubectl) che possono utilizzare l'opzione KSA kf-builder con le autorizzazioni della richiesta di assistenza associata alla risorsa associata.

  • Il deployment in Kf richiede l'accesso in scrittura a un Registro di sistema dei container. Esegui il deployment di Kf in un progetto dedicato senza accedere alle risorse di produzione. Concedi agli sviluppatori l'accesso per eseguire il push del codice al repository di artefatti concedendo loro roles/storage.admin sul progetto o sui bucket utilizzati da Artifact Repository.

  • Kf utilizza lo stesso pod per recuperare, creare e archiviare le immagini. Supponi che le credenziali fornite siano note agli autori e agli editori dei buildpack utilizzati.

  • Kf non supporta le quote per proteggere da vicini rumorosi. Utilizza le quote delle risorse di Kubernetes.

Altre risorse

Generale

Protezioni avanzate