Introduction à l’orchestrateur de conteneurs Kubernetes

Manipuler quelques conteneurs sur des environnements de développement est une tâche facile. Lorsqu’il s’agit de faire passer ces conteneurs en production de nombreuses questions se posent :

  • Comment gérer les dysfonctionnements ?
  • Comment gérer les déploiements et leurs emplacements ?
  • Comment gérer le scaling ?
  • Comment gérer les mises à jours ?
  • Comment gérer la communication entre les conteneurs ?
  • Comment gérer le stockage nécessaire à la persistance des données ?
  • Comment gérer les secrets et la configuration ?
  • etc.

Tout gérer de manière manuelle et sans surcouche au système de conteneurs n’est pas viable, maintenable et pérenne.

 

Présentation de Kubernetes

Kubernetes (k8s en abrégé) est un orchestrateur de conteneurs initialement développé par Google en 2015 puis offert à la CNF (Cloud Native Computing Foundation). La solution est développée avec le langage Go (aussi à l’origine de Google).

k8s est leader sur le marché de l’orchestration de conteneurs mais dispose quand même de quelques concurrents: Docker Swarm et Apache Mesos/Marathon.

 

Comment fonctionne Kubernetes ?

Kubernetes propose une surcouche aux moteurs de conteneurs (ex : Docker, rkt ou CRI) en introduisant la notion de pod.

Un pod est un élément composé généralement d’un conteneur, une configuration réseaux et une configuration sur le stockage. Les pods doivent être considérés comme jetable, ils sont instanciés et détruits au cours de la phase de run d’une application.

Ces pods sont gérés par des deployments. Un deployment définit la configuration des pods, le nombre de répliquas souhaités, la stratégie de mise à jour des pods, etc. C’est grâce au deployment que le nombre de pods actifs demandé est maintenu sur un environnement. En cas de défaillance d’un pod, il est supprimé et un nouveau pod est instancié.

Pour gérer le load balancing et la communication avec les pods, k8s introduit la notion de service comme point unique de communication avec plusieurs pods. Les pods étant « mortels », il n’est pas possible de se baser directement sur leurs IPs.

Pour la même raison, aucune donnée persistante ne peut être stockée au niveau des pods. Pour persister de la donnée, des PersistentVolumes pointant vers des volumes réseaux, des volumes sur AWS (EBS), Azure, etc sont créés au niveau du cluster k8s. Une fois ces volumes créés, un PersistentVolumeClaim doit être créé pour réserver un espace sur un PersistentVolume.

La vision présentée ci-dessus est une introduction. De nombreux autres paramètres et concepts sont proposés par k8s pour définir de manière très fine la gestion des conteneurs.

Exemple concret :
– Création d’un deployment spécifiant 3 répliquas de pods basés sur l’image Docker d’un service web en Java exposant le port 9000.
– Création d’un service exposant le port 80 et redirigeant vers le port 9000 des 3 pods du service web.
– Création d’un PersistentVolume de 100Go basé sur un volume EBS de AWS
– Création d’un PersistentVolumClaim de 10Go avec le mode d’accès « ReadOnlyMany » permettant au volume d’être monté en lecture seul sur plusieurs nodes (worker K8s).

 

Pour simplifier la compréhension, les exemples ci-dessus sont basés sur l’utilisation du moteur de conteneurs Docker et de son format d’images associé. Kubernetes gère également le runtime rkt de CoreOS.

Pour faciliter l’intégration des moteurs de conteneurs, Kubernetes propose la CRI (Container Runtime Interface) composée d’un API, de spécifications et de librairies. CRI-O est une implémentation de CRI proposant une alternative plus légère au runtime Docker tout en supportant son format d’image. L’utilisation de CRI-O dispense donc de l’utilisation du runtime Docker au niveau des nodes k8s.

Concernant l’installation de Kubernetes, il peut être installé on-premises ou sur un cloud public (AWS, Azure, IBM, etc.). Un bon moyen de tester Kubernetes est de l’installer sur un poste local via minikube.

 

Comment Kubernetes répond aux questions posées en introduction ?

