Travailler avec les machines virtuelles systèmes¶

Utiliser un certificat SSL pour la Console Proxy¶

Par défaut, la fonctionnalité de visualisation de la console utilise le HTTP en clair. Dans n’importe quel environnement de production, la connexion à la console proxy devrait être cryptée via SSL au minimum.

Un administrateur CloudStack dispose de 2 façons pour sécuriser la communication à la console proxy avec SSL :

• Configurer un certificat générique SSL et la résolution de nom de domaine

• Configurer un certificat pour un FQDN spécifique et configurer la répartition de charge

Changer le Certificat SSL et le domaine de la Console Proxy¶

L’administrateur peut configurer le cryptage SSL en sélectionnant un domaine et en téléchargent un nouveau certificat et une clef privée. Le domaine doit fournir le service DNS capable de résoudre les requêtes pour les adresses de la forme aaa-bbb-ccc-ddd.votre.domaine en adresses IPv4 dans la forme aaa.bbb.ccc.ddd, par exemple, 202.8.44.1. Pour modifier le domaine de la console proxy, le certificat SSL et la clef privée :

1. Configurer la résolution de nom dynamique ou peupler tous les noms DNS possibles de votre plage d’adresses IP publique au sein de votre serveur DNS avec le format aaa-bbb-ccc-ddd.consoleproxy.societe.com -> aaa.bbb.ccc.ddd.

   Note

   Dans ces étapes, vous noterez consoleproxy.societe.com – Pour des raisons de sécurité, nous recommandons de créer un certificat SSL générique pour un sous-domaine séparé. Dans le cas où ce certificat serait compromis, un utilisateur mal intentionné ne pourrait pas usurper l’identité du domaine societe.com.

2. Générer la clef privée et la demande de certificat signé (CSR). Lorsque vous utilisez openssl pour générer les paires de clefs privées/publiques et les CSRs, pour la clef privée que vous allez copier dans l’interface de CloudStack, assurez-vous de convertir dans le format PKCS#8.

   1. Générer une nouvelle clef privée de 2048 bits

      openssl genrsa -des3 -out yourprivate.key 2048
      

   2. Générer un nouveau certificat CSR. Assurez-vous de la création d’un certificat générique, comme *.consoleproxy.societe.com

      openssl req -new -key yourprivate.key -out yourcertificate.csr
      

   3. Sur le site web de votre Autorité de Certification favorite, commander un certificate SSL et soumettre le CSR. Vous devriez recevoir un certificat valide en retour.

   4. Convertir votre clef privée au format PKCS#8 crypté.

      openssl pkcs8 -topk8 -in yourprivate.key -out yourprivate.pkcs8.encrypted.key
      

   5. Convertir votre clef privée cryptée PKCS#8 au format PKCS#8 conforme avec CloudStack.

      openssl pkcs8 -in yourprivate.pkcs8.encrypted.key -out yourprivate.pkcs8.key
      

3. Dans l’écran de mise à jour du certificate SSL de l’interface CloudStack, coller ce qui suit :

   • Le certificat que vous venez de générer.

   • La clef privée que vous venez juste de générer.

   • Le nom de domaine souhaité, préfixé d’un *. ; par exemple : *.consoleproxy.societe.com

   

4. Cela va arrêter toutes les VM console proxy en fonctionnement, et les redémarrer avec le nouveau certificat et la clef. Les utilisateurs peuvent noter une brève interruption de la disponibilité de la console.

Le serveur de gestion génère des URLS de la forme “aaa-bbb-ccc-ddd.consoleproxy.societe.com” après que les changements aient été effectués. Les nouvelles requêtes aux consoles seront faîtes avec le nouveau nom de domaine, certificat et clef.

Télécharger la CA Racine et la CA intermédiaire¶

Si vous avez besoin de télécharger un certificat personnalisé avec la CA racine et la CA intermédiaire, vous pouvez trouver plus de détails ici : https://cwiki.apache.org/confluence/display/CLOUDSTACK/Procedure+to+Replace+realhostip.com+with+Your+Own+Domain+Name

NOTES IMPORTANTES :

Dans le but d’éviter toutes erreurs et problèmes durant le téléchargement de certificats personnalisés, merci de vérifier ce qui suit :

