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.

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:

  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 del GSA associato.

  • Il deployment in Kf richiede l'accesso in scrittura a un registry di contenitori. 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 Artifact Repository concedendo loro il ruolo roles/storage.admin nel progetto o nei bucket utilizzati da Artifact Repository.

  • Kf utilizza lo stesso pod per recuperare, compilare e archiviare le immagini. Supponiamo che le credenziali fornite possano essere conosciute dagli autori e dagli editori dei buildpack che utilizzi.

  • Kf non supporta le quote per proteggersi da vicini con molto rumore. Utilizza le quote delle risorse di Kubernetes.

Altre risorse

Generale

Protezioni avanzate