Les Deployments répondent aux problématiques :

  • de dysfonctionnement en assurant que le nombre de répliquas actifs demandé soit toujours respecté.
  • de déploiement sur des emplacements spécifiques (node) avec la notion d’affinity et de nodeSelector
  • de scaling en ajustant le nombre de répliquas en fonction des besoins
  • de mise à jour en spécifiant la stratégie adéquate et en utilisant les mécanismes de rollback

Les Services répondent aux problématiques de communication avec les conteneurs.

Les PersistentVolumes et PersistentVolumeClaims répondent aux problématiques de persistance des données.

Les ConfigMaps répondent aux problématiques de configuration en sortant ces éléments liés aux environnements (préproduction, production, etc.) des conteneurs.

Enfin, la notion de Secrets permet de garder le contrôle sur les données sensibles de type mot de passe, clé d’API, etc.

 

Ressources

[Cybersécurité] OpenSAMM, modèle de maturité pour le développement d’applications sécurisées

OpenSAMM (Software Assurance Maturity Model) est un des projets « Flagship » de l’OWASP (Open Web Application Security Project) permettant d’évaluer, définir et mettre en place une stratégie de sécurité pour les applications.

Le projet propose de découper le développement logiciel en 4 domaines divisés en 12 sous-domaines. On retrouve globalement les différentes étapes du SDLC.

Catégories OpenSAMM

 

Fonctionnement

Chaque sous domaine est divisé en 4 niveaux de maturité.

  • 0 : Niveau implicite de départ
  • 1 : Compréhension initiale et mise en place de pratiques de sécurité
  • 2 : Amélioration de l’efficacité/efficience des pratiques de sécurité
  • 3 : Maîtrise complète des pratiques de sécurité

Pour chaque sous-domaine, plusieurs éléments sont associés à chaque niveau de maturité :

Note : les exemples associés ci-dessous proviennent du niveau de maturité 1 du sous-domaine « Education and Guidance » du domaine « Governance ».

  • L’objectif à atteindre pour compléter le niveau de maturité
    exemple :
    – Fournir aux collaborateurs des ressources documentaires sur le développement et de déploiement sécurisés d’applications
  • Les activités à mener pour atteindre l’objectif
    exemple :
    – Faire une formation de sensibilisation à la sécurité
    – Ecrire et maintenir des guides techniques
  • Les questions à se poser pour évaluer la stratégie de sécurité en place
    exemple : 
    – Les développeurs ont-ils reçu une sensibilisation à la sécurité ?
    – Les membres des équipes projet savent-elles où chercher les guides et bonnes pratiques de développement sécurisé ?
  • Résultats attendus après avoir satisfait les objectifs
    exemple : 
    – Prise de conscience des développeurs sur les problèmes de développement les plus communs
    – Application des règles de sécurité de base sur les logiciels
    – Définition d’un niveau de connaissance minimum en sécurité pour les collaborateurs techniques
    – Mise en place de contrôles de ce niveau minimum de sécurité
  • Les métriques à mesurer et leurs seuils d’acceptation
    exemple :
    – Plus de 50% des développeurs a été sensibilisé durant la dernière année
    – Plus de 75% des développeurs seniors/architectes a été sensibilisé durant la dernière année
    – Commencer le guide technique dans les 3 mois après la 1re formation
  • Les coûts associés
    exemple :
    – Coût de la formation (à construire ou via une prestation)
    – Maintenance du guide technique
  • Les acteurs impliqués
    exemple :
    – Développeurs
    Architectes
  • Les autres sous-domaines liés avec les niveaux associés
    exemple :
    – Policy & Compliance niveau 2
    – Security Requierement niveau 1
    – Secure Architecture niveau 1

 

Comment mettre en place OpenSAMM ?

Pour mettre en place OpenSAMM il faut suivre les différentes étapes proposées :

