Déploiement de Cyberwatch sur un cluster Kubernetes existant

Cette documentation présente une stratégie de déploiement non standard de Cyberwatch, et dont le développement est actuellement en cours. Si vous souhaitez tout de même l’utiliser, ou en savoir plus sur notre feuille de route, nous vous recommandons de nous consulter.

Cette page décrit les étapes à suivre pour déployer Cyberwatch sur un cluster Kubernetes existant. Cette procédure suppose que l’utilisateur dispose d’une connaissance basique de l’orchestrateur Kubernetes et de Helm.

Prérequis techniques

La liste suivante constitue des prérequis au déploiement et au bon fonctionnement de Cyberwatch sur un cluster Kubernetes.

  1. Disposer d’une entrée DNS fonctionnelle pour accéder à l’application Cyberwatch. Cette entrée DNS doit pointer sur l’adresse IP du répartiteur de charge du cluster Kubernetes, ou de l’ingress controller. Cet enregistrement est nécessaire, aucun accès à l’application par l’adresse IP n’est possible.

  2. Disposer d’un environnement sur lequel sont installés les programmes Helm (version > 3.8.0) et Kubectl, configuré pour accéder au cluster Kubernetes.

  3. Le cluster Kubernetes doit disposer :

    • d’un résolveur DNS comme core-dns ;
    • d’un ingress-controller fonctionnel, la documentation OVH indique par exemple comment en mettre un en place ;
    • d’un système de stockage capable de générer dynamiquement des PersistentVolumes via un StorageClass.

    Pour vérifier que le cluster dispose d’un resolver DNS :

    kubectl cluster-info
    

