Remplacement des certificats internes

Les versions de NeuVector 5.4.2 et ultérieures nécessitent que les utilisateurs génèrent ou remplacent les certificats internes avant d’utiliser NeuVector. Après mars 2025, les versions de NeuVector antérieures à 5.4.2 nécessitent que les utilisateurs génèrent ou remplacent les certificats internes avant d’utiliser NeuVector.

Communication interne et certificats

SUSE® Security inclut, par défaut, des certificats auto-signés pour le chiffrement des communications du Manager (accès console/UI), du Contrôleur (API REST, interne), de l’Enforcer (interne) et du Scanner (interne).

Ces certificats peuvent être remplacés par les vôtres pour renforcer davantage la communication. Pour remplacer les certificats utilisés par l’accès externe à SUSE® Security (c’est-à-dire, navigateur vers le Manager, ou API REST vers le Contrôleur), veuillez consulter cette section. Voir ci-dessous pour remplacer les certificats utilisés dans la communication interne entre les conteneurs SUSE® Security.

Il est recommandé de remplacer les certificats uniquement lors du déploiement initial de SUSE® Security. Le remplacement sur un cluster en cours d’exécution (même avec une mise à niveau progressive) peut entraîner un état instable où les pods SUSE® Security ne peuvent pas communiquer entre eux en raison d’un décalage dans les certificats, et une PERTE DE DONNÉES peut se produire.

Remplacement des certificats utilisés dans les communications internes de SUSE® Security

Remplacez les fichiers de chiffrement internes ca.crt, tls.key, tls.crt comme suit :

  • Créez un nouveau fichier ca.cfg avec votre éditeur préféré :

[req]
distinguished_name = req_distinguished_name
x509_extensions = v3_req
prompt = no
[req_distinguished_name]
C = US
ST = California
L = San Jose
O = {product-name} Inc.
OU = Neuvector
CN = Neuvector
[v3_req]
keyUsage = digitalSignature, keyEncipherment, dataEncipherment
extendedKeyUsage = serverAuth, clientAuth
subjectAltName = @alt_names
[alt_names]
DNS.1 = Neuvector

Pour des informations supplémentaires sur ca.cfg, référez-vous à Remplacement du certificat auto-signé.

  • Choisissez votre scénario parmi les options ci-dessous :

  • Nouveau certificat

  • Mettez à jour le certificat actuel avec des SANs

  • Régénérez les fichiers de certificat et ajoutez des SANs

  • Régénérez le certificat lorsque le certificat intégré est utilisé.

Si votre certificat est sur le point d’expirer et que vous devez en générer un nouveau, suivez les étapes ci-dessous :

  • Supprimez l’ancien ca.crt, tls.key, tls.crt, secret Kubernetes, et générez-en de nouveaux :

    kubectl delete secret internal-cert -n neuvector
openssl genrsa -out ca.key 2048
openssl req -x509 -sha256 -new -nodes -key ca.key -days 3650 -out ca.crt
openssl genrsa -out tls.key 2048
openssl req -new -key tls.key -sha256 -out cert.csr -config ca.cfg
openssl req -in cert.csr -noout -text
openssl x509 -req -sha256 -in cert.csr -CA ca.crt -CAkey ca.key -CAcreateserial -out tls.crt -days 3650 -extensions 'v3_req' -extfile ca.cfg
openssl x509 -in tls.crt -text
kubectl create secret generic internal-cert -n neuvector --from-file=tls.key --from-file=tls.crt --from-file=ca.crt

  • Ensuite, modifiez les fichiers de déploiement du Controller, Enforcer et Scanner en ajoutant :

          containers:
        - name: neuvector-controller/enforcer/scanner-pod
          volumeMounts:
            - mountPath: /etc/neuvector/certs/internal/cert.key
              name: internal-cert
              readOnly: true
              subPath: tls.key
            - mountPath: /etc/neuvector/certs/internal/cert.pem
              name: internal-cert
              readOnly: true
              subPath: tls.crt
            - mountPath: /etc/neuvector/certs/internal/ca.cert
              name: internal-cert
              readOnly: true
              subPath: ca.crt
      volumes:
        - name: internal-cert
          secret:
            defaultMode: 420
            secretName: internal-cert

    Puis procédez à déployer SUSE® Security comme précédemment. Vous pouvez également accéder aux pods du controller/enforcer/scanner pour confirmer que les fichiers ca.crt, tls.key, tls.crt sont ceux personnalisés et que les communications SUSE® Security fonctionnent avec les nouveaux certificats.

    Exemples de commandes de correctif pour le controller (changez l’espace de noms en cattle-neuvector-system si nécessaire, et modifiez pour l’utiliser sur l’enforcer et le scanner)

    NAMESPACE=neuvector