Etapes OpenSAMM

  • 1 – Prepare – Préparer
    objectif : s’assurer de bien démarrer le projet
    activités :
    – Définir le périmètre
    – Identifier les collaborateurs
    – Communiquer sur l’initiative
  • 2 – Assess – Evaluer
    objectif : identifier et comprendre le niveau de maturité actuel
    activités :
    – Evaluer les pratiques déjà en place
    – Déterminer le niveau de maturité actuel
  • 3 – Set the target – Définir la cible souhaitée
    objectif : définir le niveau cible dans chaque sous-domaine
    activités :
    – Définir la cible souhaitée
    – Estimer les impacts
  • 4 – Define the plan – Définir le plan
    objectif : définir le plan pour arriver à l’objectif souhaité
    activités :
    – Définir le nombre de phases pour atteindre l’objectif
    – Définir le planning
  • 5 – Implement – Mettre en place
    objectif : réaliser le plan défini
    activités :
    – Mettre en place les mesures nécessaires
  • 6 – Roll-out – Mettre à disposition
    objectif : S’assurer que ce qui a été mis en place est utilisé
    activités :
    – Communiquer sur les améliorations
    – Mesurer l’efficacit

 

Calcul du niveau de maturité d’une organisation

Le niveau de maturité se définit par sous-domaine (« Education & Guidance » par exemple). Il est calculé en fonction d’un barème lié aux réponses aux questions de chaque niveau de maturité.

L’exemple ci-dessous expose le nombre de points à ajouter pour chaque réponse.

Barèmes OpenSAMM

Pour le sous-domaine « Education & Guidance », un exemple de réponses serait  :

  • Have developers been given high-level security awareness training?
    réponse : Once => 0,2 point
  • Does each project team understand where to find secure development best-practices and guidance?
    réponse : Half=> 0,5 point
  • Are those involved in the development process given role-specific security training and guidance?
    réponse : No => 0 point
  • Are stakeholders able to pull in security coaches for use on projects?
    réponse : Some => 0,2 point
  • Is security-related guidance centrally controlled and consistently distributed throughout the organization?
    réponse : Per Team => 0,2 point
  • Are developers tested to ensure a baseline skillset for secure development practices?
    réponse : No => 0 point

Dans ce cas le score est de 1,1, ce qui se traduit par un niveau de maturité 1+.

Aide à la mise en place

Pour aider à la mise en place d’OpenSAMM, l’OWASP met à disposition un fichier Excel permettant de :

  • Evaluer le niveau de maturité par sous-domaine en répondant aux questions. En fonction des réponses, le score par sous-domaine est automatiquement calculé.

Evaluation Excel OpenSAMM

  • Proposer en fonction des réponses données ci-dessus une roadmap pour améliorer les scores. Cette roadmap est composée de 4 phases et propose dans chaque itération d’améliorer un ou plusieurs point. L’évolution du score par phase est indiqué.

Roadmap Excel OpenSAMM

  • Proposer des statistiques sur la situation actuelle et la situation cible.

Statistiques Excel OpenSAMM

Ainsi que des graphiques sur l’avancement proposé par la roadmap

Statistiques Roadmap Excel OpenSAMM

 

Ressources

[Cybersécurité] Secure Software Development Life Cycle (SSDLC)

Le cycle de de vie du développement d’un application est l’ensemble des étapes de réalisation d’un logiciel dans le but de construire un produit de qualité.

L’intégration de la sécurité dans le SDLC intervient à chaque étape de celui-ci et se matérialise de plusieurs manières (threat modeling, review, SAST, DAST, etc.).

Ci-dessous, une liste non-exhaustive d’actions à mener au sein du SDLC pour délivrer une application sécurisée.

Ressources

[Cybersécurité] Surveiller vos dépendances avec Dependency Check de l’OWASP

Selon le Gartner, dans une application, 80% du code est fourni par des dépendances (spring, ORM, parsing de XML/JSON, etc.). Sur 95% des applications qui contiennent des dépendances opensource, 65% contiennent des dépendances vulnérables.

Malheureusement, lorsqu’une dépendance est installée pour un besoin spécifique, le suivi est rarement fait pour se tenir à jour des nouvelles versions et encore moins des vulnérabilités qui pouvant l’affecter.

Dependency Check

