OpenStack Summit Vancouver 2018

Pause Cloud & DevOps – édition spéciale OpenStack Summit Vancouver 2018

Jour 1

Vous n’avez pas pu venir à Vancouver pour assister à l’OpenStack Summit et vous souhaitez savoir ce qui est annoncé/présenté d’important ? Les consultants d’Objectif Libre sur place vous racontent, comme si vous y étiez.

Au menu : du cloud, de l’Open Source, du stockage, du réseau, de l’Open Infrastructure… tout ce qui fait OpenStack  :

  • Keynotes
  • Amélioration de la sécurité dans Kubernetes et les conteneurs (A devops State Of mind : continuous Security with Kubernetes)
  • Octavia, K8s et terraform
  • Sécurité avec un outil automatique (Security Monkey)
  • vGPU dans OpenStack
  • Roles par défaut pour Rocky
  • Présentation du projet Istio pour du déploiement d’application inter-cloud
  • Fédération de Keystone avec SSO
  • Project Update

Bonne lecture !

Keynotes

Lors de la présentation de cette édition du Summit à Vancouver, Marc Collier met en avant  « L’OpenInfrastructure » en insistant sur le fait que plus de 35 projets Open Source seront présentés lors des sessions.
Pour cette première keynote, Jonathan Bryce et Lauren Sell ont communiqué les nouveaux chiffres sur les implémentations d’OpenStack en 2018:
  • 71% des plateformes OpenStack sont en production durant les 12 derniers mois 
  • 6,1$ milliards de chiffre d’affaires sur OpenStack
  • 10 000 000 de cœurs en production
On retrouve toujours un cycle de production dans le domaine du cloud privé à savoir :    
  • Des cas d’usages (HPC, Self services, Edge computing, Conteneurs…)
  • La collaboration
  • De nouvelles technologies à intégrer (Kata containers)
  • Tests et validation (Zuul, OpenCI, OpenLab…)
Mélanie Witt, PTL du projet Nova, a annoncé les changements apportés dans la release Queens avec notamment les vGPU (partage d’un GPU physique entre plusieurs instances) et le Fast Forward Upgrade (mise à jour simplifiée et accélérée).
Xu Wang et Amy Leeland ont annoncé la sortie de la release de Kata Container pour l’OpenStack Summit de Vancouver. Nous détaillerons lors des prochains jours le contenu de cette release.
Les autres keynotes ont mis l’accent sur l’aspect communautaire de l’OpenInfrastructure et sans entrer en profondeur sur les aspects techniques.
Mark Shuttleworth de Ubuntu/Canonical, a présenté une keynote très offensive, en comparant les coûts des solutions Canonical avec ceux de leurs concurrents. Sans surprise, le montant annoncé par Canonical est inférieur aux autres… mais peut-être que les cas choisis par Mark Shuttleworth étaient favorables ?
Le SuperUser Award a été attribué à l’organisme public OICR (Ontario Institute Cancer for Research) devant les finalistes CityNetwork,Vexxhost et T-Systems.
Enfin, la Fondation a annoncé que l’OpenStack Summit de mai 2019 se déroulerait à Denver (pour rappel, celui de novembre 2018 aura lieu à Berlin).

 

A devops State Of mind : continuous Security with Kubernetes

Par Chris Van Tuin (Red Hat)
Beaucoup de logiciels « disruptent » par leurs technologies (ApplePay, Sporify, Netflix Uber, Lyft…) avec le monde traditionnel de l’IT et on note une accélération du business. On est passé sur des périodes de 6 mois/9 mois de R&D à des livraisons toutes les semaines voire toutes les heures.
L’approche DevOps pour objectifs : 
  • De réduire l’organisation en silos
  • D’accepter la panne comme quelque chose de normal
  • D’insuffler un changement graduel 
  • De mesurer en permanence les changements
Souvent, la sécurité est mise de côté dans une approche DevOps. Ainsi, d’après une enquête de Techvalidate/Redhat, les risques en faille de sécurité proviennent, en majorité :
  • pour 36% des employés qui n’implémentent ou ne respectent pas les mesures de sécurité
  • pour 32% d’attaques externes
  • pour 14% de patchs de sécurité non appliqués
  • pour 11% d’attaques internes réalisées par des salariés
  • etc.
Il est donc nécessaire d’embarquer la sécurité et on parlera dès lors de DevSecOps.
Le DevSecOps permet de :
  • Réduire les risques
  • Réduire les coûts
  • Accélérer les livraisons
  • Augmenter les résolutions des incidents
