07

Quoi de neuf dans l’actualité OpenStack ?

 

 

openstack_logo_mark

Le calendrier de l’Avent est maintenant bien entamé.

 

TasseVintage

Prenez un café et 5 minutes pour vous mettre à jour des derniers faits marquants et des tendances du moment : faites une pause OpenStack !

 

 

Au menu aujourd’hui :

> Suse récupère les activités OpenStack Helion et CloudFoundry de HPE

> Octavia arrive dans la big tent d’OpenStack

> Tricircle arrive dans la big tent d’OpenStack

> T-systems, HPE et IBM en lice pour le cloud hybride du CERN

> Les bonnes pratiques pour sécuriser les conteneurs Docker

> et en bonus : 2 nouveaux articles pour revenir sur l’OpenStack Summit de Barcelone à lire ici

 

Bonne lecture !

 


Suse récupère les activites OpenStack Helion et CloudFoundry de HPE

 

HPE vient de céder la partie OpenStack Helion, solution de IaaS privée, et la partie PaaS avec CloudFoundry Stackato à la société Suse. Le constructeur préfère confier son activité à un partenaire de confiance et se recentrer sur son métier initial.

Cette annonce fait logiquement suite à la fusion des activités logicielles de HPE avec la maison mère de Suse, MicroFocus, début septembre.

 

La point à retenir : Suse ajoute à son portfolio une offre de PaaS avec CloudFoundry et va pouvoir accompagner ses clients avec du IaaS avec leur offre OpenStack, au PaaS avec CloudFoundry et également sur le CaaS avec Micro OS.

HPE va continuer de vendre ses solutions à travers son partenaire Suse et les marques HPE Helion et Stackato vont être conservées.

 

En savoir plus :

http://www.linformaticien.com/actualites/id/42422/suse-recupere-les-activites-openstack-iaas-et-cloudfoundry-paas-de-hpe.aspx

http://www.silicon.fr/hpe-cede-lexpertise-openstack-et-cloudfoundry-a-suse-164003.html


Octavia arrive dans la big tent d’OpenStack

Historiquement dans le projet OpenStack, le Load Balancer as a Service était géré par Neutron. Octavia va maintenant devenir le projet officiel de Load Balancer as a Service en entrant dans la Big Tent.

Les nouvelles fonctionnalités attendues sont les suivantes :

  • Le support des conteneurs

  • La scalabilité horizontale

  • La haute disponibilité du control plane

  • La clustering actif/actif

 

L’intégralité des nouvelles fonctionnalités sont consultables sur le site du projet.

 

En savoir plus :

https://review.openstack.org/#/c/313056/

https://wiki.openstack.org/wiki/Octavia (wiki)

https://wiki.openstack.org/wiki/Octavia/Roadmap (road map)


Tricircle arrive dans la big tent d’OpenStack

Tricircle est une API d’OpenStack qui fait son entrée dans la big tent. Tricircle fonctionne en étroite relation avec Neutron et permet d’automatiser la gestion des réseaux Neutron sur une infrastructure OpenStack Multi-régions.

 

Partons d’un cas client pour expliquer son fonctionnement. Prenons 2 OpenStacks multi-régions. (i.e. partageant le même keystone pour l’authentification mais gérant eux-mêmes tous les autres services). Sur le 1er OpenStack, il n’est plus possible de lancer de nouvelles instances par manque de place et nous souhaitons donc lancer des instances sur le 2ème OpenStack en gardant la connectivité entre les VM.

Pour faciliter la communication entre 2 OpenStack multi-régions, il faudrait mettre en place des mécanismes réseau suivants :

  1. Création d’un routeur pour joindre les 2 OpenStack

  2. Création d’un nouveau sous-réseau sur le deuxième OpenStack

  3. Lancement d’une VM depuis le deuxième OpenStack

 

Cette méthode ne permet pas l’isolation des réseaux entre les 2 OpenStacks, et la création de deux réseaux jumeaux pourrait apporter des problématiques de concurrence en terme d’adressage MAC et IP sur chacun des OpenStacks.

Tricircle est fait pour répondre à cette problématique. Voici les mécanismes qui se mettent en place lors du déploiement d’une VM sur le deuxième OpenStack avec Tricricle :

  1. Création du même réseau et du même sous-réseau en automatique

  2. Création du même security group

  3. Délivrance d’une Mac adresse unique et d’une adresse IP distincte du premier réseau

  4. Encapsulation des paquets L2 en L3 pour la communication Est-ouest entre les VM

Dans ce cas particulier, Tricircle facilite donc la connectivité entre 2 VM.

 

 

En savoir plus :