L’OWASP propose un outil nommé Dependency Check permettant de lister et vérifier automatiquement pour toutes les dépendances d’une application si une CVE (Common Vulnerabilities and Exposures) a été publiée pour la version utilisée. La base de données utilisée par Dependency Check est le NVD Data Feeds proposée par le NIST.

Dependency Check est actuellement mature pour Java, .NET et expérimental pour Ruby, Node.js, Python et C/C++. Il est disponible sur la forme d’un plugin Maven, un plugin Gradle, une tâche Ant, un plugin Jenkins ou un executable en ligne de commande. Il existe également un plugin Sonarqube permettant d’intégrer directement les résultats dans les « issues » et les « measures ».

Glossaire

  • CVE (Common Vulnerabilities and Exposures) : Dictionnaire public maintenu par le MITRE et permettant d’identifier des vulnérabilités sur des composants logiciel

Exemple :

CVE-2017-9787 – When using a Spring AOP functionality to secure Struts actions it is possible to perform a DoS attack when user was properly authenticated. Solution is to upgrade to Apache Struts version 2.5.12 or 2.3.33.

  • CWE (Common Weakness Enumeration) : Classe de vulnérabilités

Exemple : SQL Injection

  • CPE Confidence : Indice de confiance sur la reconnaissance d’une dépendance et de sa version
  • Evidence : Preuve permettant de déterminer le nom et la version d’une dépendance

Exécution via Jenkins

En intégrant le plugin Jenkins (mode job et pipleline disponibles), Dependency Check peut être exécuté à chaque fois qu’une build est déclenchée.

Les résultats sont ensuite mis à disposition via un lien sur la page « status » de la build :

L’intégration peut être directement faite dans Sonarqube via un plugin :

Les métriques sont disponibles dans l’onglet « Measures » de chaque projet. Suite aux changements intervenus sur Sonarqube 6.x, le détail des vulnérabilités ne peut pas être consulté directement en cliquant sur les liens proposés mais doit être accédé depuis l’onglet « Issues ».

Les métriques Dependency Check peuvent également être intégrées dans le calcul des « quality gates ».

Ligne de commande

Pour télécharger l’exécutable, rendez-vous ici.

Pour lancer une analyse sur une application java, utilisez la commande suivante :

$ ./bin/dependency-check.sh --project Testing --out . --scan [path to jar files to be scanned]

Le résultat est un fichier HTML. Exemple : dependency-check-report

On retrouve une vue un peu plus détaillée que dans les rapports Jenkins ou Sonarqube avec notamment la notion de « confiance » dans l’analyse d’une dépendance.

Pour déterminer qu’un projet utilise ou non une dépendance dans une version donnée, Dependency Check va analyser certains éléments de l’application (pom.xml, Manifest, nom des jars, etc.) et récolter des preuves (evidence) permettant de dresser une liste des dépendances avec leurs versions.

Le nombre de preuves (Evidence Count) est donc mentionné dans les rapports ainsi qu’un indice de confiance dans l’identification de la dépendance et de sa version.

Conclusion

La mise en place d’un outil comme Dependency Check dans une plateforme d’intégration continue permet d’être alertée sans effort sur la présence de vulnérabilités liées à des dépendances au sein d’un application. N’oubliez pas qu’environ 80% du code de votre application n’a pas été écrit par vous.

Ressources

Retour sur l’AWS Summit Paris du 27 juin 2017

Le 27 juin dernier s’est déroulé l’AWS Summit 2017 d’Amazon à Paris dédié à la présentation des services AWS et aux retours d’expériences de différents clients sur l’utilisation de ces services.

Voici des notes sur quelques-unes des sessions présentées :

#Keynote

Vidéo : https://www.youtube.com/watch?v=Fn5jpD_Utn4

Mise en avant

  • Clients d’AWS mis en avant : Société Générale, Danone, Veolia, Engie
  • 80% des entreprises du CAC40 utiliseraient AWS
  • L’ouverture d’un datacenter en France est toujours prévu pour la fin 2017