L’approche conteneurs offre également une réponse à cette méthode car il est simple d’imposer le même niveau de sécurité dans des conteneurs que sur un laptop, un serveur bare metal, une VM, dans un cloud privé ou un cloud public. Il faut respecter le même niveau de sécurité de bout-en-bout (développement, intégration, production) avec quelques bonnes pratiques:
  • Le code intégré doit être immuable
  • La configuration doit être proposée aux conteneurs via des mécanismes chiffrés (secrets pour les mots de passe par exemple)
  • Les données doivent être isolées sur un stockage persistant

La sécurité, pour être efficace, doit être intégrée dans les cycles de déploiement et les mécanismes de CI/CD, avec des scans systématiques par exemple.

Lors des mises en production à l’aide de conteneurs, plusieurs méthodes sont utilisées :
  • Récréer l’infrastructure avec un downtime pour les services non critiques (avantages : simple et rapide ; inconvénients : le downtime)
  • Blue/Green pour les services critiques (avantages: pas d’interruption de service, rollback possible ; inconvénients : infrastructure doublonnée lors de la MEP et impossible lors du changement du schéma de la BDD)  
  • Canary release pour des services critiques qu’on veut tester avant la mise à l’échelle (avantages : pas d’interruption du service,tests sur un petit nombre d’utilisateurs ; inconvénients : avoir en permanence une infrastructure en double).
En conclusion, mettre en place une approche DevSecOps impose la mise en place des métriques suivantes :
  • SLA
  • Fréquence de Mise En Production (MEP)
  • Durée de la MEP
  • Mesure des interruptions de service
  • Mesure de la remise en production du service

 

OpenStack octavia, k8s, terraform

Par German Eichberger (Rackspace), Software Engineer

Objectif

Le but de cette conférence est de déployer aisément une application en HA grâce à :

  • Terraform
  • GopherCloud : plugin go
  • Octavia (projet officiel de LBaaS dans OpenStack)

Aujourd’hui, Terraform est capable de déployer un LoadBalancer Octavia grâce à une simple variable « use_octavia = true ».

GopherCloud ?

GopherCloud est un kit de développement en Go pour OpenStack. Il supporte nativement Octavia.
Terraform utilise notamment GopherCloud pour toute la partie LoadBalancing applicative d’OpenStack (= Octavia).

Fonctionnement

OpenStack fournit grâce à Octavia la fonction de LBaaS ; ceux-là seront visible dans Kubernetes et seront donc directement utilisables en tant que LoadBalancer & Ingress dans Kubernetes.

Pourquoi Octavia+GopherCloud et non pas Nginx:

  • Pour les développeurs : focus sur l’application K8S et non pas sur l’infrastructure OpenStack
  • HA gérée par la plateforme de IaaS et non de CaaS
  • Permet d’avoir une page d’erreur en cas de perte du cluster Kubernetes – cela peut arriver…
  • Pas besoin d’IP flottante pour les workers Kubernetes
  • Avoir un couple IP/port pour chaque LB/service et donc pouvoir utiliser les ports communs tels que 80 / 443
  • En cas d’utilisation d’Octavia pour la partie ingress controller : TLS & load balancing HTTP géré en amont par Octavia

À venir

Conclusion

Ce projet permet de fournir aisément un LoadBalancer OpenStack pour une application fonctionnant dans Kubernetes via Terraform.

 

Protecting OpenStack with Security Monkey

Security Monkey est un outil releasé en Open Source par Netflix en 2014. Basé sur celery, flask et redis pour le message queuing, il est utilisé pour monitorer AWS, et est notamment connu pour stopper aléatoirement des instances EC2 (voire même des régions entières).

Google a ajouté un support pour GCP, et AT&T a récemment ajouté un support pour OpenStack.

Security Monkey est composé des éléments suivants:

  • Watchers : produisent des items, des objets exploitables par le soft.
  • Auditors : analysent les items produits par les watchers et détectent les anomalies.
  • Alerters : déclenchent des alertes.

En ce qui concerne le support d’OpenStack, les watchers supportent les projets « classiques » (keystone, neutron, swift…). Les ressources surveillées sont des instances, des security groups, des routeurs, des réseaux, des objets swift…

Nous avons eu droit à une démonstration extrêmement simple, basée sur la version dockerisée de Security Monkey (déconseillé en production):

  • Un réseau accessible depuis Internet est créé dans un cloud Rackspace.
  • Security Monkey détecte l’anomalie (le réseau ne devrait pas être exposé).
  • Un alerter pousse l’anomalie dans Jira.