https://review.openstack.org/#/c/338796/

https://wiki.openstack.org/wiki/Tricircle

 


T-systems, HPE et IBM en lice pour le cloud hybride du CERN

 

Le CERN est à la recherche d’un prestataire pour hybrider sa solution de cloud Helix Nebula. Cette plateforme à destination de la communauté scientifique est issue du consortium de 18 entreprises (Atos, Capgemini, Logica, OBS…). Le CERN a lancé un appel d’offres publics en juin 2016 pour sélectionner l’entreprise qui sera en charge de la phase de Build et de Run de la solution de cloud hybride.

 

 

A ce jour, le CERN a short-listé 4 consortiums :

  • T-Systems, Huwawei , Cyfronet et Divia

  • IBM

  • RHEA Group, T-Systems, Exoscale et SixSq

  • Indra et HPE

Le CERN met l’accent sur une infrastructure OpenStack hors normes avec 7000 serveurs et 190 000 cœurs et insiste sur la capacité que l’offre retenue doit être capable de gérer : un grand nombre de VM, au moins autant de conteneurs, tout cela pour réaliser du HPC et générant donc des Petatoctets de données.

 

Le CERN a reçu les 4 nommés pour qu’ils présentent leur offre de IAAS :

  • T-systems consortium 1 a présenté Open Telekom Cloud, offre basée sur OpenStack

  • T-systems consortium 2 a présenté une offre basée sur Cloudstack

  • IBM a présenté une offre basée sur Softlayer

  • Le consortium HPE a présenté Cloud 28+, offre basée sur Helion OpenStack

 

Les prochaines étape clés de ce projet gigantesque sont les suivantes :

  • Janvier 2017 le CERN va éliminer un des 4 consortium

  • Février 2017 les 3 consortium vont réaliser un POC

  • Octobre 2017 après analyse 2 POC seront retenus

  • Décembre 2018 résultat final

 

 

En savoir plus :

http://www.silicon.fr/t-systems-hpe-et-ibm-en-lice-pour-le-cloud-hybride-cern-163664.html?utm_source=2016-12-06&utm_medium=email&utm_campaign=fr_silicon_dsi&referrer=nl_fr_silicon_dsi&t=57aa6c2994742a3c4cd7f6ce514a70f11786243

 


Les bonnes pratiques pour sécuriser les conteneurs Docker

Le Sans Institute est une organisation américaine à but non lucratif regroupant 165 000 professionnels de la sécurité (Sans signifie  Sysadmin, Audit, Network et Security). Il publie une liste de bonnes pratiques pour améliorer la sécurité dans les conteneurs Dockers.

Cette liste devient essentielle :

  • La sécurité est de plus de plus en plus contraignante sur des architectures de type conteneur versus VM/Legacy

  • L’arrivée de nouvelles méthodes telles que le Devops et les micro-services contraint à revoir la sécurité en profondeur

  • Le manque de standardisation des outils de sécurité est contraignant pour auditer les systèmes Docker

 

Le Sans Institute souligne également qu’il est difficile d’auditer des architectures Docker car elles sont souvent éphémères et très complexes.

D’après les chiffres de New Relic :

  • 46 % des conteneurs ont une durée de vie < 1h

  • 11 % des conteneurs ont une durée de vie < 1min

 

Un autre point analysé est la difficulté d’agir sur les vulnérabilités multiples entre les OS parents et les conteneurs. Il faudra souvent traiter différemment ces vulnérabilités en utilisant des outils distincts. De plus, si une entreprise utilise des images Docker externes, elle augmente ses risques de vulnérabilité (30 % des images sur « Docker hub » présentent des vulnérabilités).

Le Sans Institute dresse constat qu’il est donc primordial de mettre en place des bonnes pratiques de sécurité.

Il en dénombre 31 dont nous listerons les principales :

  • L’installation des patch de sécurité au niveau des hôtes mais aussi des Docker

  • La ségrégation des conteneurs en fonction de la confidentialité

  • L’installation limitée aux seuls composants utiles

  • La centralisation des logs

  • Le durcissement de l’hôte

  • L’utilisation d’images signées

  • L’interdiction de faire tourner un processus en « root »

  • Gestion du chiffrement des mots de passe (Vault, Keywhiz ou Crypt)

  • Désactiver les communications inter-conteneur

  • L’utilisation de Docker Bench Security pour la partie audit

 

 

En savoir plus :

https://www.sans.org/reading-room/whitepapers/auditing/checklist-audit-docker-containers-37437

http://www.silicon.fr/31-bonnes-pratiques-securiser-conteneurs-docker-163501.html