Aujourd'hui, les conteneurs ne surprendront personne. Vous serez surpris de la question de la sécurité des conteneurs. Il est particulièrement intéressant de poser des questions sérieuses à des collègues qui utilisent des conteneurs et des microservices dans la production: souvent je vois des visages surpris et une question perplexe, ils disent: "Quoi, pourquoi est-ce"? Il s'avère que nous connaissons déjà la technologie (et comment pouvons-nous ne pas savoir: il semble que même les écoliers seront bientôt en mesure de construire un cluster Kubernetes en tant que classe dans les cours de technologie), mais ils n'ont pas encore appris comment protéger ses composants. Peut-être qu'il n'y avait simplement personne à enseigner.
Dans cet article et sur
DevOops , nous aurons des conférenciers qui ont mangé un chien sur le thème des solutions de sécurité adaptées aux conteneurs. Nous nous adressons à eux pour obtenir des réponses aux questions les plus simples sur la sécurité du cloud. Il faut commencer l'auto-éducation avec quelque chose?
Les participants:
Seth Vargo dirige le Developer Advocate chez Google. Il a précédemment travaillé chez HashiCorp, Chef Software, CustomInk et plusieurs autres startups à Pittsburgh. Il est l'auteur de Learning Chef et milite pour la réduction des inégalités technologiques.
Liz Rice est évangéliste technique chez Aqua Security, une solution d'entreprise de sécurité et de déploiement d'applications basées sur le cloud. Liz est une personne très célèbre dans la communauté, la présidente de KubeCon-s .
Oleg Chirukhin, éditeurs du groupe JUG.ru
Commençons par une question qui déterminera notre discussion future. Que signifie DevOps pour vous? En quoi diffère-t-il du SRE moins connu?
Par exemple, lors d'un travail précédent, quand on m'a demandé «d'implémenter DevOps», j'ai simplement parcouru la table des matières du livre SRE , saisi des idées et les ai appliquées une par une. Eh bien, ou du moins j'ai essayé de les transmettre aux autres. Que dites-vous - est-ce la bonne approche?
Si nous parlons de DevOps, nous parlons d'éviter l'abîme, de l'écart qui était habituellement entre les processus de développement de code (Dev) et sa maintenance ultérieure (Ops). Imaginez que nous avons un mur haut, d'un côté duquel les développeurs sont assis, il crée un code, le jette par-dessus le mur. De l'autre côté du mur se trouvent des personnes engagées dans le soutien. Ils interceptent l'application transférée et commencent à lancer et à maintenir. Et ces personnes connaissent les détails nécessaires pendant l'opération. Par exemple, quels ports et où seront alloués et ouverts.
Au lieu d'avoir deux groupes distincts de personnes ayant des intérêts différents, je veux les faire communiquer les uns avec les autres, décider quoi faire ensuite, déterminer ensemble les objectifs qu'ils essaieront d'atteindre ensemble pendant la journée de travail. DevOps est donc un changement dans la culture de la communication qui aide les collègues de différentes équipes techniques à travailler pour le bien commun: créer de la valeur pour l'entreprise, déployer des logiciels et les faire fonctionner. Je pense que ce sont des changements très importants, et ils apportent avec eux de nouveaux outils connexes: si vous n'avez pas de culture de communication, alors il n'y a pas grand intérêt à introduire les mêmes processus CI / CD.
Il y a souvent confusion avec les concepts de DevOps et SRE. Certaines personnes pensent que SRE est en concurrence avec DevOps, d'autres les considèrent comme des concepts complètement différents et se chevauchant. À mon avis, ce ne sont pas des concurrents, mais des amis proches. Pensez aux approches qui sous-tendent DevOps - réduire les coûts organisationnels, traiter les défaillances comme une partie normale du flux de travail, introduire progressivement des changements, automatiser et implémenter les outils nécessaires à cela, et utiliser des métriques pour évaluer les processus. Comme vous pouvez le voir, tout cela est très abstrait: DevOps ne nous dit pas comment réduire les coûts organisationnels ou introduire des changements progressifs, il vous dit simplement que ce serait bien s'ils étaient mis en œuvre.
Voyons maintenant SRE. Bien que l'approche SRE ait évolué indépendamment de l'approche DevOps, SRE est, pourrait-on dire, une implémentation des principes DevOps: si vous imaginez DevOps comme une classe abstraite ou une interface en programmation, SRE sera une classe concrète qui implémente cette interface. SRE a clairement défini des approches pour une multitude de choses et de concepts: la copropriété, le partage des risques, l'autopsie, la collecte et l'accumulation de valeurs métriques et bien plus encore. Par conséquent, il est plus pratique pour les organisations de parler de l'adoption du SRE en raison de la présence de processus et d'entités très compréhensibles.
Pensez-vous que le terme «ingénieur DevOps» est correct? Peut-il être remplacé d'une manière ou d'une autre?
Personnellement, je ne crois pas que le concept "d'ingénieur DevOps" existe. Vous pouvez lire plus en détail dans mon article «10 mythes de DevOps» que «DevOps» est en fait une idéologie: plus de communication et de coopération entre différentes unités organisationnelles, mais essentiellement connectées. Même si elle semble aujourd'hui assez robuste et familière, une telle approche a d'abord suscité à la fois des éloges et des critiques sévères. Depuis lors, de nombreuses organisations, dont Etsy, Facebook et Flick, ont étonnamment réussi à mettre en œuvre les principes de DevOps.
Ainsi, aucune de ces organisations n'a embauché des «ingénieurs DevOps». Le succès de la mise en œuvre peut être attribué à la coopération interne émergente des équipes et à la volonté de modifier leurs processus et procédures existants afin d'atteindre un objectif commun. Le rôle du soi-disant «ingénieur DevOps» était d'encourager la collaboration entre les groupes et de veiller à ce que les unités organisationnelles échangent régulièrement des idées et des objectifs. En fait, nous avons déjà ces gens aujourd'hui, et nous les appelons des «gestionnaires».
J'ajouterai encore un instant. Lorsque nous nommons quelqu'un à un poste ou à un rôle spécifique, nous commençons à nous attendre à des choses et des actions bien spécifiques de lui, il est donc important de choisir un titre de poste. Mais les noms exacts des postes peuvent différer en raison des réalités et traditions locales adoptées par l'organisation, il est donc important non pas le nom en tant que tel, mais plutôt l'équilibre entre les postes de toutes les personnes qui travaillent dans l'entreprise.
Il n'y a pas si longtemps, j'ai parlé à une personne qui travaillait dans une organisation assez grande, et ils ont donc créé une équipe de plusieurs employés et l'ont appelée, disons, une équipe d'infrastructure. Ensuite, cette équipe a été renommée en quelque chose d'autre, et après un certain temps une autre équipe a été créée, et maintenant elle s'appelait l'équipe d'infrastructure - en conséquence, tout le monde n'était que confus: qui sont les «spécialistes de l'infrastructure» et quel est leur rôle.
À mon avis, le plus important n'est pas l'existence d'une équipe ou d'un poste avec un nom spécifique, mais la présence au sein de l'organisation d'une compréhension claire de qui est responsable de quoi. Peu importe qu'ils les appellent SRE ou DevOps: l'essentiel est de comprendre ce que signifie un nom spécifique pour cette organisation particulière.
Liz, vous êtes consultant, comment expliquez-vous les principes DevOps aux entreprises clientes? Ils semblent assez abstraits et quelque peu difficiles à expliquer. Ou peut-être avez-vous développé une sorte d'approche qui vous permet de transmettre ces idées aux clients?
Cela dépend du but. De nombreuses personnes et entreprises avec lesquelles je communique dans le cadre des consultations viennent nous voir et disent vouloir déployer Kubernetes et des conteneurs. Mais avant de parler de technologie, vous devez comprendre pourquoi ils essaient de prendre de telles mesures. Et il s'avère que les avantages attendus du changement se résument souvent au désir d'être plus flexible. D'où le mouvement dans le sens où les équipes techniques pourraient publier plus rapidement les résultats de leur travail, quelque chose comme ça, expliquait «sur les doigts». À ce stade, il est utile de déplacer la conversation du côté que le problème du manque de culture (habitudes, si vous voulez) de communication entre les membres de l'équipe ne sera pas aidé par un «lancement» de nouvelles technologies, que la communication est une ressource importante.
De plus, comme je me retrouve souvent impliqué dans l'amélioration de la sécurité des solutions, notre conversation s'oriente vers «Dev - ** Sec ** - Ops», et il s'avère que le système doit être construit pour que la sécurité soit prise en charge par les plus dans les premiers stades des processus, et pas seulement abordé la question à l'ancienne: nous écrivons d'abord le code de l'application, puis nous le déployons, puis nous le transmettons au service de maintenance, et ce n'est qu'à la toute fin que quelqu'un commence à penser à la sécurité de celui en cours d'exécution.
En fait, de nombreux problèmes de sécurité sont moins chers et plus faciles à résoudre au début du processus, mais vous devez poser beaucoup de points dans le projet dès le début. Par exemple, si vous avez l'intention de travailler avec des conteneurs, vous devez vous inquiéter que les images soient collectées de manière assez sûre. Il peut être utile de les analyser pour détecter les vulnérabilités afin d'éviter au moins le déploiement de logiciels avec des problèmes de sécurité déjà connus. Vous allez peut-être essayer de configurer les conteneurs pour que le logiciel qu'ils contiennent ne démarre pas par défaut par root (comme souvent pour des raisons de simplicité, sans besoin particulier, ils sont effectués lors de l'assemblage des conteneurs). Si vous suivez ces étapes, vous obtiendrez au final une augmentation de la sécurité de votre application, et vous pourrez, dans le cadre de tous ces DevOps, parler de la culture SecOps.
Cependant, cela signifie que les développeurs, en fait n'étant pas des experts en sécurité des applications, sont obligés de penser non seulement au code de l'application, mais aussi de créer leurs propres systèmes de sécurité. À votre avis, quel devrait donc être l'ensemble minimal de compétences pour un développeur de logiciels ou un ingénieur d'exploitation moderne?
Vous et moi, que cela nous plaise ou non, nous voyons constamment l'émergence de nouvelles règles et exigences qu'il s'avère à un moment donné nécessaire de remplir et de respecter: prenons par exemple le même RGPD. L'émergence et l'existence de ces réglementations signifient qu'un nombre croissant de personnes doivent avoir un sentiment de sécurité. Par exemple, aujourd'hui, vous ne pouvez plus stocker les noms d'utilisateur et les mots de passe sous forme de texte brut dans les champs de la base de données - cela n'est plus considéré comme au moins tolérable. Je dirais que dans l'industrie, il y a déjà des exigences très claires pour tout le monde en matière "d'hygiène".
Les fabricants d'outils et d'infrastructures eux-mêmes ont un impact significatif sur ce processus, en essayant de concevoir et de modifier des systèmes afin que les utilisateurs puissent créer des applications et des systèmes plus sécurisés dès le début. Par exemple, dans Kubernetes au cours de la dernière année, de nombreux réglages par défaut et valeurs de paramètres ont changé vers une plus grande sécurité, et c'est vraiment très cool. Auparavant, par défaut, le serveur d'API était ouvert pour un accès anonyme - ce n'est pas tout à fait ce que vous attendez de voir «prêt à l'emploi». Maintenant, des choses comme le contrôle d'accès basé sur les rôles sont apparues, nous avons donc des autorisations (oui, «prêt à l'emploi»), et lorsque vous démarrez Kubernetes pour la première fois, vous n'êtes pas ouvert au monde entier, vous êtes protégé par défaut. Je pense que c'est un bon moyen de rendre la sécurité accessible à tous au cours de processus familiers, car nous n'avons pas à changer constamment les valeurs par défaut en valeurs sûres (qui, en outre, devaient être gardées à l'esprit).
Personnellement, je crois que chaque ingénieur logiciel doit avoir au moins une compréhension de base de la sécurité. Des choses comme les approches OWASP (Open Web Application Security Project) viennent à la rescousse, mais en fin de compte, les ingénieurs doivent être autodidactes. Il est peu probable que chaque ingénieur ait un doctorat en cryptographie, mais si nous voulons que nos collègues prennent la sécurité au sérieux, nous devrions leur faciliter la prise de bonnes décisions. C'est là que des outils tels que Vault peuvent aider - et les équipes de sécurité et les professionnels peuvent prendre des décisions et fournir la «sécurité en tant qu'API».
Si je comprends bien, il y a une tendance à tout transformer en code. Tout comme code. Infrastructure comme code, processus comme code, code comme code. Quelles en sont les implications?
Avant de parler des conséquences, nous devons parler des avantages. Le code existe depuis très longtemps. Les applications ont toujours été «codées», et pendant ce temps, un vaste écosystème d'outils et de processus a été créé pour soutenir et améliorer le processus de développement d'applications (CI / CD, linting, outils pour le développement conjoint, etc.). Après avoir décrit l'infrastructure comme du code, les processus comme du code, la sécurité comme du code, nous pouvons utiliser le même écosystème, sans rien payer de plus pour cela. Vous pouvez développer conjointement des changements d'infrastructure, faire des revues de politique, etc. Vous pouvez tester les modifications d'infrastructure avant de les déployer. Ce ne sont là que quelques-uns des avantages de la traduction de quelque chose en code.
Je pense que les plus grandes conséquences sont le temps et la complexité. Lorsque vous travaillez avec quelque chose «comme avec du code» (par exemple, via Terraform, Vault, CloudFormation, Deployment Manager, etc.), vous devez parfois rencontrer des écarts entre ce qui est écrit dans le code et ce qui se passe réellement. dans le cloud. La modélisation de relations complexes est parfois difficile à réaliser visuellement, surtout compte tenu de la mise à l'échelle. En outre, nous pouvons rencontrer une inexactitude des abstractions - par exemple, un script fonctionnant via l'API peut ne pas percevoir l'état actuel des choses tel qu'il est affiché aux utilisateurs via l'interface Web. Cependant, avec le temps, la complexité diminue et la flexibilité revient.
Le code et d'autres modèles formels sont un domaine approprié pour l'analyse et l'apprentissage machine. Quand exactement les robots nous remplaceront-ils? Comment devons-nous réagir?
Les robots peuvent-ils configurer Kubernetes sans humains? En particulier, il peut arriver que certaines professions (comme un administrateur système ou un testeur de logiciels avec un haut niveau d'interactivité - un mot socialement acceptable pour un «testeur manuel») disparaissent tout simplement?
Je ne pense pas que les gens vont disparaître, mais je soupçonne que certains des emplois que nous avons aujourd'hui ne seront pas sauvés à l'avenir. J'habite à Pittsburgh, la capitale mondiale des systèmes de contrôle des voitures autonomes, et je vois des voitures autonomes littéralement tous les jours. À l'avenir, bien sûr, les chauffeurs de taxi seront remplacés par des technologies de conduite robotisées. Peut-être pas immédiatement, mais après 10 ans ou plus, mais cet avenir viendra inévitablement. Cependant, je pense que les chauffeurs de taxi ne disparaîtront pas. L'humanité se réinvente constamment.
Je pense que l'on peut en dire autant de l'apprentissage automatique dans le domaine de la gestion. J'attends avec impatience davantage d'intelligence artificielle pour rendre nos systèmes plus stables et plus résistants, et je pense que nous pouvons décider de lutter contre cette approche - ou de l'accepter. Le rôle des administrateurs système traditionnels peut être remplacé par quelqu'un qui contrôle le système d'IA, mais cela ne signifie pas que les gens eux-mêmes disparaîtront. Nous avons connu les mêmes changements dans plusieurs industries où la technologie et l'innovation ont fourni une vitesse et une précision plus élevées que les gens, mais au final, quelqu'un doit suivre les robots :).
Imaginez qu'une équipe de développement régulière crée une application Web, la place dans un cluster Kubernetes. Comment pouvons-nous nous assurer que l'application est sécurisée? Embaucher un pirate Blackhat ou un spécialiste qui essaie de trouver des failles de sécurité, ou existe-t-il des moyens moins compliqués?
Chez Aqua Security, nous avons récemment publié un outil open source appelé kube-hunter . Il est capable de tester Kubernetes pour le piratage ou la pénétration - ce qui en fait un test assez simple. Vous pouvez utiliser cet outil et tester votre propre cluster, et vous découvrirez presque certainement quelque chose d'intéressant pour vous, surtout si votre installation était basée sur l'ancienne version de Kubernetes, où les paramètres par défaut étaient moins sécurisés - vous pourriez bien l'avoir, par exemple ports ouverts.
Nous avons tous entendu des histoires de personnes qui "ont oublié" de fermer leur panneau de contrôle de cluster de l'accès gratuit à Internet entier, donc l'objectif de créer kube-hunter était de vérifier notre propre système et de s'assurer qu'il est protégé. À notre avis, les pirates analysent depuis longtemps les hôtes sur Internet à la recherche de ressources et de ports ouverts et bien connus, de sorte que votre panneau de configuration Kubernetes, qui par hasard n'est pas protégé (et donc ouvert à tout le monde), peut ne pas être si difficile à trouver, en particulier avec des outils qui ils sont habitués à utiliser.
Nous voulons que hunter aide les administrateurs Kubernetes ordinaires à mieux comprendre s'il y a des problèmes de configuration dans leur déploiement, il est donc conçu exclusivement pour Kubernetes et signale qu'il a été trouvé dans une langue que les utilisateurs de Kubernetes comprennent. Nous vous informerons donc que vous n'avez ouvert aucun port 6443, mais, disons, l'accès à ce composant particulier de Kubernetes. De cette façon, il est plus facile pour les gens de déterminer si ce qu'ils ont trouvé est un problème avec une configuration affaiblissant la sécurité et si cela vaut la peine de le corriger immédiatement - sans être un expert en sécurité de Kubernetes. Nous voulons essayer de rendre ces contrôles disponibles à tout moment, sans avoir besoin d'experts extérieurs.
Il y a une observation: beaucoup ne sont plus intéressés par ce qui se trouve à l'intérieur des conteneurs qu'ils lancent.
Oui, et ils n'ont aucune idée des dépendances qui ont été intégrées dans ces conteneurs. Bien que, si vous prévoyez d'utiliser l'approche conteneur pour déployer le service, il semble raisonnable de savoir quel type de logiciel se trouve à l'intérieur de telle ou telle image. Mais ce n'est pas un problème de l'approche conteneur elle-même, c'est seulement une attitude envers la sécurité de la part de ceux qui utilisent l'approche.
Il n'est pas si difficile de tout faire correctement et de manière fiable. Supposons que, lorsque vous entrez dans le monde du cloud, vous devez commencer à utiliser des outils supplémentaires - qui ajouteront certainement des niveaux de sécurité supplémentaires.
Les nuages ont leurs propres spécificités. Par exemple, je rencontre souvent l'idée fausse selon laquelle dans le monde du cloud, un outil auquel les gens sont habitués dans le passé fera automatiquement tout ce dont ils ont besoin. À certains égards, ils ont raison: disons que vous pouvez utiliser la liste habituelle (et toujours fonctionnelle) des paramètres de pare-feu, ce qui améliorera la sécurité, mais certains des anciens outils ne conviennent plus aujourd'hui. Par exemple, si vous déployez une image de conteneur et utilisez l'ancien outil familier pour analyser les vulnérabilités, alors si le scanner ne sait pas comment regarder à l'intérieur de l'image, il ne trouvera tout simplement rien et vous aurez (peut-être faux) l'assurance que tout est en ordre.
J'aime vraiment que lorsque vous passez à l'architecture des microservices, vous obtenez un assez grand nombre de petites fonctions disposées dans des conteneurs (dont le contenu est dans la paume de votre main) et vous pouvez voir le trafic entre eux. Chacun des conteneurs peut être perçu comme une sorte de boîte noire à partir de laquelle des actions strictement définies sont attendues. Et dès que tel ou tel récipient commence à se comporter de manière inattendue ou à produire des résultats étranges, il devient possible d'y répondre. Mieux les images spécifiques des conteneurs sont assemblées et configurées, plus il sera compréhensible qu'elles fonctionnent correctement.
Et comment attraper les anomalies? Utiliser quelque chose comme une heuristique antivirus, des réseaux de neurones?
Tout au long du cycle de vie du logiciel, nous utilisons différents outils de sécurité. runtime enforcer — , , . «», , , nginx, , nginx . , , «» , . , , . : , , .
. Serverless , , . . « »? , ?
, severless , , , . serverless — . severless-, «», . , «- ». severless. serverless- . «» , ( «» ) .
serverless – « ». serverless- pub/sub, , Redis . , , - () .
severless- , . , , , serverless- . - . , , , . serverless, - .
, serverless- . , , . ?
, , — , , , DevOps. , , , , .
, , : YAML. , Kubernetes Kubernetes, YAML. , 30 000 YAML. , , , 30 000 YAML, , , .
, Kubernetes . , , ?
Kubernetes , . , , , , - , . , , YAML- , , Kubernetes . , . , .
, Kubernetes — , . . , Kubernetes CNCF graduated, , , , , CNCF .
, : YAML, , . , YAML Kubernetes.
, YAML, , , , YAML. , , , - YAML .
, Kubernetes, , ?
Bonne question. , , , , . – Istio ( service mesh), 1.0. , , , «».
, - , .
, ?
C . , , , , !
! , : — .
DevOops 2018 «Modern security with microservices and the cloud» , «Practical steps for securing your container deployment» . .