La WebUI de Security Monkey est assez poussée, avec possibilité de discuter les issues, etc.

Les briques OpenStack de base sont bien intégrées, les autres sont en cours d’intégration par la communauté. D’autres features sont sur la roadmap de la communauté, comme par exemple une approche event-driven, en opposition à l’approche par polling en place actuellement.

 

Call it real : virtual GPU in Nova !

Par Sylvain Bauza (Red Hat) Core Reviewer Nova

La virtual GPU est une fonctionnalité qui a été réalisée conjointement par l’équipe en charge de libvirt et de Xen. Les besoins pour l’utilisation de GPU dans OpenStack sont multiples:

  • pour du mining des bitcoins et autres cryptomonnaies
  • pour du deep learning
  • pour du Big Data/de l’IA

ll faut noter que la fonctionnalité de PCI PASSTHROUGH est disponible dans OpenStack depuis les versions Havana (libvirt) et Juno (Xen). Ce qui donne la possibilité d’affecter un device PCI pour chaque instance de chaque host. C’est une solution qui fonctionne bien, SAUF pour le VGA : il est par exemple compliqué d’éviter que le host utilise les cartes graphiques en question. Des contournements sont possibles, mais donnaient lieu à des soucis de sécurité (accès privilégié à la mémoire de l’hôte par exemple), à l’impossibilité de monitorer du host (du moins sans avoir accès aux guests), ainsi que le faible nombre de slots PCI par CPU (et donc peu d’instances possibles…).

Grâce au placement API, depuis Newton, il est possible de demander des ressources depuis des resource providers, qui auront en plus certaines caractéristiques.
C’est la fonctionnalité de base qui est utilisée pour la création des vGPU (le resource provider étant le compute avec une caractéristique GPU).

Au final, la mise en place des vGPU est assez simple : activation dans nova du type de GPU, et création d’une flavor spécifique avec une ressource vGPU.

Cette approche présente cependant des limitations:

  • il faut faire des petites adaptations sur le host, comme ne pas utiliser le driver NVidia nouveau habituel mais le driver GRID
  • l’impossibilité de faire des suspend/migrate/resize de ces instances, pour des raisons respectivement propres à libvirt ou à nova
  • la possibilité d’avoir plus de 1 GPU par instance dépend du vendor driver

Une démo enregistrée a été présentée à la fin.

A noter que dans la version Queens on ne peut pas avoir plusieurs types de vGPU par host. Cela sera corrigé en Rocky, via un mécanisme de nested Resource Providers.

Plusieurs améliorations sont également envisagées :

  • Gestion des quotas (pour Stein)
  • Prise en charge de NUMA et CPU pinning dans placement pour avoir jusqu’à 30% de performance en plus
  • Possibilité de prise en charge de live migration avec ces instances, ce qui impose un set capabilities équivalent entre les vGPU et donc leur découverte/gestion.

A noter enfin le projet Cybord qui souhaite fournir un moyen général de gérer des accelerators, dont par exemple GPU et FGPA. Ce projet débute juste, alors que l’on peut dès à présent utiliser des vGPU dans nova.

 

Default-Roles in Rocky

Cette conférence se déroule sous la forme d’un « Fishbowl », c’est-à-dire des personnes réunies autour d’une table. Le sujet ici : les rôles et les policies par défaut présents dans les projets OpenStack. Un point met tout le monde d’accord : il est très difficile de maintenir des rôles personnalisés dans le temps, car cela nécessite de modifier les policies du projet (policies gérées par oslo.policy).