1. While doing URL encoding of ROOT CA and any Intermediate CA, be sure that the plus signs (“+”) inside certificates are not replaced by space (” ”), because some URL/string encoding tools tend to do that.

2. If you are renewing certificates it might happen you need to upload new ROOT CA and Intermediate CA, together with new Server Certificate and key. In this case please be sure to use same names for certificates during API upload of certificate, example:

http://123.123.123.123:8080/client/api?command=uploadCustomCertificate&...&name=root1... http://123.123.123.123:8080/client/api?command=uploadCustomCertificate&...&name=intermed1...

Ici les noms “root1” et “intermed1”. Si vous utilisiez d’autres noms auparavant, merci de vérifier la table cloud.keystore pour obtenir les noms utilisés.

Si vous avez toujours des problèmes et les erreurs suivantes dans le management.log lors de la destruction du CPVM :

• Unable to build keystore for CPVMCertificate due to CertificateException
• Cold not find and construct a valid SSL certificate

cela signifie toujours que certains certificats racine/intermédiaire/serveur ou la clef n’est pas dans le bon format, ou encodée incorrectement ou plusieurs CA racine/CA intermédiaire sont présente dans la base de données par erreur.

Une autre façon de renouveller les certificats (racine, intermédiaires, certificats serveurs ou clef) - bien que non recommandée sauf si vous la trouvez confortable, est d’éditer directement la base de données, tant que vous respectez la principale exigence que la clef soit encodée en PKCS8, alors que la CA racine, intermédiaire et les certificats serveurs sont toujours au format par défaut PEM (pas besoin d’encodage d’URL ici). Après avoir éditer la base de données, merci de redémarrer le serveur de gestion, de détruire la machine SSVM et CPVM après ça, pour que les nouvelles SSVM et CPVM soient créées avec les nouveaux certificats.

Les consoles proxys de répartition de charge¶

Une alternative à utiliser les DNS dynamique ou de créer une plage d’entrées DNS comme décrit ans la section précédente serait de créer un certificat SSl pour un nom de domaine spécifique, de configurer CloudStack pour utiliser ce FQDN particulier et alors de configurer un répartiteur de charge pour l’adresse IP de la console proxy derrière ce FQDN. Comme cette fonctionnalitée est toujours nouvelle, merci de voir https://cwiki.apache.org/confluence/display/CLOUDSTACK/Realhost+IP+changes pour plus de détails.

Configurer le routeur virtuel¶

Vous pouvez paramétrer :²

• Plage IP

• Services réseaux supportés

• Le nom de domaine par défaut pour les services servis par le routeur virtuel

• Adresse IP de la passerelle

• A quelle fréquence CloudStack rapporte les statistiques d’utilisation du réseau depuis les routeurs virtuels CloudStack. Si vous voulez collecter les données métriques du trafic depuis les routeur virtuel, fixer le paramètre de configuration global router.stats.interval. Si vous n’utilisez pas de routeur virtuel pour recueillir les statistiques d’utilisation du réseau, le positionner à 0.

Mettre à jour un routeur virtuel avec les offres de service système¶

Quand CloudStack crée un routeur virtuel, il utilise des paramètres par défaut qui sont définis dans une offre de service système par défaut. Voir “Offres de service système”. Tous les routeurs virtuels du même réseau invité utilise la même offre de service système. Vous pouvez mettre à jour les capacités du routeur virtuel en créant et appliquant une offre de service système personnalisée.

1. Définir votre offre de service système personnalisé. Voir “Créer une nouvelle offre de service système”. Dans le type de VM système, choisir Routeur de domaine.

2. Associer l’offre de service système avec l’offre de service. Voir “Créer une nouvelle offre de réseau”.

3. Appliquer l’offre de réseau au réseau dans lequel vous voulez les routeurs virtuels utilisant la nouvelle offre de service système. S’il s’agit d’un nouveau réseau, suivre les étapes de Ajouter un réseau invité additionnel de la page 66. Pour changer l’offre de service d’un routeur virtuel existant, suivre les étapes de “Changer l’offre réseau d’un réseau invité”.

Meilleurs pratiques pour les routeurs virtuels¶

