OpenStack Summit Vancouver 2018 : jour 4

thumbernail OpenStack


Après Vancouver, Tokyo, Austin, Barcelone, Boston et Sydney, c’est de nouveau à Vancouver que nous nous retrouvons pour l'édition 2018 de l’OpenStack Summit ! 17ème summit OpenStack, Osones vous fait, comme à son habitude, vivre l’OpenStack Summit de Vancouver comme si vous y étiez !


Breakout Sessions

Keystone : Enabling cloud native applications with "Application Credentials"

Colleen Murphy - Suse (développeuse Keystone) @cmurphy

En introduction, rappelons que toute utilisation des API OpenStack nécessite au préalable de s'authentifier en utilisant Keystone, le service d'identité d'OpenStack. Une authentification réussie se concrétise par :

  • la délivrance par Keystone d'un token permettant l'accès aux différents services d'OpenStack et dont la durée de vie est limitée dans le temps,
  • l'attribution d'un "rôle" sur un tenant, généralement "member" ou "admin",
  • le droit d'appliquer des opérations de type CRUD (Create/Read/Update/Delete) sur les ressources virtuelles appartenant au tenant

Du point de vue du mécanisme d'authentification Keystone et de l'obtention des droits sur un tenant, la situation actuelle est la suivante :

  • une authentification réussie, basée sur le principe username/password, confère à l'application les mêmes droits que celui de l'utilisateur utilisé pour l'authentification, en termes de fonctions d' API et d'opérations applicables (CRUD) sur les ressources virtuelles du tenant.
  • le mot de passe du compte Keystone est placé dans un fichier de configuration (openrc, clouds.yaml, {svce}.conf, app.ini,...), la plupart du temps en clair.
  • le changement de ce mot de passe entraîne un dysfonctionnement de l'application car il faut mettre à jour les fichiers de configuration qui contiennent le mot de passe.

Keystone Application Credentials apporte une solution à ces problèmes en introduisant une nouvelle méthode d'authentification spécialement conçue pour les applications. Il s'agit d'une méthode d'authentification de type "scoped". Une Application Credential possède un nom et un ID. Le contrôle d'accès devient granulaire et il est possible de limiter les droits de l'application à un sous-ensemble des droits que possède l'utilisateur qui a créé l'Application Credentials. Ainsi, si le propriétaire des credentials possède le rôle "admin", il pourra limiter l'application a des opérations de lecture sur les différentes ressources du tenant.

Un autre bénéfice remarquable est le fait que le mot de passe de l'utilisateur Keystone ne figure plus dans aucun fichier de configuration.

Par ailleurs, il est possible de créer plusieurs credentials pour une même application et mettre ainsi en oeuvre une politique douce de rotation des credentials.

Basiquement, une Application Credential se crée via la console Horizon ou via le CLI OpenStack avec la commande suivante :

$ openstack application credential create MyAppCred --role member

En retour, Keystone délivre un credential ID et un secret. Il est néanmoins possible de fournir sont propre secret. Également, il est possible de préciser une date et une heure de péremption des credentials.

En fin de session, Colleen nous dévoile deux fonctionnalités majeures prévues par la roadmap court-terme :

  • mécanisme de rotation automatique des credentials
  • nouveau scope "système" permettant aux administrateurs de la plate-forme OpenStack (c.a.d du cloud) d'automatiser des tâches système

Parions que cette nouvelle fonctionnalité très intéressante de Keystone contribuera à accélérer l'adoption par les grandes DSI, et notamment par leurs RSSI, de l'approche Cloud Native Application.

Ce sera tout pour cette semaine, nous espérons que vous avez appréciez ces revues dans lesquelles nous essayons de vous transmettre le maximum d'informations ! N'oubliez pas que toutes les Breakout Sessions sont disponibles en ligne et que vous y avez accès sans modération !

A dans 6 mois pour le Summit de Berlin !

La Team Osones

Découvrez les technologies d'alter way