A l’origine, chaque projet doit définir un fichier de policy contenant des scénarios pour un utilisateur, qu’il soit admin ou non (https://review.openstack.org/#/c/245629/).

Une première spécification a été mise au point : l’idée était d’intégrer les policies par défaut directement dans le code de chaque projet, comme c’est le cas pour les configurations des différents projets qui sont dans les fichiers .ini. Si un « operator » veut changer les policies par défaut, il avait juste à écrire un fichier policy.json dans /etc/$(project_name)/policy.json ; de cette manière, les policies par défaut étaient surchargées. Cette approche offre beaucoup de flexibilité aussi bien pour l’operator que pour le developper.

De plus, la génération de la documentation pour les policies est plus facile. Avec cette méthode, l’automatisation des déploiements est clairement simplifiée. Cependant, cette proposition n’a pas été validée par la communauté.
Une autre spécification a été proposée. Celle-ci concerne les scopes des rôles: aujourd’hui, ceux-ci sont liés à un domaine ou à un projet. Cependant, certains appels d’API s’adaptent mal à ce modèle. Par exemple, le fait de lister les hyperviseurs n’est pas lié à un projet. La spec propose donc de différencier le project-scope (scope actuel) du system-scope (scope concernant les actions qui ne se limitent pas à un projet en particulier). Par exemple, un admin du system-scope pourra ajouter et supprimer des hyperviseurs, mais ne pourra pas administrer les projets OpenStack.
En plus des scopes, la spec propose trois rôles par défaut: auditor (membre en lecture seule), member (membre classique) et admin. Chacun de ces rôles inclut le rôle précédent, ce qui simplifie les fichiers actuels (role:member plutôt que role:auditor OR role:member). Tous ces rôles et scopes par défaut pourront être surchargés, mais ceux-ci permettront un contrôle plus fin et une configuration plus lisible. Cette spec est toujours en discussion pour approbation. A suivre donc !

 

Stretching your application from OpenStack into PublicCloud

Par John Joyce (Principal Engineer) and Tim Swanson (Senior Tech Lead) Cisco
    
L’objectif de cette présentation est de montrer comment il est possible de déployer une application sur OpenStack et un autre Cloud provider, ici Google avec Google Kubernetes Engine.
Pour ce faire, c’est Istio, une solution qui permet de gérer, d’interconnecter et de sécuriser des microservices, qui est utilisée. Un cluster kubernetes est déployé sur un cloud privé OpenStack ; l’interaction entre Kubernetes et OpenStack se fait à l’aide du projet « cloud-provider-openstack » (https://github.com/kubernetes/cloud-provider-openstack) ; d’un point de vue réseau, l’utilisation d’un VPN est un prérequis pour que les deux cluster puissent communiquer ensemble.
Istio et ses composants (Pilot, Envoy, etc.) vont gérer le cycle de vie des différents pods et leurs interactions. Dans la démonstration qui suit, la version 1 de l’application est déployée sur GKE et la version 2 est déployée sur OpenStack. Istio intègre un Ingress controller et des CRD (Custom Ressource Definition) permettant de facilement mettre en place une approche de type Canary Release.
Deux usecase sont présentés :
  • Dans un premier temps la moitié des utilisateurs est redirigée vers un cloud, par exemple GKE, pendant que l’autre est redirigée sur une version plus avancée de l’application qui est elle présente sur OpenStack.
  • Dans un second temps, cette même approche a été utilisée par utilisateur nommé. Par exemple, l’utilisateur Foo était automatiquement redirigé vers la version 1 de l’application présente sur GKE et l’utilisateur Bar était redirigé vers la version 2 hébergée sur un cloud OpenStack.
    
Le projet est prometteur malgré sa jeunesse, et de nombreuses améliorations sont prévues, notamment  : 
  • Avoir une meilleure couverture de tests sur l’intégration du multi-cluster
  • Faciliter l’utilisation du projet
  • Ne plus être contraint d’avoir un VPN entre les différents cloud providers

 

Federated Keystone SSO with FreeIPA and OpenID Connect

Par Martins INNUS et Andrew BRUNO (centre de recherche de l’université Buffalo)

Objectif principal : permettre aux utilisateurs de pouvoir s’authentifier de façon simple sur leur plateforme OpenStack.

La conférence débute avec un rappel du principe de fédération d’identité et les technologies choisies en conséquent.

La fédération d’identité inclut 3 acteurs : le fournisseur d’identité (IdP : FreeIPA), le service provider (SP: OpenStack) consommateur des identités délivrées par l’IdP, et le protocole (FP : OpenID).

Implémentation à l’université de Buffalo

IDP

L’université de Buffalo a choisi d’utiliser la solution FreeIPA pour l’aggrégation de leurs technologies d’authentification et d’autorisation (LDAP, AD, etc.). Cependant, cette solution n’implémente pas nativement le protocole OpenID.

Pour cela, les ingénieurs du centre de recherche ont choisi d’implémenter leur propre solution permettant :

  1. D’assurer la prise en charge du protocole OpenID (Hydra)
  2. De gérer l’interaction des clients avec le protocole OpenID

Le projet Mokey (https://github.com/ubccr/mokey) est né de cette réflexion, et permet de gérer l’interaction entre le fournisseur d’identité (FreeIPA), Hydra (gestion du protocole OpenID/OAuth2 entre le client et l’IdP), et le client (lui, nous, vous !)

FP

Sans grande surprise : OpenID. Le protocole d’authentification/autorisation est une surcouche au protocole OAuth2, permettant de gérer (en plus d’OAuth2) l’authentification auprès d’un service d’identité (ex: LDAP).

Au milieu de tout cela, l’application Mokey permet d’assurer l’interaction entre l’utilisateur et le l’IdP ; comme le souligne Martins : « Une simple application de consentement à l’utilisation du service OpenStack ».

SP

Nous y retrouverons bien entendu OpenStack, fournisseur du service et donc consommateur du service d’identité.

Configuration

L’implémentation côté Horizon reste basique :

  • Horizon : référencement de l’IdP dans l’interface de connexion
  • Keystone : référencement de l’IdP dans la BDD
  • Apache : configuration OpenID via le module mod_auth_openidc

Pour plus d’information : https://docs.openstack.org/keystone/queens/advanced-topics/federation/federated_identity.html

Note de l’auteur : le mod_auth_openidc offre une fonctionnalité de cache incontournable en cas de mise en haute disponibilité (https:github.com/zmartzone/mod_auth_openidc/wiki/Caching)

Conclusion

Présentation très concrète, aggrémentée de nombreuses lignes de commandes de la phase de mise en place, d’exemples de mapping, et d’utilisation. Notons tout de même un dernier point essentiel : la CLI ! En effet, Martins et Andrew nous présentent leur implémentation maison du protocole OpenID avec le CLI OpenStack officiel : v3oidcmokeyapikey (https://github.com/ubccr/v3oidcmokeyapikey). Ce projet permet d’assurer une intégration complète du CLI OpenStack avec leur solution d’authentification OpenID.

Les futures pistes d’évolution pour l’université de Buffalo ? La fédération multi-sites et la mise à jour de Hydra.

À retenir :

  • SSO à base d’Openstack + OpenID : fonctionnel
  • Intégration d’OpenID avec le CLI : demande du spécifique pour simplifier les manipulations (projet v3oidcmokeyapikey)

 

Project Updates

La majorité des projets OpenStack proposent une présentation de leur actualité : ce sont les sessions « project update ». Durant cette journée, Octavia a retenu notre attention :

Octavia

Par Michael Johnson (Rackspace) PTL de Octavia

La présentation commence par un état des lieux d’Octavia, le load-balancer à la demande de OpenStack qui est vendor-neutral. Lors de Ocata, Octavia devenu un projet indépendant – il s’agissait auparavant d’un sous-projet de neutron. C’est d’ailleurs la feature du scope de neutron que, selon les 2 derniers OpenStack surveys de 2016 et 2017, le plus de personnes « utilisent, sont intéressées à utiliser ou pensent utiliser ».

La release de Queens (février 2018) a été marquée par les éléments suivants:

  • 90 contributions de 30 sociétés –  ces chiffres sont en augmentation
  • Amélioration du dashboard horizon
  • Ajout de QoS Neutron pour la VIP du Load-Balancer
  • Travail autour de TLS offload (avec ajout de Castellan pour permettre le stockage dans Vault)
  • Enfin, dépréciation de neutron-lbaas

Comme pour tout projet OpenStack, le développement est particulièrement intense en ce moment.

Les éléments principaux qui apparaîtront dans Rocky et qui ont été remontés par Michael Johnson sont :

  • Support pour avoir des drivers third party dans l’API v2 de Octavia, comme dans neutron-lbaas, afin d’étendre l’API
  • Support de l’UDP
  • Exposition des time-out des listeners via l’API
  • Amélioration des tests avec un nouveau plugin Tempest (pour l’API v2 et différents scénarios)
  • Outil de migration de neutron-lbaas vers Octavia
  • Amélioration des VMs (réduction de la taille des images de amphora en se basant sur ubuntu minimum et gestion des flavors)
  • Enfin, le active/active est une priorité mais il n’est pas certain que ce soit possible de le réaliser car les choix d’architecture sont en cours de discussion (au niveau BGP surtout)

Une vision à plus long terme que Rocky a été donnée :

  • Le support de Active/Active avec de l’autoscalling est LA priorité
  • Log offloading pour permettre une visualisation des flows
  • Suppression de neutron-lbaas (qui va cependant rester au moins pour 2 cycles). Ce point est très important, c’est pourquoi moyens et éléments pour y arriver sont proposés : FAQ, plusieurs manières de rediriger les requêtes faites au neutron-lbaas vers l’API Octavia (soit via un pass-through proxy dans neutron soit des policies L7). Enfin, un outil de live migration de neutron-lbaas vers Octavia va bientôt arriver.

Pour finir la présentation, plusieurs sujets de travail cross-project ont été donnés:

  • Mettre amphora dans des conteneurs
  • Utiliser les default RBAC roles proposés par la team keystone