Déploiement de Cyberwatch sur un cluster Kubernetes existant

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.

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
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
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

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.

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

Il est nécessaire de conserver le fichier values.yml de manière sécurisée. Le fichier est requis pour la mise à jour des images Docker ou encore pour mettre à jour le chart Helm.

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: single

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

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.
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
```
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.
Désactiver le conteneur thirdParties en définissant le paramètre thirdParties.enabled à false :
```
thirdParties:
  enabled: false
```

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

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: single
```
Créer le namespace cyberwatch sur le cluster :
```
 kubectl create namespace cyberwatch
```

Générer un couple de clef SSH et l’enregistrer en tant que secret :

 ssh-keygen -q -N '' -f ./id_ed25519 -t ed25519
 kubectl -n cyberwatch create secret generic web-scanner-ssh-authorized-keys --from-file=authorized_keys="./id_ed25519.pub"
 kubectl -n cyberwatch create secret generic ssh-private-key --from-file="./id_ed25519"

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.
Vérifier l’état des pods :
```
kubectl -n cyberwatch get pods
```
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.