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

Kf propose une expérience de développement semblable à 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 largement connues et utilisées, telles que Kubernetes, Istio et les registres de conteneurs, plutôt que de réimplémenter l'ensemble des composants depuis zéro.

Présentation de la sécurité

En ce qui concerne la sécurité, Kf s’appuie sur des solutions complètes, intégrées à chacun de ses composants, et pouvant être renforcées par d’autres mécanismes. Voici ce que cela implique :

  • "Solutions complètes" signifie que Kf cherche à fournir des solutions complètes plutôt que partielles, afin d’éviter tout faux sentiment de sécurité.
  • "Intégrées à chacun de ses composants" signifie que les solutions font partie du composant lui-même et non d'une construction Kf afin d'éviter des modifications destructives.
  • "Pouvant être renforcées" signifie que l'approche de Kf fonctionne de manière transparente avec d'autres outils Kubernetes et Google Cloud, permettant ainsi 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.
    • En attendant, utilisez les RBAC existants.
  • 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 GSA associé.
  • Le déploiement sur Kf nécessite un accès en écriture à un registre de conteneurs.
    • Déployez 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, créer et stocker des images.
    • Supposons que les identifiants que vous fournissez soient connus des auteurs et des éditeurs des buildpacks que vous utilisez.
  • Kf ne prend pas en charge les quotas pour la protection contre les voisins bruyants.

Autres ressources

Général

Protections avancées