• ATTENTION : rédémarrer un routeur virtuel depuis une console de l’hyperviseur efface toutes les règles iptables. Pour contourner ce probluème, stopper le routeur virtuel et le démarrer depuis l’interface CloudStack.

• Avertissement

  N’utilisez pas l’API destroyRouter lorsqu’un seul routeur n’est disponible dans le réseau, parce que l’API restartNetwork avec le paramètre cleanup=false ne pourra pas le récréer plus tard. Si vous voulez détruire et recréer un seul routeur disponible dans le réseau, utiliser l’API restartNetwork avec le paramètre cleanup=true.

Outil de surveillance de service pour Routeur Virtuelle¶

Des services variés fonctionnant sur les routeurs virtuels CloudStack peuvent être surveillés en utilisant l’outil de Surveillance Système. L’outil garantit que les services fonctionnent correctement jusqu’à ce que CloudStack les désactive délibérément. Si un service tombe, l’outil redémarre automatiquement le service et si cela n’aide pas à remonter le service, une alerte et un évènement sont générés indiquant la panne. A nouveau paramètre global, network.router.enableservicemonitoring, a été introduit pour contrôler cette fonctionnalité. La valeur par défaut est à false, ce qui implique que la surveillance est désactivée. Quand vous l’activez, s’assurer que le serveur de gestion et le routeur soient redémarrer.

Les outils de surveillance peuvent aider à démarrer un service VR, qui est planté à cause d’une raison inconnue. Par exemple :

• Le service a planté à cause de défauts dans le code source.

• Les services qui sont arrêtés par l’OS quand la mémoire ou le CPU ne sont plus suffisamment disponible pour le service.

Les services suivants sont contrôlés par un VR :

• DNS
• HA Proxy
• SSH
• Apache Web Server

Les réseaux suivant sont supportés :

• Les réseaux isolés

• Les réseaux partagés dans les zones Avancées et Basiques

  Note

  Les réseaux VPC ne sont pas supportés

Cette fonctionnalité est supporté sur les hyperviseurs suivants : XenServer, VMware et KVM.

Mise à jour améliorée pour les routeurs virtuels¶

Mettre à jour un VR est rendu souple. L’administrateur CloudStack est capable de contrôler la séquence des mises à jour du VR. Le séquencement est basé sur la hiérarchie de l’infrastructure, comme par Cluster, Pod ou Zone et la hiérarchie (de comptes) administrative, comme par Utilisateur ou Domain. En tant qu’administrateur, vous pouvez aussi déterminer quand un service client particulier, comme les VR, est mis à jour dans les limites d’un intervalle de mise à jour spécifiée. L’opération de mise à jour est améliorée pour augmenter la vitesse de mise à jour en autorisant autant d’opérations en parallèle que possible.

Durant la durée complète de la mise à jour, les utilisateurs ne peuvent pas lancer de nouveaux services ou faire des modifications sur un service existant.

En complément, utiliser plusieurs versions de VRs dans une seule instance est supporté. Dans l’onglet Détails d’un VR, vous pouvez voir la version et si il nécessite une mise à jour. Durant la mise à jour du serveur de gestion, CloudStack vérifie si le VR est à la dernière version avant d’effectuer toute opération sur le VR. Pour supporter cela, un nouveau paramètre global, ``router.version.check``, a été ajouté. Ce paramètre est fixé à true par défaut, ce qui implique que la version minimum requise est vérifiée avant d’effectuer toute opération. Aucune opération n’est effectuée si le VR n’est pas à la version requise. Les services de la vieille version du VR continue d’être disponible, mais aucune nouvelle opération ne peut être effectuée sur le VR jusqu’à ce qu’il soit mis à jour à la dernière version. Cela va assurer que la disponibilité des services VR et l’état des VR n’est pas impacté à cause de la mise à jour du serveur de gestion.

Le service suivant sera disponible même si le VR n’est pas mis à jour. Toutefois, aucun changement pour aucun des services ne peut être envoyé au VR jusqu’à ce qu’il soit mis à jour :

• Groupe de sécurité

• Données utilisateur

• DHCP
• DNS
• LB

• Redirection de port

• VPN

• NAT statique

• Source NAT

• Parefeu

• Passerelle

• ACL réseau