Serveur minecraft

Une suite de devops: la politique en tant que code – Monter un serveur MineCraft

Le 1 novembre 2019 - 43 minutes de lecture

Transcription

Roshgrove: Merci d'être venu au dernier entretien de la journée. Comme je l'ai mentionné, je suis Gareth Roshgrove, @garethr un peu partout sur Internet. Je suis chef de produit chez Docker, responsable de bon nombre de nos outils destinés aux développeurs. Si vous utilisez Docker Desktop sur Mac et Windows, je suis responsable de cela.

Espérons que cette discussion ne sera pas trop méta. C'est en quelque sorte un avertissement que je pourrais être un peu emporté. Je vais commencer par un tas d’histoire. Pas comme l’histoire ancienne, il ya environ 10 ans, parle réellement d’infrastructure, d’infrastructure en tant que code, de DevOps et de quelques-unes des choses que nous pouvons apprendre de ce moment si vous voulez, ce genre de mouvement.

Je fais cela pour mettre en place la partie suivante où je parlerai davantage de la position actuelle de la sécurité (et de toute évidence, c'est la voie de la sécurité, donc je vais essayer de revenir sur le sujet). Vraiment, quels sont les parallèles là-bas? Quelles sont certaines des choses qui sont différentes? Quelles sont certaines des choses qui sont en fait assez similaires et que pouvons-nous apprendre de ce qui s'est passé avec l'explosion autour de DevOps et de l'infrastructure en tant que code?

Je vais aussi vous donner quelques exemples, donc pas tous la théorie, l’histoire et les méta-choses. Je vais donner quelques exemples d’outils qui pourraient nous amener quelque part, peut-être pas quand il s’agit de prendre réellement la sécurité et d’en faire une discipline plus programmatique. Nous examinerons plusieurs outils, nous examinerons certains des avantages et des inconvénients et déterminerons où ils en sont dans ce voyage. Comparez et, fondamentalement, rapportez certains des enseignements tirés de la manière dont d'autres outils ont fonctionné. J'espère que c'est intéressant. Si ce n'est pas le cas, n'hésitez pas à partir maintenant.

Un peu d'histoire

J'ai dit remonter 10 ans ou plus. J'aime cette citation. En fait, je revenais à des entretiens que j'avais tenus il y a longtemps, au cours des années consacrées à Internet, à propos des API et de cette émergence des API comme produit. Du coup, vous pouvez interagir avec des ordinateurs via des interfaces de programmation. Cela a motivé énormément de choses lorsque l’on réfléchit à la question, qu’il s’agisse de l’informatique en nuage ou de l’internet des objets (IoT), l’idée que tout devrait avoir une API. Nous n'utilisons plus le mot «mashup» parce que c'est juste ce que nous faisons tout notre temps maintenant. C'était de retour à ce point. Les API réalisent soudain qu’elles sont importantes. Infrastructure sous forme de code en tant que bannière, une discussion ayant eu lieu à peu près au même moment. Une grande partie de cela appliquait vraiment l'idée de "Pourquoi ne puis-je pas avoir d'API pour mon infrastructure?"

C'est ce qui se passe là où, oui, l'informatique en nuage existe, mais ce n'est certainement pas ce qu'elle est aujourd'hui, ce n'est certainement pas quelque chose que tout le monde utilise. Nous parlons de nos serveurs, de nos commutateurs et de notre matériel physique qui n’a absolument pas d’API ni au moins d’autre équipement spécifié. Tout est différent, tout est axé sur l'utilisateur final.

Une grande partie de l'outillage que nous avons ici concerne l'idée de «donner une API à mon serveur». Maintenant, l'infrastructure en tant que code ne commence pas avec le mot, puis de nombreux outils sont apparus. Les gens construisaient des choses, souvent un peu avant. Mais l'idée qu'il y ait une bannière soudainement, qu'un certain nombre de personnes poursuivent des approches différentes pour des problèmes fondamentalement identiques ou similaires, est toujours, je pense, un bon signe. Etre trop tribal au sujet des outils peut être mauvais. Entrer dans une discipline dans un domaine où différents outils font différentes choses peut être réellement intéressant pour tout le monde, même si vous finissez par utiliser un seul de ces outils.

J'aurais pu avoir plus de logos, mais je ne voulais pas m'emporter, mais CFEngine a certainement été l'un des premiers à inventer des trucs ici. Il y a tout un tas d'histoires là-bas dans lesquelles je ne parlerai pas et sur lesquelles je peux me lancer.

Une grande partie était conduite par ces trois personnes. Si vous en voyez un jour, dites merci. C'est Luke Kanies, Adam Jacob et Matt Burgess. Fondamentalement, créateur de Puppet, créateur de Chef et créateur de CFEngine. Toutes les personnes super intéressantes et il y avait tous des serveurs en cours d'exécution, dans une certaine capacité. Ils étaient des administrateurs frustrés qui ont construit des outils pour résoudre leurs propres problèmes. Je pense qu'il y a un conte là aussi.

De Ad-hoc au logiciel

Pour ceux qui ne sont peut-être pas aussi familiers, peut-être que vous n'avez pas passé du temps de côté des infrastructures, il est facile de sauter à l'endroit où nous en sommes et d'aller, "Bien sûr, c'est comme ça. Bien sûr, c'est un logiciel. " Il s’agissait vraiment de partir d’une approche ponctuelle. Il suffit de vous connecter à des machines individuelles que vous avez gardées de près, sans laisser personne d'autre s'approcher de votre éditeur de texte préféré ou quoi que ce soit qui se trouve sur cette machine, modifier certains fichiers texte puis exécuter un ensemble de commandes et vous rappeler de le faire. les 50 choses dans le bon ordre qu'oui, vous avez notées la dernière fois, mais vous êtes quasiment sûr que ce n'est pas le bon ordre, puis que vous le donnez à quelqu'un d'autre qui ne comprend pas comment vous avez écrit. Ou vous êtes dans un monde d'interfaces graphiques. Sans tenir compte du monde Windows ou de Linux, il s’agissait uniquement d’interfaces graphiques. Il suffit de pointer et de cliquer.

Nous avons transféré cela vers le logiciel. Il s’agissait donc peut-être de Puppet, de Chef, d’Ansible, de CFEngine, d’outils différents, mais d’un autre outil, nous l’avions fait passer d’un monde d’utilisateurs individuels commandes impératives, à décrire ce que nous voulions dans le logiciel. C'est le saut. C'est la chose dont nous parlons comme infrastructure comme code. C'est la bannière sous laquelle de nombreux outils aux approches différentes pourraient résoudre le même problème.

DSL et l'horloge de configuration

Cette variété de solutions différentes, d'outils différents – vous pouvez aller comme, "Oh, pourquoi tout le monde n'est-il pas simplement d'accord?" Ce qui n’a jamais, jamais eu lieu dans l’histoire de l’informatique, mais c’est quand même une bonne question à poser. Qui a déjà vu ce blog ou entendu parler de l'horloge de complexité de configuration? Personne.

C'est probablement l'un de mes blogs préférés sur Internet. Je pense que cela n’est pas seulement pertinent pour la configuration, mais si vous êtes intéressé par de nombreux langages, DSL, pourquoi différents langages de programmation sont parfois la bonne approche ou la mauvaise approche, et pourquoi, si vous programmez suffisamment longtemps, vous avez tendance à tourner en rond à propos de la meilleure solution. À un moment donné, vous êtes absolument convaincu que DSL que vous avez écrit est le moyen optimal pour une équipe de configurer, de construire ou d'écrire un logiciel. À un autre moment de votre carrière, vous dites: "Nous aurions dû tout coder en dur." À un moment donné, vous "avez créé le fichier de configuration parfait dans mon XML, INI, JSON ou YAML, ou quelle que soit l'année choisie, en fonction du format de votre fichier de configuration. Nous pouvons maintenant le faire dans les données et autour du cercle et c’est en fait la raison pour laquelle vous vous retrouvez avec un ensemble d’outils différents, ou l’une des raisons pour lesquelles vous vous retrouvez avec un ensemble d’outils différents. Ce n’est pas uniquement une question de personnes, je dirais, une des caractéristiques qui caractérisent Les conversations autour de l'infrastructure en tant que code consistaient en cette exploration de langages et de configurations spécifiques à un domaine et de ce que vous exposez en tant qu'interface utilisateur à un très grand nombre de personnes, dont certaines sont des experts et d'autres non.

Entrez DevOps

Si l'infrastructure en tant que code concernait dans une certaine mesure les outils, il y avait certes des pratiques, mais il s'agissait d'appliquer des outils à l'administration des systèmes, de la programmation à l'administration des systèmes. Dans le même temps et impliquant pas mal de personnes, mais ce n’est pas un chevauchement complet, est apparu sur cette bannière de DevOps. Et très semblable à l’infrastructure comme code, ce n’est pas que le mot vient d’abord, mais il y avait tout ce qui concernait le fonctionnement du déploiement, comment nous pourrions mieux travailler ensemble dans différents silos d’organisation. Et si tout cela se passait et que nous avions un mot, nous avions une bannière pour tenir ces conversations?

Ce n'est pas une discussion sur ce que DevOps signifie pour moi, mais c'est vraiment ça: c'est une bannière sous laquelle les gens discutent de la pratique. Pas seulement la technologie, pas seulement le code, pas seulement les outils, mais la façon dont ils ont été appliqués dans le contexte où ils ont été appliqués.

Tout le monde aime une définition et c'est de loin, d'une certaine manière, la meilleure distillation de DevOps de John Willis – culture, automatisation, mesure et partage. Appliquez votre réflexion, appliquez votre rigueur, appliquez les problèmes que vous essayez de résoudre sous ces bannières et soulignez ceux qui ont besoin de réponses. Comment partageons-nous? Comment pouvons-nous mesurer? Que mesurons-nous? Comment automatisons-nous? Qu'est-ce qu'on automatise? Cela vous fait en réalité un long chemin sans avoir besoin des manifestes et du reste.

Co-évolution des outils et de la pratique

Ce que vous observez ici est intéressant et ne concerne pas uniquement ce problème spécifique. Il se trouve que j’étais au bon endroit au bon moment pour voir ces deux choses. Vous avez souvent une coévolution des outils et des pratiques. Il n’est pas souvent suffisant d’avoir des outils révolutionnaires et des gens qui vont, "Bien sûr." Et commencez simplement à les utiliser ou échangez-les pour autre chose. Ça ne marche pas vraiment.

Les choses révolutionnaires ont tendance à demander des précisions sur la façon dont vous travaillez, sur la manière dont vous les appliquez. Nous parlons plus généralement d'une livraison et d'un déploiement continus tous les jours, ou d'un déploiement toutes les heures, ou d'un déploiement toutes les minutes, ou d'un déploiement 2 000 fois par jour. Il y a dix ans, c'était comme dans le discours au Velocity [Conference], cinq déploiements par jour. Les gens étaient: "Brûlez-les. Ce sont des hérétiques. De quoi parlent-ils? C'est fou."

Maintenant, je peux dire: "Oui, les gens déploient 2 000 fois par jour." Tout le monde est comme: "Oui, j'en ai entendu parler. J'ai vu quelqu'un le faire." Cela semble un peu poussé, mais nous déployons tous les jours. Nous sommes passés à là. C'est en partie l'un des moteurs de nombreuses discussions sur la nécessité de structurer différemment. Il ne suffit plus que l'équipe des opérations soit à l'autre bout du monde et déconnectée, car notre déploiement nous impose du travail. Nous devons travailler ensemble, sinon tout va être en feu.

En généralisant et en réfléchissant à cela, lorsque vous réfléchissez aux outils, pensez également à ce qui va changer du côté de la pratique. Ce n'est pas un hasard si DevOps et l'infrastructure en tant que code, et plus généralement l'informatique en nuage, sont apparus au même moment. Ils co-évoluent des aspects de la même chose. Je suppose que l'informatique en nuage est en même temps. C'est presque une réalisation de cette promesse gérée par l'API avec laquelle nous avons commencé.

Ordinateurs d'autres personnes

C’est peut-être juste les ordinateurs d’autres personnes, mais c’est vraiment bien que quelqu'un d’autre s’occupe de cela derrière une API. Si vous aimez les outils tels que Chef and Puppet et CFEngine, essayez de fournir quelque chose qui ne dispose pas d'une API que vous pouvez simplement raisonner, gérer et gérer via leur abstraction. Le cloud vient de commencer de cette façon, il ne s'agissait que d'une API. Et nous disons: "Oh, oui, il y a des serveurs." Nous ne savons pas réellement, il pourrait ne pas y en avoir, peut-être y a-t-il de la magie. Peu importe – il y a une API et nous pouvons raisonner à propos de cette API et nous pouvons faire face aux conséquences de son appel.

Pourquoi toutes ces histoires?

C’est bien qu’un groupe d’administrateurs système aient mis au point des outils fous, et c’est bien que les gens aient trouvé des moyens de se déployer tous les jours ou de mieux travailler ensemble. Toutes ces choses sonnent bien, mais pourquoi toutes ces histoires? Pourquoi les gens étaient-ils intéressés? Pourquoi demandez-vous aux DSI de dire: "Nous devons faire le DevOps." La raison en est que parallèlement, les geeks de la technologie ont eu un impact important sur les organisations et les entreprises. Dix ans plus tard, nous n’avons pas seulement un bon sens de l’araignée. Ce ne sont pas que des gens qui vont: "Je suis à Netflix. Nous faisons des choses insensées avec des ordinateurs et nous en parlons lors de conférences." "Oh, c'est intéressant. Je n'y avais pas pensé. Peut-être devrions-nous essayer." Ce n'est pas une preuve.

À ce stade, il y a suffisamment de signaux, il y a assez de données, il y a assez d'études non seulement de la part de personnes comme moi, du côté des éditeurs de logiciels, mais également d'analystes du secteur, de journalistes et d'universitaires. Nous avons eu assez de temps, nous avons assez de données pour indiquer de telles choses dans le rapport sur l'état du DevOps. Tout le monde ne voit peut-être pas ces choses-là, mais même en sachant que c'est possible, que vous pouvez faire ce genre de saut en avant, les gens se lèvent et remarquent. C’est raisonnable d’être "Whoa. Il ya quelque chose ici et nous le faisons." Et nous le savons.

Qu'avons-nous appris?

Quelles sont certaines des choses que nous pouvons retirer de cela et appliquer à notre sujet de sécurité dans ce cas? Je pense que ceux-ci sont généralisables pour d'autres choses aussi.

Une des choses qui se passait avec tous ces outils était que tout le monde n’avait pas besoin d’être un expert. C’est en termes d’expert dans l’utilisation des outils car il s’agit vraisemblablement d’un auditoire de développeurs de logiciels. Vous êtes probablement des experts en programmation et cela peut vouloir dire programmation en général, il peut s'agir de programmation spécifique dans un domaine donné. Il s'avère que les responsables de systèmes, les ingénieurs de systèmes et les administrateurs de systèmes sont souvent assez généralistes, mais également spécialisés. Peut-être sont-ils des experts de ce commutateur ou de cet équipement de réseau ou de ce type de serveur. Tout ce mouvement qui consiste à travailler différemment, les logiciels dévorant le monde, le cloud computing y modifie fondamentalement beaucoup de choses, mais cela ne fait pas disparaître une partie de leur expertise existante. Cela signifie qu'ils ont besoin d'une nouvelle expertise rapidement pour être utiles. Il est difficile de faire évoluer une organisation et tout le monde n'a pas besoin d'être un expert. De nombreux outils y adhèrent en vertu de cet exemple tiré de Ansible Galaxy. C'est un module Ansible qui a été téléchargé 1,5 million de fois. Je ne me souviens pas vraiment de quoi il s'agissait, je pense que c'était pour Python.

L’échelle de la réutilisation en tant que moyen de dire: «Eh bien, oui. Un expert a écrit cela, mais d’autres personnes peuvent l’adopter» est puissant. Et vous voyez beaucoup de choses qui sont là nous allons littéralement avec tout maintenant, et vous pouvez évaluer vos achats. Le côté social de la chose est intéressant.

L'utilité d'un marché

Quelles sont les autres choses qui ont vraiment surgi et dans tous ces outils et qui ont conduit à l'utilité de certains de ces éléments, tels que la possibilité de découverte plutôt que de certains contenus partagés? Où était le marché? Docker Hub est un exemple ou Puppet Forge est un exemple, Chef Supermarket, Ansible Galaxy, le référentiel de modules TerraForm. Toutes ces choses disent: "Faisons la synthèse des choses, rendons-les découvrables". Il y a un utilitaire sur un marché.

Contrôle de version en tant que contrôle des modifications

Une des autres choses qui a été soulevée et qui, je pense, a prouvé que presque tout était secrète, était le contrôle de version, c'est le contrôle des modifications. Le contrôle de source est une chose à laquelle les programmeurs sont habitués depuis longtemps, en tant qu’industrie. Oui, tout le monde ne l’utilise peut-être pas aujourd’hui, mais la majorité l’utilise. Oui, nous avons de mauvais outils aujourd'hui. Oui, certains des outils précédemment utilisés [proved] être terrible – VisualSource Safe. J'ai des cauchemars récurrents sur les fuseaux horaires dans VisualSource Safe dans lesquels je ne vais pas entrer ici.

En fin de compte, je pense que nous voyons cela lorsque nous interagissons avec d'autres types d'actifs. Le pouvoir que nous avons dans les systèmes de contrôle de version est un peu fou. Personne ne connaît tout Git, mais vous en savez assez pour pouvoir faire des choses qui, si vous pensez aux documents Word, vous disent: "Pourquoi ne puis-je pas simplement faire cela? Pourquoi ne puis-je pas avoir le pouvoir de contrôle de version avec des feuilles de calcul et des documents Word? " Vous commencez à voir certaines de ces choses émerger maintenant.

Il s’agit d’un outil puissant et les organisations ont toujours insisté – et c’est toujours une question de réglementation, c’est souvent une question de gestion des risques et une obsession du contrôle des changements. À moins que vous ne puissiez résoudre les problèmes de contrôle des modifications, votre production n’est pas géniale, peu importe ce qui va se passer. Il s'avère que, lorsque nous réalisons que le contrôle de version fournit une base incroyablement puissante sur laquelle construire des systèmes de contrôle du changement, la mise en production de ces éléments s'est avérée beaucoup plus facile que peut-être d'autres technologies.

Outillage partagé

Une des choses qui se sont produites autour de ça, ce n’était pas que les outils eux-mêmes. Ce n'était pas simplement qu'ils étaient des choses autonomes et vous l'avez pris et vous l'avez utilisé. Une communauté a émergé qui a construit des outils pour que le nombre de choses qui améliorent Puppet, le nombre de choses qui améliorent Chef, le nombre de choses qui améliorent Ansible non seulement en termes de contenu, mais également d'outils qui améliorent réellement les outils. Mon exemple préféré sont les tests. En tant que personne ayant développé un logiciel en infrastructure, l’idée d’écrire des tests unitaires pour mon infrastructure me semble logique. Avoir des outils pour le faire est incroyablement puissant et renforce vraiment la raison pour laquelle un logiciel est la bonne approche pour gérer une infrastructure, car vous pouvez le traiter comme un logiciel. Pas seulement un langage de description. C'est du code – je peux le tester, le lier, le style et le support de l'édition.

Les tableaux de bord sont un exemple simple et agréable où nous générons des données et les affichons de différentes manières. Mais la longue queue de différents outils partagés pour différentes personnes, pour différents types de cas d'utilisation, est tout ce qui a réussi est sans égal.

L'importance de la communauté

La base de tout cela était une communauté et si c’était des rencontres locales et souvent, beaucoup de cela a précédé les entreprises qui se sont formées autour de ces outils. Ils étaient presque l'instigateur et le carburant pour cela. Des groupes de personnes sur IRC à ce moment-là, ce qui pour les personnes assez jeunes dans la pièce ressemble à Slack mais se trouve au même endroit. Et ce n’est pas seulement un groupe de personnes, c’est en fait ChefCon, je pense. C'est la communauté de personnes qui construisent des infrastructures. Toutes ces choses font partie intégrante de la raison pour laquelle l'infrastructure en tant que code a réussi là où nous en sommes aujourd'hui.

Parallels avec la sécurité

Prendre du recul sur le côté de la sécurité. Ce n'est pas vrai partout et les gens poussent la balle, mais en général, il y a beaucoup plus de feuilles de calcul de sécurité que d'infrastructure. Il y a dix ans, l'infrastructure contenait beaucoup de feuilles de calcul. Si quelqu'un a déjà eu à faire une mise à jour manuelle de la feuille de calcul avec la CMDB avant de pouvoir faire quoi que ce soit – c'est beaucoup moins courant aujourd'hui. La sécurité – en paraphrasant un peu l'effet comique – fait appel à de nombreux processus manuels. Il y a beaucoup de processus de travail, beaucoup de contrôleurs d'accès et beaucoup de feuilles de calcul.

Cela est en partie dû à un modèle encore très cloisonné dans de nombreuses organisations en matière de sécurité et de surveillance. C'est parfois structuré comme ça. Parfois, il s’agit de financement et, c’est souvent cité, mais a besoin de preuves, d’une organisation qui peut compter 100 développeurs, 10 opérateurs et 1 agent de sécurité, ce ratio. Quelle est la précision? Je ne sais pas, mais cela me semble juste en fonction de mon expérience personnelle.

La sécurité finit souvent par se sentir un peu plus comme un silo, se sentir un peu plus à l'extérieur. Vous pouvez affirmer que c'est en raison de la nature du travail, mais je ne suis pas sûr que ce soit une excuse suffisante pour les avantages que nous avons constatés ailleurs, dans lesquels les gens travaillent réellement ensemble. Et finalement ça se voit.

Il s’agit d’informations tirées du rapport DORA Accelerate State of DevOps, d’une enquête à grande échelle et d’un grand nombre de données permettant de catégoriser les personnes en catégories les moins performantes et les plus performantes. Si vous n'avez pas lu le livre Accélération et que vous ne l'avez pas vu 10 fois sur des diapositives, du moins sur QCon, vous n'êtes probablement pas resté ici toute la journée. Les personnes peu performantes mettent des semaines à effectuer des revues de sécurité et à compléter les modifications identifiées. C'était l'une des conclusions ici. Pour des choses très importantes, les semaines semblent être une longue période.

Un de mes amis, Vincent [Janelle], a déclaré: "La plupart des équipes de sécurité préféreraient que la politique ne soit pas publiée, ou il n’a pas de sens d'ouvrir certaines choses à la source." Cela en arrive au partage, et le partage est l'un des solides fondements de DevOps. Beaucoup de ces caractérisations des outils qui ont réussi, partager fondamentalement et habiliter et en tirer profit. Là où les choses sont gardées secrètes et sensibles, – oui, il y a des secrets et des choses sensibles mais en réalité – où il y a juste une résistance au partage en général, alors bien , vous avez tendance à ne pas voir le partage et vous n’avez pas l’impact positif, les effets qui en découlent. Nous voyons de plus en plus de gens parler de sécurité, nous voyons la communauté de la sécurité sortir un peu de sa bulle, mais c’est C’était vrai – c’est vrai, je pense que c’est le problème ici – il en était de même pour la communauté des administrateurs système il ya 10 ans. Je pense que c’est différent aujourd’hui.

J'ai dit qu'il y a des gens qui réussissent. Nous commençons à voir les premiers succès de personnes qui ont changé leur façon de faire la sécurité pour le meilleur. L'une de ces idées, qui était vraie dans l'infrastructure, était l'importance de penser dans les pipelines, et cela se passait auparavant dans le logiciel lui-même. Vous avez testé des choses et exécuté des commandes et vous avez dit: "Oui, ça a l'air bien." Ensuite, vous l'avez déployé manuellement en production. C'est comme ça que les logiciels ont été déployés. Aujourd'hui, les gens seraient: "Oh, non. J'ai un pipeline, nous le testons là-bas, nous le déployons là-bas." Nous avons également cet aspect, l’aspect flux de travail dans les logiciels. La même chose s’est produite avec l’infrastructure où il s’agissait de commandes ad hoc. Maintenant, c’était un logiciel auquel je pouvais appliquer des modèles d’intégration continue, je pouvais appliquer des modèles de livraison continue, car c’était un logiciel.

Ceci provient du prochain sondage de la communauté DevSecOps. Ceci est sorti aujourd'hui. Ce rapport est vraiment bon, plein de détails. Merci aux gens de Sonatype de m'avoir donné un aperçu. La seule façon de réellement assurer la sécurité des logiciels consiste à mettre en place des contrôles de sécurité automatisés. La seule façon de le faire est d’avoir ces contrôles dans les logiciels.

Il y a une foule de bonnes données ici sur les organisations qui ont des pratiques DevOps matures par rapport à aucune. N'oubliez pas que nous disposons de bonnes données. Par exemple, si vous êtes un praticien DevOps mature, vous bénéficierez également probablement d'avantages organisationnels. Mais ce grand fossé entre les "nantis" et les "nantis", si vous voulez, en ce qui concerne les personnes qui utilisent des outils pour vraiment respecter la sécurité, constitue le fossé entre les feuilles de calcul – car je ne considère pas les feuilles de calcul comme des outils. J'aime les feuilles de calcul, mais ce sont parfois les mauvais outils.

Il y a une foule d'autres éléments, je pourrais remplir un tableau avec les graphiques de ce rapport. Les pratiques DevOps matures, qui sont alignées sur le bon fonctionnement de votre organisation, rappelez-vous, sont beaucoup plus susceptibles d'intégrer la sécurité automatisée tout au long du processus.

L'automatisation de la sécurité n'est pas nouvelle

Une chose que je veux éviter, et je glisse donc une diapositive plus précisément, c'est que je ne dis pas que l'automatisation de la sécurité n'existe pas, que les gens ne le font pas déjà ou qu'il s'agit uniquement de tests manuels au stylo. et il n'y a pas d'outils. Il existe une multitude de bons outils, ce qui est vrai depuis longtemps et des fournisseurs se trouvent déjà dans le secteur. C'était vrai dans l'infrastructure. L'infrastructure en tant que code était une bannière autour d'un ensemble d'outils qui adoptaient une certaine approche, et certains d'entre eux avaient 10 ans à ce moment-là. Il y avait beaucoup d'outils dans le domaine de la gestion d'infrastructure et Bash est assez incroyable quand on y pense. L’approche globale avait atteint un maximum local. Je pense que l'automatisation de la sécurité jusqu'à un certain point, telle que nous la voyons aujourd'hui, est similaire.

«Les performances d’élite renforcent la sécurité et peuvent effectuer des analyses de sécurité et apporter des modifications complètes en quelques jours.» C’est l’autre moitié de la citation précédemment. Il est possible d'être bien meilleur que nous, dans la plupart des cas. Nous avons vu cela dans l'infrastructure, avec DevOps, nous commençons à voir cela dans la sécurité, mais «comment pouvons-nous y arriver à grande échelle?» Est la prochaine question. La question que j'aimerais voir les gens demander et répondre plus.

Sécurité en tant que gestion de politique

Pour moi, une partie de cela consiste à prendre un objectif singulier. Cela ne veut pas dire que toute la sécurité est cela, mais je pense que c'est un objectif utile pour le voir à travers. L’ensemble de l’infrastructure en exploitation n’est pas réellement une gestion de la configuration et des serveurs, mais l’une des conséquences de ce mouvement est la suivante: «Si j’automatise beaucoup de tâches fastidieuses, j’ai le temps de réfléchir à des problèmes de niveau supérieur». temps et l’espace sont venus beaucoup des pratiques les plus modernes. Comment pouvons-nous obtenir du temps et de l'espace dans la sécurité pour que les gens trouvent ces pratiques? Nous devons nous débarrasser du travail fastidieux. Je dirais que beaucoup de travail fastidieux se fait par ses contrôles, sa gestion des politiques.

Politique en tant que code

Comment pouvons-nous arriver à la politique en tant que code? Comment pouvons-nous en arriver au point où nous pouvons assumer tout ce travail fastidieux, nous pouvons prendre ces contrôles, nous pouvons les encoder dans un logiciel et nous pouvons leur appliquer le génie logiciel, comme nous l'avons fait pour l'infrastructure? Prenez le temps d'innover sur les pratiques.

ModSecurity: pare-feu d'applications Web

C'est la configuration. Je vais creuser quelques outils qui ont des propriétés intéressantes. Qui a utilisé ModSecurity ARG auparavant? ModSecurity est un pare-feu pour applications Web qui permet de filtrer les attaques. Les gens tentent de lancer une attaque par injection SQL sur vous ou tentent d'accéder à vos pages d'administration WordPress.

ModSecurity existe depuis longtemps, ce n'est pas un nouveau projet, loin de là. ModSecurity 3.0 est la nouvelle hotness. Il vous permet d'écrire des règles qui protègent vos applications, il dispose d'un DSL pour le faire. Ce DSL ressemble un peu à ça. Vous voyez beaucoup de SecRule et, heureusement pour tout le monde dans la salle, je ne vais pas revenir sur ce que c'est, en partie parce que personne ne peut réellement s'en souvenir. La date et la légèreté du ModSecurity DSL sont un facteur limitant, je dirais que c'est un obstacle très important pour quiconque écrit de nouvelles règles.

La réalité que j’ai trouvée est que les gens n’aiment pas les règles ModSecurity. C'est possible, totalement. Vous les copiez et les collez à partir d'Internet ou vous utilisez une distribution. Certaines personnes peuvent écrire ces règles. Il existe d'autres groupes, il existe d'autres distributions de règles, dont la plus connue est probablement le noyau OWASP. Ensemble de règles. OWASP a une vaste charge de projets de sécurité – organisation très intéressante. Et ils ont un ensemble de règles ModSecurity que vous pouvez simplement télécharger, utiliser et protéger vos applications – pour revenir à ce concept de partage. C'est puissant.

Il existe également d’autres outils dans l’écosystème ModSecurity, dont certains sont relativement nouveaux. ModSecurity existe depuis longtemps dans un certain espace qui est au-dessous de la limite pour beaucoup de gens, mais c'est là. Ceci est un framework pour tester les pare-feu d'applications Web en général, mais cela vous permet d'écrire des tests sur vos règles ModSecurity. Les tests finissent par être beaucoup plus lisibles que la configuration ModSecurity, heureusement, mais il s’agit d’un projet relativement récent de Fastly et de quelques autres personnes du secteur. Il y a des outils écosystémiques, il n'y en a pas beaucoup, je dois dire.

Il y a quelques choses qui nous reviennent, comme la politique en tant que code. Comment avons-nous des outils populaires qui accélèrent? Je ne suis pas ici pour recommander ModSecurity comme solution, en partie parce qu'il n'est pas manifestement déplacé comme suit. Et je pense que certaines des raisons sont liées à «Pourquoi certaines règles d'infrastructure ont-elles réussi?» Franchement, écrire des règles ModSecurity est un exercice de folie, à moins que vous ne soyez un pirate Perl regex. Alors ce n’est pas pour vous, mais plutôt fastidieux, quelle que soit votre opinion sur différents DSL ou différentes méthodes de configuration, dirais-je. Opinion personnelle, etc.

Il y a du contenu partagé et une utilisation généralisée. Je dirais que ModSecurity est en fait un outil utile dans et de son droit. Il ne possède pas les propriétés qui m'intéressent et qui, je pense, ont joué un rôle déterminant dans l'explosion de l'utilisation des outils d'infrastructure.

C'est lié à des technologies qui sont peut-être plus dans le temps et oui, il y a beaucoup d'Apache. Oui, ModSecurity 3 devient de plus en plus facile à utiliser dans le contexte de NGINX, mais beaucoup de gens passent à l’autre, à l’autre, et au suivant. Cela n'a rien à dire sur l'orchestration du conteneur, sur le maillage de service ou sur les conversations qui se déroulent autour des serveurs. Donc, quelle que soit la raison pour laquelle nous allons passer, même si nous savons que le fait d’avoir cela en place pour le moment, c’est une bonne chose.

Il y a un tas d'autres outils plus spécifiques au domaine dans lesquels je n'entrerai pas, mais ModSecurity était là, il est tôt. L'idée de coder votre politique en code est une bonne idée, mais elle ne possédait peut-être pas les propriétés d'une réponse plus générale et largement applicable au type de choses dont je parle. Les gens l'utilisent contre le fait d'être génératif.

InSpec: Compliance as Code

InSpec est un outil plus moderne et plus récent. Est-ce que quelqu'un dans la pièce a utilisé InSpec? InSpec est un outil destiné aux environnements de conformité. C’est en fait Ruby, donc, selon votre opinion sur Ruby, cela vous plaira ou non, mais vous disposez d’un langage de programmation complet. C'est une façon d'écrire les contrôles dans la structure de test RSpec. Nous écrivons ici une règle spécifique: "Ce fichier doit correspondre à son masque." Nous rédigeons des déclarations de fait auxquelles nous souhaitons que notre système adhère.

Cela a certaines des propriétés dont nous parlions. Cela a été étendu et peut être étendu par n’importe qui pour ajouter de nouveaux types de choses dont le framework est conscient. Il y a tout un ensemble de ressources. Le pack de ressources appelé ainsi pour les ressources AWS. Mon kit de règles n'a pas besoin uniquement de bits, de paquets, de fichiers, de ma configuration SSH, de mes règles de pare-feu et de mes règles de réseau. Cela peut concerner mes instances de cloud et la manière dont elles sont réellement configurées et configurées au niveau de l'API. En fin de compte, il y a une API quelque part et j'ai beaucoup de ressources et je veux définir des règles à leur sujet. Je pense que c'est un bon modèle, mais InSpec peut également être étendu.

InSpec fait partie de cette suite d'outils de Chef. Le chef a le supermarché et son supermarché est comme Docker Hub ou Puppet Forge. Il s'agit essentiellement d'un référentiel partagé de code provenant à la fois de Chef eux-mêmes, de tiers et d'autres fournisseurs. InSpec a un support intégré pour cela – vous pouvez voir des profils tiers. Les gens partagent leurs profils, ils partagent leurs politiques. C'est ce que nous voulons atteindre.

Juste en train de prendre la route, vous pouvez voir qu'il y a des choses comme les repères de la CEI et tout un tas d'autres choses là-dedans. Une partie de cela est motivée par une communauté que les responsables de DevOps et de la sécurité de DevSec sont vraiment allés en ville pour transformer bon nombre des bonnes idées et des meilleures pratiques en logiciels à exécuter. Plutôt que de publier un livre blanc, dites: "Hé, voici comment configurer votre serveur." ils ont construit des profils InSpec. Ils ont créé le code Puppet et Chef que vous pouvez simplement utiliser et prendre pour sécuriser vos serveurs. Est-ce que cela va correspondre à 100% de ce que votre politique interne est? Est-ce que ce sera probablement un bon point de départ pour les personnes qui n’ont même pas eu le temps de discuter de ce que cela devrait être? Absolument. C'est également un excellent exemple de la manière d'ancrer la politique. Even if you don't use it directly, from a learning perspective, seeing a real code basing, a real implementation is useful. We're starting to see some of the things that we saw on the infrastructure side.

And that makes it easy to use without expertise. I talked about not everyone having to be an expert, and as software developers you're unlikely to become an expert in handling learning machines or a specific compliance regime. You might do, you might choose to do. You might be, "That sounds terrible." Being able to give you code that says, "Well, actually you don't need to be the expert. The code is the expert. Apply this." gives you superpowers. InSpec support is actually just running directly from the third party and this runs a whole bunch of checks. It runs a 100 plus checks, from one command. I install one tool and one command and bang, I've just gone, "Oh, that's a bit of a thing! There's a lot of problems that I didn't know about." Now I can go whack-a-mole. Now I can go fix individual things because it's telling me what's wrong.

InSpec has lots of things to like. There's maybe an argument that Ruby was a moment in time. Ruby's still really popular, but it's maybe not the language that everyone is heading towards at this point. I really like Ruby, but on the other hand language communities are fickle and fashion conscious, and there are more people using other things new now. There's loads of high quality shared content. The Supermarket acting as a central repository works really well. I would argue that you need a certain level of expertise to get involved here. There aren't tools for non-programmers, and I think the barrier to entry there, for people coming from the security side, is a lot higher than it will be for people who are probably coming to QCon and interested, from the software development side. InSpec's an interesting tool. I'd love to see it succeed, I think there's maybe some barriers in its way.

Open Policy Agent

Last but not least, I want us to talk about Open Policy Agent. Who in the room's come across Open Policy Agent before? This is mainly popular at the moment in the Kubernetes community. I'd argue it's more generally applicable than that. Open Policy Agent allows you to express policies in a high level declarative language that promotes safe, fine grained logic. Ultimately it's a DSL for describing policy about structured data.

We can write rules in Rego which is basically the DSL for these uses. It's a separate language that has pros and cons, back to that idea of the configuration complexity clock. I was going to do some demos and had to swap my laptop at the last minute, but this is a simple policy for TerraForm code. TerraForm can be compiled down to if I say JSON or YAML or whatever it might be and we can apply this policy. This policy is going to count all of the resources, it's going to iterate over the resources. It's going to grab all of those that start with AWS IAM – basically they're IAM rules – and it's going to say, "Deny." If you're trying to change any IAM rules it's going to go, "No."

You can imagine the other types of things you can do over any type of structured data. A common example in the Kubernetes community would be blocking images from other repositories. You only want images coming from your internal repository, rather than random place on the internet or untrusted source. That's easy to encode in a policy in Rego and applying it with OPA.

You might be writing tests for home chart. I think that's a really good use case. I hear this is actually a nice, simple example and all we're saying is, "Well, it's [inaudible 00:44:03] type deployment and it's not got the security contacts run as root set to true."

We've set up a nice policy and there's a Helm plugin that allows you to run those policies against your Helm chart deployments. Helm is a package manager for Kubernetes. All these things are just structured data and OPA is a way of writing policies against structured data, and it's got a testing framework built in. You can apply it just simply on the command line. You can run it as a daemon to act as a live filtering proxy for off the connections. It's a really powerful tool set.

It's pretty new, which is one of the reasons why I wanted to talk about it. You could do a whole talk on Open Policy Agent. I think you'll probably start seeing those types of things at conferences, hopefully. Modern sensibilities, I think, are a good sign. I'm a fan of the DSL approach, not everyone will be but that's fine. I like a good DSL.

Built-in tools for testing and it's widely applicable to different problems. I have, a bunch of times, written proxies to put in the middle of places to say, "Look. I want to filter out certain things. I only want things to go through here that meet a certain schema" for example. Open Policy Agent is a generic framework for doing that type of thing. Any time you're passing structured data around and you want to apply policy, OPA is a good way of doing it.

It's new, which isn't a good [inaudible 00:45:40] sign but there are limited examples outside the use of Kubernetes. There are examples, but not real cases where I've seen it applied. There's no built-in sharing or central repository yet. I keep bugging folks and maybe it'll happen one day but the sharing story isn't there yet, it's new. I like OPA and I'd like to see it succeed so please have a look at those.

Conclusions

Rounding up. I think, with security tooling, we're in this point where we're definitely not across the chasm yet. Ultimately, not everyone adopts all the same software at the same time. You do end up with most people adopting certain things that become popular enough that they hit the general audience, but lots of things don't get across this maybe imagined gap. We're definitely in an early market situation here, nothing's really breaking out, nothing's really over that line. I think that says a lot about lots of things, not just about the individual tools. It's about security and structures and how we incentivize people to work together, and a lot of the things that we're seeing being broken down by the DevOps conversation.

I don't think we're across there yet. A good example of that is this is public content on GitHub. It's not a perfect proxy, partly down to that idea of “security people might not want to share”. I can tell you sysadmins really did not want to share, and some of them still don't. I don't think that's the argument for the discrepancy here, but you see this one and a half million probably manifests public on GitHub – that's a lot. I've done some data mining on that sample, it's good fun.

More than a million DOC files, hundreds of thousands of composed files, tens of thousands of Helm charts – that's not indicative of anything. Those numbers are not comparative, but those are large numbers for the types of things they're trying to describe. Actually, all the things I just talked about you don't see that much public content. That means it's not super visible, it means it's not easy to learn from it, it means it's not easy to share.

I do think this is a powerful idea. Unfortunately, if you came along expecting, "And here's how to do everything today." I don't think we're there yet. I don't think we have the tools. You can do this, you're going to write it yourself. However, I think we can get to the place where we do have tools, we do have a general approach.

If you are building tools, then build for a community. First and foremost, make it possible for people to get involved. That's the only way you break out, and that's true inside your organization as well as, if you're trying to build for a wider audience.

Adam [Jacob] is up on the sustainable, free and open source community. There's loads of good guidance about that.

If you're using it, build what you're doing for sharing. Try and share by default, rather than get permission after the fact when it's become powerful and a big thing. And it might not be the actual policy, it might be how you did something. It might be getting up and talking at QCon, it might be blog posts. It might be whatever it might be.

Put it in your context, in your organization and it's easy when you look and go, "Wow. These people are in charge of this big open source project." Actually a lot of them just started like you, inside an organization fixing their own problem, and the approach they took became the thing that you see in hindsight.

See more presentations with transcripts

Commentaires

Laisser un commentaire

Votre commentaire sera révisé par les administrateurs si besoin.