Panoramica sulla sicurezza

Kf mira a fornire un'esperienza di sviluppo simile a Cloud Foundry, replicando il ciclo di vita di build, push ed esecuzione di 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 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:

  1. Scrivere 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 GSA.
  3. 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)

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 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, 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.

Altre risorse

Generale

Protezioni avanzate