10
mai

En direct de Boston jour 2 !

Que retenir du jour 2 de l’OpenStack Summit de Boston ?

Prenez un café et 5 minutes pour vous mettre à jour des faits marquants de la journée retenus par l’équipe d’Objectif Libre présente à Boston:
faites une pause OpenStack !

Au menu aujourd’hui :TasseVintage

Keynotes

Les keynotes du second jour, présentées par Mark Collier, ont été ponctuées par plusieurs démonstrations d’interopérabilité :

  • Installation standalone de Ironic : pas besoin de Nova, le projet peut être utilisé en dehors du monde OpenStack. Un rack complet a été déployé sur scène en quelques minutes.
  • Installation standalone de Cinder : l’effet démo a eu lieu, mais Cinder peut maintenant fonctionner de manière autonome, également sans nova.
  • Déploiement multicloud à partir d’un même playbook Ansible de cockroachDB. Plus d’une dizaine d’opérateurs ont étendu un même cluster de base de données en live, chacun sur sa plateforme de cloud (IBM, Rackspace, Ubuntu, …). La démonstration était impressionnante et a montré à quel point l’interopérabilité des plateformes de cloud est devenue importante.

Imad Sousou de Intel a présenté l’engagement de sa société dans la communauté, en mettant en avant la solution Clear Container.

Mark Collier a ensuite interviewé 2 intervenants :

  • Brian Stevens, CTO de Google Cloud
  • Edward Snowden

Quoi de neuf sur les projets

Avec le nouveau format du summit OpenStack sont apparus des nouveaux formats de sessions. Les project updates font le point sur les nouveautés de la version Ocata, le travail en cours pour Pike et pour les versions suivantes (Queens et Rocky). Les présentations sont faites par les PTLs et core developers des projets.

Ironic

Prévu pour Pike

  • support de Redfish
  • driver composition : mix and match des interfaces de plugin pour le boot, le réseau, le mode d’installation…
  • les interfaces réseau peuvent être ajoutées et supprimées dynamiquement
  • boot sur volume cinder
  • rolling upgrades

Kuryr

Prévu pour Pike :

  • première release officielle kuryr-kubernetes
  • support de Neutron LBaaS v2
  • support SSL pour les communications client/serveur
  • packaging RDO
  • support du mode Swarm (ipv6 / ipv4)

Keystone

Prévu pour Pike :

  • les politiques par défaut seront améliorées (gérées dans le code, avec une meilleure documentation)
  • mise en place de fonctionnalités pour la gestion uniforme des limites (pour la définition des quotas par exemple)
  • tags pour les projets
  • Amélioration de l’intégration continue (rolling upgrades et fédération)

Difficile d’assister aux sessions de tous les projets mais le format est agréable et laisse suffisamment de temps pour des questions et échanges avec les développeurs. Un des objectifs du changement de format du summit était d’améliorer les échanges entre utilisateurs et développeurs, c’est réussi avec ces sessions !

Containers et Kubernetes

De nombreuses conférences traitant de Kubernetes sont au programme de ce summit.

Self driving k8s

Tectonic, un produit de l’équipe CoreOS propose une méthode de déploiement originale : laisser k8s se déployer lui même, en utilisant ses propres outils (replica sets, deployments, …).

Un état désiré (nombres de réplicas, services) est défini par l’utilisateur, et le cluster se gère de manière automatique : le processus kubelet s’occupe de déployer, monitorer et réparer les autres composants. Cette méthode permet en particulier de mieux gérer les montées de version. Les processus operators s’occupent également des tâches traditionnellement gérées par les équipes d’admin : application des patchs de sécurité, backups, mises à jour, …

Le projet bootkube permet le démarrage d’un nouveau cluster, et le tectonic installer permet un déploiement complet sur des plateformes de cloud. Ces projets sont Open Source.

SAP : OpenStatck sur K8S

Ce retour d’expérience a montré les avantages d’un déploiement d’OpenStack sur kubernetes. La plateforme SAP a des dimensions non-négligeables : 10 datacenters, 80 000 cores, 100 000 volumes et 40 000 instances.

L’utilisation de OpenStack Helm a permis de faciliter la maintenance de la plateforme, et notamment les montées de version.

Une région entière peut être déployée en moins de 5 minutes.

Conférences de type dive in

Message Bus security with Trove DBaaS

Trove utilise un bus de message pour la communication de ses éléments internes (API, task manager,…) et des agents déployés sur les instances constituant les clusters de base de données. Pour des problèmes de performances, tous les agents sont déployés avec le même credential pour accéder au bus de message. Si une des instances d’un cluster de base de données est compromise, le bus de communication est également compromis…. pas terrible.

La solution proposée lors de cette conférence est de chiffrer les échanges entre les agents et le control plane. Lors du déploiement d’une instance, une clé unique est générée et poussée au client par le gestionnaire de tâches. En cas de compromission d’un agent, seul cet agent est impacté, le bus de communication reste intègre.

Une solution complémentaire évoquée lors de la séance de questions serait de séparer les communications internes et les communications avec les agents sur 2 bus séparés comme dans le projet Murano.

FWaaS : évolution de la v2

L’équipe de développement de FWaaS (firewall as a service) a présenté les nouveautés et l’implémentation de cette nouvelle version du plugin Neutron.

Parmis les nouveautés existantes et à venir :

  • plus de souplesse d’utilisation sur la partie L3
  • un début d’implémentation au niveau L2, sur les ports Neutron

Les détails techniques ont principalement porté sur l’implémentation L2, et les problèmes à résoudre pour éviter les conflits avec les règles existantes des security groups.

Cette nouvelle implémentation est encore jeune, et pas forcément recommandée pour des environnement de production.

Protecting plaintext password in Openstack Service configuration files

Les mots de passe en clair dans les fichiers de configuration Openstack sont un vrai problème de sécurité, et sans gestion centralisée, leur changement devient vite un enfer.
Une solution envisagée serait de chiffrer entièrement les fichiers de configuration. Se pose alors la question du stockage des clés et la complexité pour mettre à jour les fichiers.

Le PoC présenté dans cette session consiste à utiliser custodia (une api de gestion de backend de gestion de secrets comme vault, freeIPA ou barbican) et de l’adapter pour utiliser keystone.
Pour obtenir le mot de passe, une requête est faite sur custodia, qui authentifie le demandeur sur keystone et ensuite utilise le token keystone pour interroger barbican.

Coté plomberie Openstack, Oslo config est modifié pour parser les secrets dans les fichiers de configuration et interroger custodia.

Une limitation dans le design et l’architecture apparait rapidement : custodia devant accéder à Barbican et Keystone, les mots de passse de ces deux entités restent en clair.

A suivre pour voir comment le PoC évolue.

Quelques déceptions

  • La conférence « Protecting plaintext password in Openstack Service configuration files » n’a duré que 10 minutes, sans rentrer dans les détails technique : dommage.
  • Le projet Zun, présenté lors du dernier slot de sessions, ne nous a pas convaincu. Les manières de faire sont intéressantes, mais quel avenir face à Kubernetes ?
  • La soirée organisée au Fenway park n’était à la hauteur des soirées des summit précédents.