ObjectifLibre-DockerCon2018

Cette semaine, les consultants d’Objectif Libre étaient à Barcelone à l’occasion de la DockerCon Europe.

La Pause Cloud & DevOps de la semaine vous propose donc dans son édition spéciale un condensé des annonces, sessions et conférences qui ont marqué ces trois jours.

Au menu : des conteneurs bien sûr !

  • Sécurité
  • Surveillance
  • Docker Desktop Enterprise
  • Docker-app
  • Docker-assemble
  • Buildkit
  • Docker EE 2.1
  • Open Policy Agent
  • De la difficulté de débugger les grosses infrastructures distribuées

Bonne lecture !

Sécurité

La présentation des sponsors annonce la mouvance et les préoccupations actuelles des acteurs du cloud computing : la sécurité de la chaîne d’intégration continue, jusqu’à l’exploitation.

Les problématiques de sécurité s’articulent principalement autour de deux axes :

  • le scan d’images : ce mécanisme est généralement réalisé sur les layers de l’image, parfois sur les binaires embarqués et se réfère à une base de données de vulnérabilités propre à l’éditeur.
  • des analyses et des interventions au runtime : les outils peuvent détecter des modifications effectuées dans les conteneurs ou des comportements anormaux. La qualification de ces derniers est soit issue d’un profiling, soit de règles pré-écrites.

Ces mécanismes de sécurité sont intégrés (ou le seront prochainement) dans des orchestrateurs tels que Kubernetes ou OpenShift.

 

Surveillance

Nous constatons aussi une recrudescence d’outils consacrés à la surveillance des conteneurs au runtime. L’objectif de ces outils est de collecter les données en positionnant des sondes au niveau du noyau, interceptant tous les appels système de l’hôte et donc des processus présents à l’intérieur des conteneurs.

Des tableaux de bord détaillés font leur apparition, permettant une vision globale au runtime ainsi qu’une analyse comportementale plus précise à froid.

 

Docker Desktop Enterprise

#dockerDesktopEnterprise #windows #mac #k8s

C’est l’annonce de la version Entreprise de Docker Desktop (Windows & Mac OS X) qui a pour objectif de simplifier la vie des développeurs.

Les annonces principales sont les suivantes :

  • Installation et paramétrage sans droit particulier et en appliquant les politiques de sécurité de l’entreprise (verrouillage de proxy, …).
  • Un Kubernetes local disponible en un clic, et même simultanément avec Swarm.
  • Des templates d’applications pour initialiser des stacks pouvant être personnalisés.
  • Bascule entre plusieurs versions de docker engine en un clic.

Le mode de « licencing » est différent de Docker EE.
Scoop : la version Linux est en cours de réflexion, une étude de marché est en cours pour déterminer l’intérêt.

 

docker-app

#dockerDesktopEnterprise #cloud #experimental #docker-compose

docker-app est un outil entreprise en CLI permettant :

  • d’enrichir un docker-compose pour préparer son déploiement dans un orchestrateur
  • de gérer cette stack dans l’orchestrateur choisi : déployer, démarrer, arrêter, vérifier

HELM est supporté.

En savoir plus : https://github.com/docker/app

 

docker assemble

#dockerDesktopEnterprise #cloud #experimental #dockerfile

Comme docker-app, docker assemble est un outil entreprise en CLI permettant de dockeriser une application. Il va explorer le code de l’application et ses fichiers descriptifs (pom.xml, …) pour générer automatiquement un dockerfile optimisé. Il peut découvrir les ports à ouvrir et, pour des applications web, ajouter un healthcheck.

 

buildkit

#experimental #dockerimage

Buildkit est le nouvel outil de docker core pour fabriquer des images à partir d’un dockerfile. L’objectif est l’optimisation de la taille des images et du temps de build. La commande standarde RUN est enrichie d’options permettant de faire un point de montage, de « passer » des secrets ou d’ouvrir une connexion ssh ; tout cela seulement pendant le temps de vie du build ! Il permet en outre de gérer un cache « applicatif » pour accélérer les build riches en dépendances (go, npm, …). Buildkit est également accessible via l’API Docker.

Buildkit n’est pas activé par défaut mais peut l’être via une variable d’environnement ou en configurant le daemon.json.

En savoir plus : https://github.com/moby/buildkit

 

Docker EE 2.1

#dockerEE #k8s #windows #secu

La plateforme évolue pour mieux supporter de nouvelles versions de Windows Server.

L’intégration de Kubernetes s’améliore avec :

  • le support du RBAC
  • le chiffrement des réseaux internes
  • la gestion des CPU et des réplicas directement depuis l’interface.

Les métriques sont plus nombreuses dans l’interface (node, pods), ainsi que les logs et les events des différents objets gérés. Prometheus peut être utilisé comme backend de Docker EE. La sécurité se renforce avec des audits de logs pouvant provenir de Swarm, Kubernetes ou encore du registry intégré (DTR). D’ailleurs, ce dernier permet de signer les images afin de garantir leur intégrité lors de leur utilisation en production par exemple.

 

Open Policy Agent (OPA)

#secu #blackbelt

L’environnement de run des conteneurs, composé de plateformes et de langages hétérogènes, est très dynamique et volatile. Cela apporte des problématiques complexes à résoudre telles que les politiques de sécurité et de contrôles d’accès aux ressources.

OPA propose une réponse à ces problématiques en rendant abstraites l’écriture et la mise en place des politiques de sécurité. Il simplifie la gestion des requêtes d’autorisation, mais aussi l’écriture, le test et l’audit des ACL ou RBAC. Ces règles, écrites au format JSON, sont consultées lorsqu’un applicatif fait une requête d’authentification.

Pour évaluer une requête, OPA peut utiliser des données métier pour enrichir le contrôle d’accès. Par exemple, sur une plateforme de ticketing, OPA peut permettre l’accès aux données d’un utilisateur uniquement à l’opérateur assigné aux tickets ouverts par ce premier.

OPA se propose donc, moyennant un appel depuis l’applicatif, de prendre en charge la gestion d’accès de celui-ci. Il centralise également les règles de sécurité qui peuvent être testées et auditées. Ces dernières peuvent ainsi être réutilisées ou partagées d’une application à l’autre en étant agnostiques du langage de programmation ou du type de plateforme utilisés.

En savoir plus :

 

De la difficulté de débugger les grosses infrastructures distribuées

#blackbelt #cloud

Le développement du cloud amène de nouvelles contraintes pour débugger et monitorer les applications : pas de localisation (où tourne ce container ?), réseau (cluster multi datacenter), scheduling et dépendances. Il faut connaître le chemin critique des traitements, des données ou encore des requêtes. Des outils comme OpenCensus permettent la collecte de métriques et de traces distribuées.

Ce constat en tête, nul doute que nous assisterons prochainement à la naissance d’un certain nombre de projets facilitant le débug sur ce type d’environnement.