Retour d’expérience Radio France

  • Suite aux attentats de Charlie Hebdo, l’infrastructure en place n’a pas supporté le trafic et les services ont été dégradés pendant 3 semaines
  • Suite à ces incidents l’ensemble de l’infrastructure est maintenant sur AWS
  • Chiffres :
    • Base de données : 1,5 millions de pages, 1,4 millions de sons et plus de 10To de données
    • Sur un mois : 170 millions d’écoutes, 1000To d’audio écoutés, 150 millions de visites et plus de 20 millions d’internautes

Produits

Session#1 Casser son application pour construire l’esprit devops de son équipe ?

  • Retour d’expérience fait par Veolia sur l’organisation de « gameday » pour construire un esprit devops
  • Constat initial : « Everything fails all the time »

Organisation d’un gameday

  • Objectifs : Casser certains éléments d’un environnement dédié et voir comme se comportent les équipes
  • Un gameday doit être ludique

Etapes

  • Préparer : création des scenarii, kickoff, cadrage du périmètre, planning
  • Faire
  • Débriefer :
    • Comment améliorer l’architecture, le monitoring, la configuration des services AWS, etc.
    • Un exemple intéressant : Ils se sont rendus compte dans un scenario que toute l’application était hors service, sauf le endpoint monitoré. Aucune alerte n’était remontée.

Exemples de scenarii

  • DROP Table d’une table au hasard
  • Arrêt d’un service AWS
  • Problème de permission sur un bucket S3
  • Charge soudaine sur l’application
  • Crash applicatif

Session#2 Patterns et bonnes pratiques des architectures Big Data en Serverless

3 manières d’utiliser le cloud AWS

  • EC2
    • Création de VM, installation, gestion du scaling, etc. à la charge de l’utilisateur
  • Services managés classique (ex:  Hadoop)
    • L’infrastructure et l’installation sont gérés par Amazon mais l’infrastructure utilisée reste visible de l’utilisateur. Il lui reste des éléments à gérer lui même (scaling par exemple).
  • Serverless (ex: Lambda)
    • L’infrastructure est complètement masquée de l’utilisateur.

 Lambda

  • L’instanciation et l’exécution des fonctions est faite sur base d’événements (ex : ajout d’un objet dans S3)
  • Les fonctions doivent être stateless
  • Les fonctions pouvant être supprimées à tout moment, il faut faire attention au temps d’initialisation engendré par un démarrage à froid (cold start)
  • Il est recommandé de n’utiliser les VPC (réseau virtuel) qu’en cas de nécessité pour éviter les problèmes de performance
  • Si des erreurs se produisent avec Lambda, elles sont remontées dans Cloudwatch
  • Utiliser les step functions pour coordonner les functions Lambda

Big data/Machine learning

  • Démonstration faite par Corexpert sur la reconnaissance faciale avec Amazon Rekognition.
  • Vidéo disponible ici

Session#3 Le continuous delivery au service de la performance

  • Objectif : Ajuster le dimensionnement de l’infrastructure en fonction des événements. Par exemple, la finale de la ligue des champions.
  • Retour d’expérience de la part de BeINSport
  • Chiffres : En 2016, ils ont fait 121 MEP et fait 813 créations de VM
  • A retenir, le déploiement doit être :
    • un non-événement
    • indolore
    • pas consommateur en temps

Session#4 Intégrez votre Amazon Lex Chatbot avec vos services de messagerie

  • Amazon Lex : interface de création de Chatbot pour de multiples plateformes (SMS, Messenger, Slack, etc.)
  • Amazon Polly : Text to Speech
  • Ces 2 services ne sont actuellement disponibles que pour l’anglais

Etapes

1- Traduction de la voix en texte
2- Découpage des mots
3- Reconnaissance de mots clés pour correspondre à un scénario (ex : « hôtel » => scénario de réservation d’hôtel)
4- Reconnaissance de mots clé pour pré-remplir certains paramètres nécessaires au déroulement du scénario (ex : Paris => localisation)
5- Pose des questions pour remplir les autres paramètres attendus (ex : date de départ et d’arrivée)
6- Confirmation
7- Amazon Polly pour Text to Speech et pour répondre