Présentation des fonctionnalités de sécurité

Kf propose une expérience de développement similaire à celle de Cloud Foundry, en répliquant le cycle de compilation, de transmission et de déploiement. Pour ce faire, il crée une couche d'expérience utilisateur de développeur sur des technologies très connues et utilisées telles que Kubernetes, Istio et les registres de conteneurs, plutôt que de mettre en œuvre tous les éléments à partir de zéro.

Présentation de la sécurité

En ce qui concerne les décisions en matière de sécurité, Kf vise à fournir des solutions complètes natives à leurs composants respectifs et pouvant être renforcées avec d'autres mécanismes. Voici le détail :

  • "Solutions complètes" signifie que Kf tente de ne pas fournir de solutions partielles pouvant entraîner un faux sentiment de sécurité.
  • "Natives" signifie que les solutions doivent faire partie du composant plutôt que d'une construction Kf pour éviter des modifications destructives.
  • "Pouvant être renforcées" signifie que l'approche de Kf doit fonctionner de manière transparente avec d'autres outils Kubernetes et Google Cloud pour assurer une défense en profondeur.

Remarques importantes

Outre les limitations actuelles décrites ci-dessous, il est important que vous lisiez et compreniez les éléments décrits dans cette section.

Workload Identity

Par défaut, Kf utilise Workload Identity pour assurer une livraison et une rotation sécurisées des identifiants du compte de service utilisés par Kf pour interagir avec votre projet Google Cloud. Pour ce faire, Workload Identity mappe un compte de service Kubernetes (KSA) à un compte de service Google (GSA). Le contrôleur Kf s'exécute dans l'espace de noms kf et utilise un KSA nommé controller mappé sur votre GSA pour effectuer les opérations suivantes :

  1. Écrire des métriques dans Stackdriver
  2. Lorsqu'un espace Kf est créé (kf create-space), le contrôleur Kf crée un KSA nommé kf-builder dans le nouvel espace et le mappe sur le même GSA.
  3. Le KSA kf-builder est utilisé par Tekton pour transférer et extraire des images de conteneurs vers Container Registry (gcr.io).

Le schéma suivant illustre ces interactions :

Limites actuelles

  • Kf ne fournit pas de rôles RBAC prédéfinis.
    • Tant que Kf ne les fournit pas, utilisez RBAC.
  • Un développeur qui déploie une application avec Kf peut également créer des pods (avec kubectl) qui peuvent utiliser le KSA kf-builder avec les autorisations du système GSA associé.
  • Le déploiement sur Kf nécessite un accès en écriture à un registre de conteneurs.
    • Déployer Kf dans un projet dédié sans accès aux ressources de production.
    • Autorisez les développeurs à déployer le code sur le dépôt d'artefacts en leur accordant le rôle roles/storage.admin sur le projet ou les buckets utilisés par le dépôt d'artefacts.
  • Kf utilise le même pod pour récupérer, compiler et stocker des images.
    • Supposons que les identifiants que vous fournissez soient connus des auteurs et des éditeurs des packs de création que vous utilisez.
  • Kf ne prend pas en charge les quotas pour la protection contre les voisins bruyants.

Autres ressources

Général

Protection avancée