SUSE Security est une solution destinée à renforcer la sécurité de vos clusters Kubernetes. Elle se déploie directement sur les clusters Kubernetes au travers.

Requirements

📦 Helm repo

Le déploiement peut être fait directement depuis des manifests, ou au travers de Helm Chart. Nous couvrirons ici l'utilisation des Helm Chart.

• Le Helm Repository est disponible sous https://charts.rancher.io et est présent par défaut si vous faites le déploiement via Rancher.
• Le repo est également disponible sur le github du projet : https://github.com/neuvector/neuvector-helm
  • Le repo est différent, tout comme les version de charts : https://neuvector.github.io/neuvector-helm/
  • Les deux sont générés de la même source, mais les images utilisées dans les fichiers de values diffèrent légèrement. Veillez donc à utiliser soit l'un soit l'autre, mais ne les intervertissez pas !
  • Si vous n'avez pas un accès direct à internet depuis votre serveur de déploiement (Argo, Flux, Fleet...), synchroniser le depuis votre registry interne, ou récupérer simplement le helm chart localement.

🗃️ Registry

Peu importe le chart utilisé, toutes les images sont stockées sur docker.io, sous rancher.

• Si votre serveur n'a pas d'accès direct à ces registry, synchroniser-les sur votre registry interne.
• Les images sont visibles dans le chart

 helm show values rancher-charts/neuvector|grep -i repository -A 1 -B 1

  image:
    repository: rancher/neuvector-controller
    tag: 5.4.4
--
    image:
      repository: rancher/neuvector-compliance-config
      imagePullPolicy: IfNotPresent
--
  image:
    repository: rancher/neuvector-enforcer
    tag: 5.4.4
--
  image:
    repository: rancher/neuvector-manager
    tag: 5.4.4
--
    image:
      repository: rancher/neuvector-registry-adapter
      imagePullPolicy: IfNotPresent
--
      registry: ""
      repository: rancher/neuvector-updater
      imagePullPolicy: IfNotPresent
--
      registry: ""
      repository: rancher/neuvector-scanner
      imagePullPolicy: Always

Si vous utilisez l'autre repo, vous remarquerez que les chemins sont différents

❯ helm show values neuvector/core|grep -i repository -B 1 -A 1
      digest: ""
      repository: neuvector/neuvector-csp-adapter
      tag: latest
--
  image:
    repository: neuvector/controller
    imagePullPolicy: IfNotPresent
--
    image:
      repository: neuvector/compliance-config
      imagePullPolicy: IfNotPresent
--
  image:
    repository: neuvector/enforcer
    imagePullPolicy: IfNotPresent
--
  image:
    repository: neuvector/manager
    imagePullPolicy: IfNotPresent
--
    image:
      repository: neuvector/registry-adapter
      imagePullPolicy: IfNotPresent
--
      registry: ""
      repository: neuvector/updater
      imagePullPolicy: IfNotPresent
--
      registry: ""
      repository: neuvector/scanner
      imagePullPolicy: Always

🧩 Composants

SUSE Security est déployé directement sur le cluster Kubernetes à sécuriser.
On retrouve les composants suivants :

• Le controller, qui fournit l'intelligence et l'API. Il vient par défaut avec un déploiement de 3 pods
• Les enforcer, un DaemonSet, il tourne sur tous les noeuds, récolte les informations et applique les stratégies définies.
• Le ou les scanners ont pour objectif de scanner les images directement dans les registry. Ils scalent horizontalement selon le besoin.
• Le manager héberge l'interface d'administration. Il n'héberge pas l'API, un seul pod suffit.
• L'updater met à jour la base de CVE régulièrement.

🌐 Fédération

On retrouve également deux services en lien avec la fédération, un mastersvc et un managedsvc.

Les deux services peuvent être exposé au travers de leur Ingress Controller respectif, dans ce cas vous aurez besoin d'exposer le service depuis un FQDN ou un path spécifique.

Il est également possible de les exposer via un service LoadBalancer, mais selon votre environnement cela peut être plus coûteux.

Pour résumé :

• Si vous souhaitez fédérer vos serveurs depuis un Ingress :
  • Réservez vos FQDN, il est aussi possible d'utiliser des path.
  • Mettez en place un Ingress Controller si ce n'est déjà pas le cas.
  • Ouvrez les flux 443 entre votre cluster maître et les clusters fédérés, dans les deux sens. Veillez à ce que la résolution DNS fonctionne.
• Si vous souhaitez utiliser un load balancer :
  • OnPremise ou dans du cloud privé, veillez à avoir un IPAM type MetalLB, avec une adresse disponible.
  • Si votre hébergeur fournit un Load Balancer externe intégré à Kubernetes, il faudra l'utiliser.
  • Les flux sont 10443 (pour les serveurs fédérés) et 11443 (pour le master)

💾 Persistence

Par défaut, la persistence n'est pas activée, ce qui implique qu'en cas d'arrêt de tous les pods la configuration est perdue. Cela n'est envisageable que dans des environnements éphémère où les règles sont intégralement déployées via des CRDs.

Dans la majorité des cas, si vous utilisez par exemple l'apprentissage automatique des règles et le Service Group Mode Automation, vous aurez besoin de stocker la configuration quelque part.

Il ne s'agit que de configuration et les besoins en I/O sont quasi inexistant, mais un volume RWX est tout de même requis pour permettre à plusieurs Controller de fonctionner simultanément.

Un volume sur un serveur NFS suffit, mais si vous disposez de Portworx, Longhorn, Rook, ou autre chose, c'est encore mieux.

📝 Pour résumé

• Veillez à avoir accès au Helm Chart : si vous avez prévu d'utiliser Rancher, utilisez le repo Rancher, sinon celui de NeuVector. Cela n'a pas beaucoup d'importance du moment que vous n'en changez pas en cours de route (ou si c'est le cas, pensez au chemin des images)
• Si vos clusters n'ont pas accès à docker.io, synchronisez les images sur votre registry interne
• Choisissez entre Ingress ou Load Balancer
• Veillez à avoir une StorageClass permettant la création de volumes RWX