kubectl patch deployment -n $\{NAMESPACE} neuvector-controller-pod --type='json' -p='[{"op": "add", "path": "/spec/template/spec/volumes/-", "value": {"name": "internal-cert", "secret": {"defaultMode": 420, "secretName": "internal-cert"}} } ]'

kubectl patch deployment -n $\{NAMESPACE} neuvector-controller-pod --type='json' -p='[{"op": "add", "path": "/spec/template/spec/containers/0/volumeMounts", "value": [{"mountPath": "/etc/neuvector/certs/internal/cert.key", "name": "internal-cert", "readOnly": true, "subPath": "cert.key"}, {"mountPath": "/etc/neuvector/certs/internal/cert.pem", "name": "internal-cert", "readOnly": true, "subPath": "cert.pem"}, {"mountPath": "/etc/neuvector/certs/internal/ca.cert", "name": "internal-cert", "readOnly": true, "subPath": "ca.cert"} ] } ]'

Si vos fichiers de certificat ont été créés avant la version SUSE® Security 5.3, vous devez mettre à jour le certificat avec au moins un Nom Alternatif de Sujet, ou SAN en abrégé. Si vous avez toujours les fichiers ca.key et ca.crt accessibles, exécutez les commandes comme suit :

kubectl delete secret internal-cert -n neuvector
openssl genrsa -out tls.key 2048
openssl req -new -key tls.key -sha256 -out cert.csr -config ca-new.cfg
openssl req -in cert.csr -noout -text
openssl x509 -req -sha256 -in cert.csr -CA ca.crt -CAkey ca.key -CAcreateserial -out tls.crt -days 3650 -extensions 'v3_req' -extfile ca-new.cfg
openssl x509 -in tls.crt -text
kubectl create secret generic internal-cert -n neuvector --from-file=tls.key --from-file=tls.crt --from-file=ca.crt

Une fois les fichiers de certificat mis à jour, redémarrez les déploiements afin d’utiliser le certificat mis à jour :

kubectl rollout restart deployment neuvector-controller-pod
kubectl rollout restart deployment neuvector-scanner-pod
kubectl rollout restart deployment neuvector-registry-adapter-pod
kubectl rollout restart ds neuvector-enforcer-pod

Si vos fichiers de certificat ont été créés avant la version SUSE® Security 5.3, vous devez mettre à jour le certificat avec au moins un Nom Alternatif de Sujet, ou SAN en abrégé. Si vous n’avez plus les fichiers ca.key et ca.crt, suivez les étapes ci-dessous :

  • Sauvegardez votre certificat original

    kubectl get secret internal-cert -o yaml > internal-cert.yaml

  • Exportez le certificat interne existant

    kubectl get secret internal-cert -o json | jq -r '.data."ca.crt"' | base64 -d > old-ca.crt
kubectl get secret internal-cert -o json | jq -r '.data."tls.crt"' | base64 -d > old-tls.crt
kubectl get secret internal-cert -o json | jq -r '.data."tls.key"' | base64 -d > old-tls.key

  • Créez de nouveaux fichiers de certificat et certificats internes

    openssl genrsa -out ca.key 2048
openssl req -x509 -sha256 -new -nodes -key ca.key -days 3650 -out ca.crt
openssl genrsa -out tls.key 2048
openssl req -new -key tls.key -sha256 -out cert.csr -config ca.cfg
openssl req -in cert.csr -noout -text
openssl x509 -req -sha256 -in cert.csr -CA ca.crt -CAkey ca.key -CAcreateserial -out tls.crt -days 3650 -extensions 'v3_req' -extfile ca.cfg
openssl x509 -in tls.crt -text

  • Fusionnez les anciens et nouveaux fichiers ca.crt

    cat old-ca.crt > /tmp/ca.crt cat ca.crt >> /tmp/ca.crt

  • Mettez à jour le secret Kubernetes avec le ca.crt fusionné

    kubectl delete secret internal-cert -n neuvector
kubectl create secret generic internal-cert -n neuvector --from-file=tls.key=old-tls.key --from-file=tls.crt=old-tls.crt --from-file=ca.crt=/tmp/ca.crt

  • Redémarrez les déploiements afin d’utiliser le certificat mis à jour

    kubectl rollout restart deployment neuvector-controller-pod
kubectl rollout restart deployment neuvector-scanner-pod
kubectl rollout restart deployment neuvector-registry-adapter-pod
kubectl rollout restart ds neuvector-enforcer-pod

  • Attendez que le redémarrage soit terminé

    kubectl rollout status deployment neuvector-controller-pod
kubectl rollout status deployment neuvector-scanner-pod
kubectl rollout status deployment neuvector-registry-adapter-pod
kubectl rollout status ds neuvector-enforcer-pod

  • Assurez-vous que la console est accessible et que tous les contrôleurs sont en ligne.* Mettez à jour le secret Kubernetes avec le nouveau tls.key

    kubectl delete secret internal-cert -n neuvector
