Tâche #28784
Scénario #16278: Les services OpenNebula doivent être accessibles derrière un reverse proxy
Proposition d'évolution pour l'ouverture de l'API XMLRPC
100%
Description
Aujourd'hui l'API XMLRPC n'est ouverte que dans le mode HA et uniquement aux noeuds.
Afin de pouvoir interagir avec les serveurs Hâpy, je propose de permettre l'accès à l'API a une liste d'IP.
Pour des raisons de sécurité il est préférable de n'autoriser qu'une liste d'IP et pas des sous-réseaux comme on peut le faire pour SSH.
Ci-joint un patch avec le code de ma proposition.
Révisions associées
Possibilité d'ajouter des ip pour XMLRPC Ref #28784
Changing xmlrpc_allowed_ips type for (domain)
Frozing activer_acces_xmlrpc if activer_one_ha as "oui" as value.
Updating oned.conf template
ref #28784
Correction du type des variables *_vlan_trunk et ajout des validations
Ref #28784
Historique
#1 Mis à jour par Gilles Grandgérard il y a plus de 4 ans
- Tracker changé de Anomalie à Demande
#2 Mis à jour par Daniel Dehennin il y a plus de 4 ans
Je pense que cette demande devrait être traité avec #16278.
#3 Mis à jour par Gilles Grandgérard il y a plus de 4 ans
- Tracker changé de Demande à Tâche
- Tâche parente mis à #16278
#4 Mis à jour par Philippe Caseiro il y a plus de 4 ans
- Projet changé de eole-one-master à EOLE OpenNebula
- Description mis à jour (diff)
- Assigné à mis à Vincent Febvre
#5 Mis à jour par Vincent Febvre il y a plus de 4 ans
- Statut changé de Nouveau à En cours
#6 Mis à jour par Daniel Dehennin il y a plus de 4 ans
Contrôler l’ouverture du port 2633
sur les interfaces devient peut-être inutile si tout passe par le reverse proxy HTTP comme indiqué dans le scénario ?
- Le service oned n’écoute que sur
127.0.0.1
et le nginx expose le/RPC2
(et gère les certificats du coup) - Si on veut restreindre l’accès il possible d’utiliser les directives allow et deny.
#7 Mis à jour par Philippe Caseiro il y a plus de 4 ans
- Statut changé de En cours à Résolu
#8 Mis à jour par Philippe Caseiro il y a plus de 4 ans
- % réalisé changé de 0 à 100
#9 Mis à jour par Daniel Dehennin il y a plus de 4 ans
Je ne comprends pas certains changements dans eole-one-master:9320c5a463dfb5a1cad7f340b849f5807e5569b7 :
- pourquoi les types des variables
*_vlan_trunk
sont passés destring
ànumber
(avec suppression des regexp de validation) ?
Merci.
#10 Mis à jour par Daniel Dehennin il y a plus de 4 ans
- Statut changé de Résolu à En cours
- % réalisé changé de 100 à 70
Corriger le changement de type et la suppression des validations.
#11 Mis à jour par Daniel Dehennin il y a plus de 4 ans
- Statut changé de En cours à Fermé
- % réalisé changé de 70 à 100
- Restant à faire (heures) mis à 0.0
La régression est bien corrigée dans le paquet eole-one-master 2.7.2-18.