Kibana: Autoriser le proxy http/https pour l'installation du plugin

@seang-es serions-nous capables d'implémenter une solution qui utilise le tunneling HTTP Connect ?

Après discussion avec @seang-es, il semblerait que les utilisateurs derrière des réseaux sécurisés aient leurs propres serveurs proxy http et souhaiteraient simplement pouvoir diriger Kibana via ces proxys.

Les utilisateurs souhaitent modifier une option dans le fichier kibana.yml pour définir les host et port sur le serveur proxy.

J'ai également besoin d'authentifier le paramètre de proxy.
J'attends avec impatience votre mise en œuvre.

Ouais, vous ne voulez pas de CONNECT ici, juste de vieux proxies http

@seang-es Comment cela fonctionne-t-il avec d'autres programmes d'installation de plug-ins comme bin/plugin dans Elasticsearch ? Je ne vois pas d'options CLI permettant à leurs installateurs de configurer un proxy authentifié ? De plus, après réflexion, cela ne devrait-il pas être pris en charge au niveau du système d'exploitation?

Après une discussion avec @spalger et @rashidkpc , la raison pour laquelle nous ne voulons pas utiliser CONNECT ici est que de nombreuses entreprises ne le prennent pas en charge. Voici donc les options proposées :

1. Voyez si cela est vraiment nécessaire pour nos utilisateurs ou s'il existe d'autres solutions de contournement qui permettraient aux utilisateurs d'accomplir la même chose. @seang-es, pouvez-vous répondre aux commentaires de @simianhacker afin que nous ayons une meilleure compréhension de la façon dont le client contourne cela pour les plugins Elasticsearch.
2. Réécrivez le module installedPlugins pour utiliser le module request du nœud au lieu de wreck.js car l'épave ne prend pas en charge le proxy.
3. Écrivez un plugin proxy http qui étend wreck.js .

Sur les 3, s'il s'agit d'une fonctionnalité indispensable, je suis plus à l'aise avec l'implémentation de l'option 2.

Après de plus amples discussions, nous avons décidé de ne pas ajouter de proxy http/https pour les installations de plugins dans Kibana. La raison principale en est qu'Elasticsearch ne le prend pas non plus en charge et qu'il existe une solution pour effectuer des installations hors ligne à l'aide du programme d'installation de fichiers.

Par example:

bin/kibana plugin --install --url file:///home/username/plugin.tar.gz

_Remarque_ : Vous devez utiliser des chemins absolus

Donc, je supprime l'étiquette P1 et ferme ce problème.

J'ai soumis le problème #5998 pour mettre à jour la documentation du plug-in Kibana afin d'inclure les installations de fichiers à partir d'un répertoire local.

L'une des raisons données ci-dessus pour ne pas le prendre en charge directement n'est pas valide, car la commande de plug-in d'elasticsearch _does_ prend en charge la spécification de proxys, bien que via les propriétés système Java correspondantes, comme documenté à :
https://www.elastic.co/guide/en/elasticsearch/reference/1.6/modules-plugins.html

bin/plugin -DproxyHost=host_name -DproxyPort=port_number --install mobz/elasticsearch-head

@avallen Est-ce que le téléchargement du fichier puis son installation manuelle fonctionnent pour vous ?

Cette soi-disant solution de contournement ne semble pas fonctionner

$bin/kibana plugin --install --url file:///opt/kibana-4.4.1-linux-x64/marvel-latest.tar.gz
Invalid install option. Please use the format <org>/<plugin>/<version>.

De plus, ne pas autoriser les installations de plug-ins proxy et/ou hors ligne empêche 90 % des organisations d'utiliser cette version...

La méthode correcte pour l'installation hors ligne est la suivante :

bin/kibana plugin -i marvel -u file:///tmp/marvel-latest.tar.gz

@stormpython L'étiquette PI doit être supprimée, mais ne doit-elle pas rester ouverte ?

Cela casse les Dockerfiles qui fonctionnent autrement correctement derrière un proxy HTTP.

@stormpython - explication ridicule pour plusieurs raisons :

• Elasticsearch prend en charge le proxy sortant (je le sais car c'est le seul moyen pour moi d'installer des plugins);
• Aucun administrateur raisonnable n'autorisera le trafic sortant illimité de son centre de données (serveurs), vous devez donc vous attendre à ce que l'installation du plug-in passe par un proxy sortant. Fondamentalement, si Kibana ne peut pas installer de plugins via un proxy sortant, c'est à côté de ne pas pouvoir les installer du tout.
• La solution de contournement que vous avez suggérée complique considérablement l'administration et la gestion de la configuration (c'est-à-dire Puppet, Chef). Et introduit la confusion: par exemple, je ne sais pas si mes problèmes d'installation du plugin sense (voir problème 7400 ) sont causés par l'installation à partir d'un fichier (votre solution de contournement) ou non.

Guyz, discuté ou non, décidé ou non, vous devriez reconsidérer cela à nouveau. Une seule décision est la bonne (la plus intelligente), et vous l'avez ratée.

La cohérence entre les projets d'installation est importante, nous allons donc examiner la prise en charge du proxy dans Elasticsearch.

en utilisant puppet et derrière un pare-feu d'entreprise, je peux installer des plugins pour elasticsearch et logstash (mais pas kibana ) en

(1) définir une variable d'environnement dans l'instance exec

exec {
    "$name":
        command     => $command,
        creates     => $creates,
        environment => [ "http_proxy=http://1.2.3.4:3128" ],
        logoutput   => $logoutput,
        onlyif      => $onlyif,
        path        => ["/bin", "/sbin", "/usr/bin", "/usr/sbin"],
        returns     => [0,74],
    ;
}

ou par

(2) en passant des paramètres de proxy à java.

"${bin_plugin} -DproxyHost=1.2.3.4 -DproxyPort=3128 install -b --verbose $name"

Voici un essai #7967 pour ajouter le support proxy pour l'installation du plugin

Cela a été corrigé avec #12753 et sera publié avec 6.1. La commande du plugin comprendra alors les variables d'environnement http_proxy , https_proxy et no_proxy .

Bonne nouvelle @timroes !
Grand merci pour ça !