Chrome sous Docker: CAP_SYS_ADMIN vs privilégié? [fermé]

11

J'utilise chromedriver + chrome dans Docker dans mon environnement de test.

Tout fonctionnait bien jusqu'à la dernière mise à niveau de CoreOS.

Ce sont les versions qui semblent fonctionner:

VERSION=1185.5.0
VERSION_ID=1185.5.0
BUILD_ID=2016-12-07-0937

Et c'est une version plus récente qui provoque le vidage du chrome:

VERSION=1235.4.0
VERSION_ID=1235.4.0
BUILD_ID=2017-01-04-0450

En regardant les changements, il semble que docker ait été mis à niveau de 1.11.x à 1.12.x, ce qui a interrompu l' setns()appel à l'intérieur du conteneur. setns()est utilisé par Chrome pour créer des espaces de noms.

Voici les exemples de sorties:

jsosic-coreos-test-20161207 ~ # docker --version
Docker version 1.11.2, build bac3bae

De l'intérieur d'un conteneur sur cette boîte:

[root@2939f21ecfaa /]# /opt/google/chrome/google-chrome
[57:57:0107/015130:ERROR:browser_main_loop.cc(261)] Gtk: cannot open display:

C'est ainsi que la nouvelle version l'a cassé:

jsosic-coreos-test-2017-01-04 ~ # docker --version
Docker version 1.12.3, build 34a2ead

[root@13ab34c36c82 /]# /opt/google/chrome/chrome
Failed to move to new namespace: PID namespaces supported,
  Network namespace supported,
  but failed: errno = Operation not permitted
Aborted (core dumped)

Ce que j'ai découvert, c'est que si je démarre le conteneur avec --cap-add=SYS_ADMINou --privileged- Chrome fonctionne comme prévu.

Quelle est la différence entre ces deux commutateurs? Quelles fonctionnalités sont activées par --privileged?

Et puis-je autoriser l' setns()intérieur du conteneur sans compromettre la sécurité?

permissions docker chrome namespaces Jakov Sosic
la source
Merci pour cela. J'ai fait un problème, en utilisant beaucoup de vos trucs: github.com/docker/for-linux/issues/496 Je pense que cela devrait être corrigé
Merc
J'ai presque 2 ans de retard, mais il y a une solution bien meilleure et plus sûre dans le ticket ci-dessus si vous êtes toujours intéressé.
Merc
Si l'affiche originale ne met pas à jour la réponse (il ne semble pas du tout actif sur SO), faites-moi savoir si vous seriez disponible pour en accepter une autre. J'ai perdu des heures là-dessus, je ne peux qu'imaginer combien d'heures nous sauverons d'autres personnes.
Merc

Réponses:

7

AFAICS, la documentation suggère d' accorder les capacités nécessaires à un conteneur, plutôt que d'utiliser le --privilegedcommutateur. L'exécution en mode privilégié semble accorder au conteneur toutes les capacités (exactement celles qui sont répertoriées dans la première URL, à condition que les documents soient à jour).

En bref, je dirais que cela --cap-add=SYS_ADMINaccorde un plus petit sous-ensemble de capacités au conteneur, par rapport au --privilegedcommutateur. Évidemment, les exemples de la documentation Docker (première URL) semblent préférer simplement ajouter la capacité SYS_ADMINou NET_ADMINsi nécessaire.

ivuk
la source
Merci, exec_linux.goaidé. J'ai essayé de cloner le dépôt Docker pour le parcourir, mais comme cela m'a pris quelques heures, je l'ai juste oublié :)
Jakov Sosic
Juste pour exécuter Chrome, il existe une bien meilleure solution répertoriée ici: github.com/docker/for-linux/issues/496#issuecomment-441149510 Je pense qu'il serait très bénéfique de mettre à jour la réponse pour que les gens fassent ce que j'explique dans ce même commentaire. Veuillez me faire savoir si vous êtes d'accord.
Merc
1

Une différence est que --privileged monte / dev et / sys en RW, alors que SYS_ADMIN les monte en RO. Cela signifie qu'un conteneur privilégié a un accès complet aux périphériques du système. SYS_ADMIN ne vous donne pas cela.

mel1990
la source