Procédure de déploiement

  1. Se connecter au dépôt Helm :

    helm registry login harbor.cyberwatch.fr
    

    Compléter le nom de l’utilisateur en le préfixant par cbw$, puis fournir le mot de passe.

    Ces identifiants sont ceux de votre licence Cyberwatch, si vous n’en disposez pas merci de vous rapprocher de support@cyberwatch.fr.

  2. Créer puis éditer le fichier de configuration values.yml.

    Les étapes présentées ci-dessous visent à mettre en place un fichier de configuration minimal permettant le déploiement de l’application Cyberwatch.

    Voici un exemple de fichier values.yml dans sa configuration minimale :

    global:
      # storageClass:
    
      image:
        registryCredentials:
          - name: cyberwatch-credentials
            registry: harbor.cyberwatch.fr/cbw-on-premise
            username: changeme
            password: changeme
    
    nginx:
      resolver: changeme
    
    ingress:
      enabled: true
      ingressClassName: nginx
      host: cyberwatch.example.com
      tls:
        selfSigned: true
    
    thirdParties:
      enabled: false
    
    database:
      password: "changeme"
      root_password: "changeme"
    
    redis:
      password: "changeme"
    
    key:
      base: "changeme"
      credential: "changeme"
    
    node:
      name: cyberwatch-node-name
      type: cluster
    
  3. Configurer l’accès au registre des conteneurs. Le couple identifiant/mot de passe est similaire à celui utilisé pour se connecter au dépôt Helm.

    global:
      image:
        registryCredentials:
          - name: cyberwatch-credentials
            registry: harbor.cyberwatch.fr/cbw-on-premise
            username: changeme
            password: changeme
    
  4. Configurer le champ global.storageClass permet de définir le type de stockage utilisé par les VolumeClaims afin de conserver les données persistantes.

    Par défaut, le chart Helm configure l’application pour que les données soient sauvegardées sur la machine qui exécute le conteneur en utilisant des VolumeClaims de type hostPath. Ce comportement n’est adapté que si le cluster Kubernetes n’est composé que d’un seul nœud. Sur un cluster Kubernetes de plusieurs nœuds, Cyberwatch recommande d’utiliser un StorageClass :

    global:
      # storageClass:
    
    1. Lister les storageClass disponibles sur le cluster :

      kubectl get sc
      
    2. Dé-commenter le champ global.storageClass et lui assigner comme valeur le nom d’un des storageClass disponibles sur le cluster.

      Par exemple :

      global:
        storageClass: csi-cinder-classic
      

    Si nécessaire, plus d’informations sont disponibles en commentaires du fichier de configuration par défaut du chart Helm.

  5. Configurer le champ nginx.resolver.

    1. récupérer l’IP du DNS resolver kube-dns :

      kubectl -n kube-system get svc kube-dns
      
    2. Assigner l’adresse IP du résolveur DNS du cluster Kubernetes au champ nginx.resolver.

      Exemple :

      nginx:
        resolver: 10.3.0.10
      
  6. Configurer l’ingress

    1. Le champ ingress.ingressClassName permet de définir quelle IngressClass va être utilisée pour implémenter l’Ingress. Cette valeur doit être définie afin de pointer sur le nom d’une IngressClass valide. Les IngressClass disponibles sur le cluster peuvent être listées à l’aide de la commande ci-dessous :

      kubectl get ingressclasses
      
    2. Assigner la valeur sélectionnée au champ ingress.ingressClassName et le nom de domaine qui acceptera les requêtes au champ ingress.host.

      Exemple :

      ingress:
        enabled: true
        ingressClassName: nginx
        host: cyberwatch.example.com
        tls:
          selfSigned: true
      

      L’adresse IP qui correspond au nom de domaine doit être celle du répartiteur de charge du cluster.

    Si nécessaire, plus d’informations sont disponibles en commentaires du fichier de configuration par défaut du chart Helm.

  7. Désactiver le conteneur thirdParties en définissant le paramètre thirdParties.enabled à false :

    thirdParties:
      enabled: false
    
  8. Configurer les mots de passe de l’application, de la base de données et de redis.

    L’ensemble des secrets peut être généré avec la commande suivante :

    cat <<-EOF
    database:
      password: "$(openssl rand -hex 16)"
      root_password: "$(openssl rand -hex 16)"
    
    redis:
      password: "$(openssl rand -hex 16)"
    
    key:
      base: "$(openssl rand -hex 64)"
      credential: "$(openssl rand -hex 64)"
    EOF
    
  9. Configurer le nom que prendra le nœud Cyberwatch dans l’application à l’aide du paramètre node.name.

    node:
      name: cyberwatch-node-name
      type: cluster
    
  10. Créer le namespace cyberwatch sur le cluster.

     kubectl create namespace cyberwatch
    
  11. Générer un couple de clef SSH et l’enregistrer en tant que secret.

     ssh-keygen -q -N '' -f %s -t ed_25519
     kubectl -n cyberwatch create secret generic container-scanner-ssh-authorized-keys --from-file=authorized_keys="./id_ed25519.pub"
     kubectl -n cyberwatch create secret generic ssh-private-key --from-file="./id_ed25519"
    
  12. Déployer le chart Helm :

    helm -n cyberwatch install cyberwatch oci://harbor.cyberwatch.fr/cbw-on-premise/cyberwatch-chart -f values.yml
    

    Le déploiement du chart Helm va prendre en compte les configurations du fichier values.yml afin de configurer l’application.

  13. Vérifier l’état des pods :

    kubectl -n cyberwatch get pods
    
  14. Quand tous les pods sont en cours d’exécution, se connecter à l’interface web en HTTPS à partir de l’entrée DNS et enregistrer l’utilisateur Administrateur depuis l’interface web.

Le fait d’accéder à l’instance Cyberwatch via l’adresse IP renverra une erreur 404. Il est nécessaire d’utiliser le nom de domaine défini plus haut.

(Optionnel) Récupérer le fichier de configuration par défaut du chart Helm

La documentation ci-dessus indique les étapes à suivre afin de mettre en place une configuration minimale de Cyberwatch.

Il est possible de récupérer le fichier de configuration par défaut du chart Helm de Cyberwatch, afin de disposer d’un fichier complet indiquant quelles valeurs par défaut sont modifiables.

L’utilisation de ce fichier est recommandée si vous souhaitez dévier de la configuration minimale proposée dans cette documentation, notamment pour la mise en place d’un certificat TLS par exemple.

Pour récupérer le fichier de configuration par défaut du chart Helm :

helm show values oci://harbor.cyberwatch.fr/cbw-on-premise/cyberwatch-chart > values.yml

Ce fichier peut ensuite être modifié selon vos besoins, et le chart Helm redéployé à partir de cette nouvelle configuration.


Retour en haut