kubectl create secret generic internal-cert -n neuvector --from-file=tls.key=tls.key --from-file=tls.crt=tls.crt --from-file=ca.crt=/tmp/ca.crt

  • Redémarrez les déploiements afin d’utiliser le certificat mis à jour

    kubectl rollout restart deployment neuvector-controller-pod
kubectl rollout restart deployment neuvector-scanner-pod
kubectl rollout restart deployment neuvector-registry-adapter-pod
kubectl rollout restart ds neuvector-enforcer-pod

  • Attendez que le redémarrage soit terminé

    kubectl rollout status deployment neuvector-controller-pod
kubectl rollout status deployment neuvector-scanner-pod
kubectl rollout status deployment neuvector-registry-adapter-pod
kubectl rollout status ds neuvector-enforcer-pod

  • Assurez-vous que la console est accessible et que tous les contrôleurs sont en ligne.* Mettez à jour le secret Kubernetes avec le nouveau ca.crt

    kubectl delete secret internal-cert -n neuvector
kubectl create secret generic internal-cert -n neuvector --from-file=tls.key=tls.key --from-file=tls.crt=tls.crt --from-file=ca.crt=ca.crt

  • Redémarrez les déploiements afin d’utiliser le certificat mis à jour

    kubectl rollout restart deployment neuvector-controller-pod
kubectl rollout restart deployment neuvector-scanner-pod
kubectl rollout restart deployment neuvector-registry-adapter-pod
kubectl rollout restart ds neuvector-enforcer-pod

  • Attendez que le redémarrage soit terminé

    kubectl rollout status deployment neuvector-controller-pod
kubectl rollout status deployment neuvector-scanner-pod
kubectl rollout status deployment neuvector-registry-adapter-pod
kubectl rollout status ds neuvector-enforcer-pod

  • Assurez-vous que la console est accessible et que tous les contrôleurs sont en ligne.

Si vous n’avez pas remplacé le certificat interne auparavant et souhaitez migrer vers un nouvel ensemble de certificats, suivez les étapes ci-dessous :

  • Vérifiez si vous avez déjà le certificat interne généré automatiquement.

    kubectl get secret internal-cert -o yaml

    Si vous voyez tls.key, tls.crt et ca.crt, cela signifie que vous utilisez le certificat généré automatiquement et vous pouvez sauter cette section.

    Si vous pouvez voir le secret, mais ne trouvez pas ces secrets, envisagez d’activer internal.autoRotateCert dans la surcharge des graphiques helm. Cette option générera et fera tourner votre certificat interne automatiquement.

    Si vous n’utilisez pas le certificat interne généré automatiquement et ne pouvez pas le faire, suivez les étapes ci-dessous :

  • Suivez les étapes dans l’onglet New certificate pour utiliser un secret Kubernetes afin de gérer le certificat interne. Au lieu de générer un nouveau certificat, utilisez le certificat, old-ca.crt, old-tls.crt et old-tls.key, récupéré ci-dessous :

    docker run -it --entrypoint=bash neuvector/scanner:3.654 -c "cat /etc/neuvector/certs/internal/ca.cert" > old-ca.crt
docker run -it --entrypoint=bash neuvector/scanner:3.654 -c "cat /etc/neuvector/certs/internal/cert.pem" > old-tls.crt
docker run -it --entrypoint=bash neuvector/scanner:3.654 -c "cat /etc/neuvector/certs/internal/cert.key" > old-tls.key

  • Assurez-vous que tous les composants fonctionnent sans erreurs.

  • Après cela, suivez les étapes dans l’onglet Regenerate certificate files and add SANs et migrez vers votre propre certificat.

Mise à jour/Déploiement avec Helm

Depuis le graphique Helm 2.4.1, nous pouvons maintenant gérer l’installation du certificat interne. Le graphique values.yaml doit être examiné pour tous les paramètres. L’exemple ci-dessous utilise RKE2, Ingress standard et certificats d’installateur.

# add chart
helm repo add neuvector https://neuvector.github.io/neuvector-helm/

# update chart
helm repo update

# add domain for ingress
export domain=awesome.sauce

# run the helm
helm upgrade -i neuvector -n neuvector neuvector/core --create-namespace  --set imagePullSecrets=regsecret --set k3s.enabled=true --set k3s.runtimePath=/run/k3s/containerd/containerd.sock --set manager.ingress.enabled=true --set manager.ingress.host=neuvector.$domain --set manager.svc.type=ClusterIP --set controller.pvc.enabled=true --set controller.pvc.capacity=500Mi --set controller.internal.certificate.secret=internal-cert --set cve.scanner.internal.certificate.secret=internal-cert --set enforcer.internal.certificate.secret=internal-cert