From 24160cee230e6f3026b1bea7280946096aed27c6 Mon Sep 17 00:00:00 2001 From: Yax <1949284+kianby@users.noreply.github.com> Date: Sat, 26 Feb 2022 16:42:31 +0100 Subject: [PATCH] new post --- posts/2021/2021-06-12-mes-extensions-gnome.md | 21 +++---- posts/2021/2021-08-01-github-action.md | 2 +- posts/2021/2021-08-15-github-badge.md | 2 +- .../2022-02-26-docker-network-isolation.md | 56 +++++++++++++++++++ 4 files changed, 66 insertions(+), 15 deletions(-) create mode 100644 posts/2022/2022-02-26-docker-network-isolation.md diff --git a/posts/2021/2021-06-12-mes-extensions-gnome.md b/posts/2021/2021-06-12-mes-extensions-gnome.md index 6b1e4a7..6c1a242 100644 --- a/posts/2021/2021-06-12-mes-extensions-gnome.md +++ b/posts/2021/2021-06-12-mes-extensions-gnome.md @@ -1,15 +1,15 @@ -La mise à jour récente vers Gnome 40 de ma distribution EndeavourOS m'a amené à faire un tour des extensions Gnome installées pour vérifier qu'elles étaient toujours compatibles et à en découvir des nouvelles. Parce qu'on peut aimer les terminaux mais aussi apprécier les interfaces graphiques bien léchées ;-) Et dans ce domaine, Gnome a atteint l'excellence avec une cohérence d'ensemble qui le rend très agréable à utiliser. +La mise à jour récente vers Gnome 40 de ma distribution EndeavourOS m'a amené à faire un tour des extensions Gnome installées pour vérifier qu'elles étaient toujours compatibles et à en découvrir des nouvelles. Parce qu'on peut aimer les terminaux mais aussi apprécier les interfaces graphiques bien léchées ;-) Et dans ce domaine, Gnome a atteint l'excellence avec une cohérence d'ensemble qui le rend très agréable à utiliser. Voici donc mes extensions usuelles disponibles sur [le site officiel](https://extensions.gnome.org/). -## Unite +## Unite -Celle extension permet de personnaliser quelques comportements (comme l'emplacement des notifications fugitives), d'améliorer le visuel de la barre principale (mais tout est question de goût personnel) et d'intégrer une systray. +Celle extension permet de personnaliser quelques comportements (comme l'emplacement des notifications fugitives), d'améliorer le visuel de la barre principale (mais tout est question de goût personnel) et d'intégrer une systray. -Voici les réglages possibles : +Voici les réglages possibles : ![reglages unite](/images/2021/unite-settings.png) @@ -19,9 +19,9 @@ Et le résultat : ## Dash to Plank -Plank est un dock qui se place par défaut en bas de l'écran, des raccourcis vers les applications les plus utilisées. Il a la modestie de se cacher lorsqu'une application est plein écran et il réapparait quand le pointeur de souris touche le bord bas de l'écran. +Plank est un dock qui se place par défaut en bas de l'écran, des raccourcis vers les applications les plus utilisées. Il a la modestie de se cacher lorsqu'une application est plein écran et il réapparaît quand le pointeur de souris touche le bord bas de l'écran. -Gnome a aussi un *dock* (mais je ne suis pas sûr qu'ils l'appellent ainsi) sur lequel on peut déposer nos applications favorites et qui apparait quand on appelle les activités. +Gnome a aussi un *dock* (mais je ne suis pas sûr qu'ils l'appellent ainsi) sur lequel on peut déposer nos applications favorites et qui apparaît quand on appelle les activités. L'idée géniale de cette extension est de lire la configuration Gnome des applications favorites et d'utiliser Plank pour l'afficher. @@ -29,12 +29,7 @@ L'idée géniale de cette extension est de lire la configuration Gnome des appli ## En bonus -J'ai deux autres extensions à l'essai : +J'ai deux autres extensions à l'essai : - **Gnome 40 UI improvements** : je n'ai pas encore regardé en détail si ces améliorations valent la peine -- **Show Desktop Button** : anti-ergonomique, une icône de maison logéé dans la systray qui minimise toutes les fenêtres ouvertes afin... d'admirer son fond d'écran ;-) - - - - - +- **Show Desktop Button** : anti-ergonomique, une icône de maison logée dans la systray qui minimise toutes les fenêtres ouvertes afin... d'admirer son fond d'écran ;-) diff --git a/posts/2021/2021-08-01-github-action.md b/posts/2021/2021-08-01-github-action.md index e9de5a1..6a5dcf6 100644 --- a/posts/2021/2021-08-01-github-action.md +++ b/posts/2021/2021-08-01-github-action.md @@ -3,7 +3,7 @@ J'ai utilisé les workflows de Github, appelés *"Github Actions"* pour constuire et publier mes images Docker sur le Docker Hub. Jusqu'à aujourd'hui, c'était un process géré *à la papa* ; j'avais un projet commun avec tous mes docker files, la plupart n'était plus utilisés depuis un bail et je lançais les quelques commandes docker build / tag / push à la demande. -Et puis la finalisation de la version 2.0 de Stacosys qui est une version orientée qualité (suppression de demi-fonctionalités jamais mises en oeuvre, ajout de tests unitaires, simplification de la base de code existante), m'a ramené sur le sujet de la CI/CD complètement laissé de côté dans mes projets perso. +Et puis la finalisation de la version 2.0 de Stacosys qui est une version orientée qualité (suppression de demi-fonctionnalités jamais mises en œuvre, ajout de tests unitaires, simplification de la base de code existante), m'a ramené sur le sujet de la CI/CD complètement laissé de côté dans mes projets perso. J'ai donc fait la liste des images réellement utilisées dans mon docker-compose : - les dockerfiles qui correspondent à un projet de dev ont été rapatriés dans le projet Github correspondant, diff --git a/posts/2021/2021-08-15-github-badge.md b/posts/2021/2021-08-15-github-badge.md index 3b9199b..1a94da2 100644 --- a/posts/2021/2021-08-15-github-badge.md +++ b/posts/2021/2021-08-15-github-badge.md @@ -43,7 +43,7 @@ Le workflow est exécuté à chaque push sur n'importe quelle branche. On défin - les version de Python : je retiens la première 3.9 (GA) et la dernière mineure de la 3.9 - les versions de Poetry, le système de build : la dernière stable me suffit, ce n'est pas Poetry que je teste. -- les systèmes d'exploitation : le tryptique classique Linux / MacOS / Ms Win +- les systèmes d'exploitation : le triptyque classique Linux / MacOS / Ms Win A partir de cette matrice, le workflow va calculer le produit cartésien de tous les environnements de tests et dérouler les actions sur chacun. On s'appuie sur l'action poetry du [marketplace Github](https://github.com/marketplace?type=actions) pour avoir un workflow plus concis et plus lisible : diff --git a/posts/2022/2022-02-26-docker-network-isolation.md b/posts/2022/2022-02-26-docker-network-isolation.md new file mode 100644 index 0000000..d973534 --- /dev/null +++ b/posts/2022/2022-02-26-docker-network-isolation.md @@ -0,0 +1,56 @@ + + + +Je réfléchis à renforcer la sécurité de mon serveur à base de docker compose. J'ai plutôt confiance dans mes containers mais c'est un sentiment subjectif et non justifiable. Certes j'utilise autant que possible des images officielles mais : +- je n'ai aucun outil pour tester les vulnérabilités +- je ne suis pas à l'abri d'une compromission d'un container par l'exploitation d'une faille. + +Je m'intéresse à deux aspects de la sécurisation : +1. le réseau : le contrôle des flux intra-containers et des containers vers l'hôte +2. les permissions : tous mes containers s'exécutent actuellement en tant que *root* + +Le contrôle du réseau est limité par ce que propose Docker, et plus exactement *docker compose*. J'ai retenu la possibilité de segmenter en plusieurs réseaux et de définir dans quel réseau placer un container avec l'option *-networks*. + +Exemple avec le blog et deux réseaux "blog-backend" et "blog-frontend" : + +```yaml +version: '3' + +services: + stacosys: + container_name: stacosys + image: kianby/stacosys + volumes: + - ${ROOT_INSTALL}/data/stacosys:/config + networks: + - blog-backend + restart: unless-stopped + expose: + - 8100 + blog: + container_name: blog + image: kianby/blogduyax + depends_on: + - stacosys + networks: + - blog-backend + - blog-frontend + restart: unless-stopped + expose: + - 80 + labels: + - traefik.enable=true + - traefik.http.routers.blog.rule=Host(`${HOST_BLOG}.${DOMAIN}`) + - traefik.http.routers.blog.entrypoints=https + - traefik.http.routers.blog.tls=true + - traefik.docker.network=blog-frontend +``` + +Placer un container dans deux réseaux lui procure une adresse IP sur chacun et il a, de facto, accès à tous les containers sur ces deux réseaux. Cela permet de ne pas placer un container avec un rôle de *backend* (comme une base de donnée) sur un réseau *frontend* qui est exposé vers l'extérieur (via Traefik). Cela protège un peu plus d'une compromission d'un container mais ce n'est pas extraordinaire car chaque container peut accéder à la machine hôte et à tous les containers des réseaux auxquels il appartient et ceci sans restriction. + +Je réfléchis à des moyens d'aller plus loin dans la sécurisation avec des techniques officielles. J'ai lu un cas de mise en oeuvre où on désactive la gestion d'iptables par Docker et on crée ses propres règles pour contrôler tous les échanges. Effectivement c'est efficace mais on perd toute la gestion dynamique des containers et on se retrouve à administrer un pare-feu. Je ne souhaite pas aller dans cette voie. + +Pour l'aspect documentation, j'ai utilisé l'outil [Nwdiag](http://blockdiag.com/en/nwdiag/nwdiag-examples.html) pour représenter graphiquement les réseaux qui composent mon déploiement. Les sources sont sur le projet : https://github.com/kianby/selfhosting/ + + +