今天的容器不会让任何人感到惊讶。 您会对有关容器安全的问题感到惊讶。 特别严肃地问问在生产中使用容器和微服务的同事：我经常看到惊讶的面孔和一个困惑的问题，他们说：“这是为什么？ 事实证明，我们已经对技术有所了解（以及如何在这里不知道：似乎学童甚至很快就能在技术课程中整体构建Kubernetes集群），但是他们尚未学会如何保护其组成部分。 也许根本没有人教。
在本文和
DevOops上 ，我们将
邀请一些演讲者，他们以容器友好型安全解决方案为主题。 我们向他们寻求最简单的云安全性问题的答案。 有必要开始自我教育吗？
参加者：
塞思·瓦尔戈（Seth Vargo）在Google担任开发者倡导者。 他曾在匹兹堡的HashiCorp，Chef Software，CustomInk和其他几家初创公司工作。 他是《 学习厨师》的作者，并倡导减少技术不平等现象。
Liz Rice是Aqua Security（基于云的应用程序部署安全性和容器企业解决方案）的技术推广人员。 Liz是社区中非常有名的人， Kubeon-s的董事长。
JUG.ru集团编辑Oleg Chirukhin
让我们从一个决定我们进一步讨论的问题开始。 DevOps对您意味着什么？ 它与鲜为人知的SRE有何区别？
例如，在上一份工作中，当我被要求“实施DevOps”时，我只是在SRE Book目录中走来走去，抓住了想法并逐一应用了它们。 好吧，或者至少我试图将它们传达给其他人。 您怎么说-这是正确的方法吗？
如果我们谈论DevOps，那是在避免避免深渊，通常情况下，它们是代码开发过程（Dev）与后续维护（Ops）之间的鸿沟。 想象一下，我们有一堵高墙，开发人员坐在其中的一面，他创建了一个代码，然后将它扔到墙上。 隔离墙的另一侧是支持人员。 他们捕获了转移的应用程序并开始启动和维护。 这些人知道操作过程中所需的细节。 例如，将分配和打开哪些端口以及在何处。
我要让他们彼此交流，决定下一步该怎么做，共同确定他们将在工作日内共同努力实现的目标，而不是让两组彼此不同的兴趣所在。 因此，DevOps改变了沟通文化，可帮助不同技术团队的同事为共同利益而努力：为业务创造价值，部署软件并保持其运转。 我认为这些都是非常重要的变化，它们带来了新的相关工具：如果您没有交流的文化，那么引入相同的CI / CD流程就没什么意义了。
DevOps和SRE的概念经常会引起混淆。 有些人认为SRE与DevOps竞争，其他人则认为它们是完全不同的，重叠的概念。 我认为他们不是竞争对手，而是亲密朋友。 考虑一下构成DevOps的方法-降低组织成本，将故障视为工作流的正常部分，逐步引入变更，自动化和实施为此所需的工具以及使用度量来评估流程。 如您所见，所有这些都是非常抽象的：DevOps不会告诉我们如何降低组织成本或进行渐进式更改，而只是告诉您如果将其实施会很好。
现在让我们看一下SRE。 尽管SRE方法的发展独立于DevOps方法，但SRE可以说是DevOps原理的一种实现：如果您将DevOps想象为编程中的抽象类或接口，则SRE将是实现此接口的具体类。 SRE已为许多事物和概念明确定义了方法：共同所有权，风险分担，事后检验，度量值的收集和累积等等。 因此，由于存在非常容易理解的流程和实体，组织谈论SRE的采用更为方便。
您认为“ DevOps工程师”一词是否正确？ 可以用某种方式更换它吗？
我个人不相信“ DevOps工程师”的概念存在。 您可以在我的文章“ DevOps的十个神话”中更详细地了解“ DevOps”实际上是一种意识形态：不同但本质上相互联系的组织单位之间进行更多的交流与合作。 尽管今天它看起来相当健壮和熟悉，但起初这种方法引起了赞扬和严厉的批评。 从那时起，包括Etsy，Facebook和Flick在内的许多组织都成功地实现了DevOps的原理。
因此，这些组织中没有一个雇用“ DevOps工程师”。 实施的成功可以归因于团队之间正在形成的内部合作以及愿意改变其现有流程和程序以实现一个共同目标的意愿。 所谓的“ DevOps工程师”的作用是鼓励团队之间的协作，并确保组织单位定期交换想法和目标。 实际上，今天我们已经有这些人了，我们称他们为“经理”。
我将再增加一分钟。 当我们任命某人担任特定职位或角色时，我们开始期望他做出非常具体的事情和行动，因此选择职务很重要。 但是职位的确切名称可能会因组织的当地实际情况和传统而有所不同，因此，重要的不是名称本身，而是公司所有工作人员职位之间的平衡。
不久前，我与一个在相当大的组织中工作的人进行了交谈，因此他们创建了一个由数名员工组成的团队，并将其称为基础架构团队。 然后，这个团队改名为其他团队，不久之后又成立了另一个团队，现在又称为基础架构团队-结果，每个人都感到困惑：谁是“基础设施专家”，他们的作用是什么。
我认为，最重要的不是拥有特定名称的团队或职位，而是在组织内部清楚地了解谁对什么负责。 不管它们叫SRE还是DevOps都没关系：主要是要了解特定名称对这个特定组织的含义。
Liz，您正在咨询，您如何向客户公司解释DevOps原则？ 他们听起来很抽象，很难解释。 或者，也许您已经开发出某种方法，可以将这些想法传达给客户？
这取决于目的。 在协商过程中与我沟通的许多人和公司都来找我们，说他们想部署Kubernetes和容器。 但是在谈论技术之前，您需要了解为什么他们试图采取这样的步骤。 事实证明，变革的预期收益通常归结为更加灵活的愿望。 因此，朝着技术团队可以更快地发布其工作成果的方向发展，类似这样的解释“触手可及”。 在这一点上，将对话转移到这样的一边是很有用的，即团队成员之间缺乏沟通的文化问题（习惯，如果您喜欢的话）不会因任何“新”技术的介入而得到解决，交流是最重要的资源。
另外，由于我经常发现自己致力于提高解决方案的安全性，因此我们的讨论转向了“ Dev-** Sec **-Ops”，事实证明，应该构建该系统，以便最大程度地确保安全在流程的早期阶段，不仅以老式的方式解决了这个问题：首先编写应用程序代码，然后部署它，然后将其传递给维护服务，直到最后，才有人开始考虑运行中的代码的安全性。
实际上，许多安全问题在流程开始时较为便宜且易于解决，但是从一开始就需要在项目中提出很多要点。 例如，如果您打算使用容器，则需要担心以相当安全的方式收集图像。 扫描它们的漏洞可能很有用，以便至少避免部署存在已知安全问题的软件。 也许您将尝试配置容器，以使它们中的软件默认情况下不会从根目录启动（通常为简单起见，无特殊需要，它们是在组装容器时完成的）。 如果采取这些步骤，最终您将获得应用程序安全性的增强，并且在所有这些DevOps的背景下，您可以谈论SecOps文化。
但是，这意味着实际上不是应用程序安全专家的开发人员被迫不仅考虑应用程序代码，而且创建自己的安全系统。 您认为对于现代软件开发人员或操作工程师而言，最低技能应该是什么？
您和我，无论我们是否喜欢，都会不断看到新规则和要求的出现，这些规则和要求在某些时候似乎是必须满足和遵守的：以相同的GDPR为例。 这些法规的出现和存在意味着越来越多的人必须具有安全感。 例如，今天您不能再将纯文本格式的用户名和密码存储在数据库字段中-不再被认为是至少可以容忍的。 我要说的是，在业界，每个人对“卫生”的要求已经非常明确。
工具和基础架构的制造商自己对此过程产生了重大影响，他们试图设计和更改系统，以便用户可以从一开始就构建更安全的应用程序和系统。 例如，在过去的一年中，在Kubernetes中，许多默认设置和参数值已朝着更高的安全性方向更改，这确实非常酷。 以前，默认情况下，API服务器已打开以进行匿名访问-这与您期望的“开箱即用”完全不同。 现在出现了基于角色的访问控制之类的事情，因此我们现在有了权限（是的，“开箱即用”），并且当您首次启动Kubernetes时，您并没有对全世界开放，因此默认情况下会受到保护。 我认为这是在熟悉的过程中使每个人都可以使用安全性的好方法，因为我们不必将默认值不断更改为安全值（此外，还必须牢记）。
我个人认为，每个软件工程师都应该至少对安全性有基本的了解。 诸如OWASP（开放式Web应用程序安全性项目）方法之类的东西可以解救，但最终工程师需要接受自学。 每个工程师不太可能拥有密码学博士学位，但是如果我们希望我们的同事认真对待安全性，我们应该使他们更容易做出正确的决定。 这是Vault等工具可以提供帮助的地方-安全团队和专业人员可以做出决定并提供“作为API的安全性”。
如果我理解正确，则有一种将所有内容转换为代码的趋势。 一切如代码。 基础设施作为代码，流程作为代码，代码作为代码。 这意味着什么？
在讨论后果之前，我们需要谈谈好处。 该代码已经存在很长时间了。 应用程序始终是“代码”，在此期间，已经创建了广泛的工具和过程生态系统，以支持和改进应用程序开发过程（CI / CD，棉绒，用于联合开发的工具等）。 在将基础架构描述为代码，将流程描述为代码，将安全性描述为代码之后，我们可以使用相同的生态系统，而无需为此付出任何额外费用。 您可以共同开发基础架构变更，进行政策审查等。 您可以在部署基础架构变更之前对其进行测试。 这些只是将某些内容转换为代码所带来的一些好处。
我认为最大的后果是时间和复杂性。 当您使用“类似代码”的东西（例如，通过Terraform，Vault，CloudFormation，Deployment Manager等）时，有时您会遇到代码写的内容与实际发生的情况之间的差异在云中。 有时很难从视觉上对复杂的关系进行建模，尤其是考虑到缩放比例。 另外，我们可能会遇到抽象的不准确之处-例如，通过API工作的脚本可能无法感知当前的事务状态，因为它是通过Web界面显示给用户的。 但是，随着时间的流逝，复杂性会降低，灵活性会得到回报。
代码和其他形式模型是适合机器分析和机器学习的领域。 机器人何时才能取代我们？ 我们应该如何回应？
机器人可以在没有人的情况下配置Kubernetes吗？ 尤其是某些专业人士（例如具有高度交互性的系统管理员或软件测试人员-“手动测试人员”在社会上可以接受的词）可能会消失吗？
我认为人们不会消失，但我怀疑我们今天拥有的一些工作将来不会保存下来。 我住在世界上无人驾驶汽车控制系统之都匹兹堡，几乎每天都能看到无人驾驶汽车。 当然，将来，出租车司机将被机器人驾驶技术取代。 也许不是立即，而是经过10年或更长时间后，但这种未来将不可避免地来临。 但是，我认为出租车司机不会消失。 人类正在不断地自我改造。
我相信对于管理领域的机器学习也可以这样说。 我期待更多的AI可以使我们的系统更加稳定和有弹性，并且我认为我们可以决定采用这种方法-或接受它。 传统系统管理员的角色可以由控制AI系统的人员代替，但这并不意味着人员本身就会消失。 我们在几个行业经历了相同的转变，在这些行业中，技术和创新提供了比人更高的速度和准确性，但最终，有人需要跟随机器人:)。
想象一下，常规的开发团队创建了一个Web应用程序，并将其放置在Kubernetes集群中。 我们如何确保应用程序安全？ 雇用试图发现安全漏洞的黑帽黑客或专家，或者有没有那么简单的方法？
我们最近在Aqua Security发布了一个名为kube-hunter的开源工具。 它能够测试Kubernetes的黑客攻击或渗透-使其成为一个相当简单的测试。 您可以使用此工具并测试自己的集群，并且几乎可以肯定会为您自己学习一些有趣的东西，尤其是如果您的安装基于旧版本的Kubernetes，默认设置不太安全-例如，您可能拥有打开端口。
我们都听到过有关人们“忘记”关闭其集群控制面板以免自由访问整个Internet的故事，因此创建kube-hunter的目标是检查我们自己的系统并确保该系统受到保护。 我们认为，黑客长期以来一直在扫描Internet上的主机以查找开放的知名资源和端口，因此，您的Kubernetes控制面板（并非偶然受到保护（因此对所有人开放））可能并不难找到，尤其是使用以下工具他们习惯了。
我们希望猎人帮助普通Kubernetes管理员更好地了解其部署中是否存在配置问题，因此它是专为Kubernetes设计的，并报告了它是使用Kubernetes用户理解的语言找到的。 因此，我们将通知您，您尚未打开任何端口6443，但可以访问Kubernetes的此特定组件。 这样，无需Kubernetes安全专家，人们就可以更轻松地确定所发现的安全弱化配置是否存在问题，以及是否值得立即解决该问题。 我们希望尝试在不需要外部专家的情况下随时进行这些检查。
有一个观察：许多人不再对它们启动的容器中的东西感兴趣。
是的，他们不知道这些容器内置了哪些依赖项。 虽然，如果您计划使用容器方法来部署服务，则找出该映像或映像中包含哪种软件似乎是合理的。 但这不是容器方法本身的问题，只是使用该方法的人员对安全性的态度。
正确，可靠地完成所有任务并不难。 假设进入云世界时，您需要开始使用其他工具-几乎可以肯定会增加其他安全级别。
云有自己的特点。 例如，我经常遇到一个误解，即在云世界中，人们过去所习惯的一种工具会自动完成他们需要的一切。 在某些方面，它们是正确的：假设您可以使用常规的（并且始终可以使用）防火墙设置列表，这样可以增强安全性，但是某些旧工具如今已不再适用。 例如，如果您部署一个容器映像并使用旧的熟悉的工具扫描漏洞，则如果扫描程序不知道如何查看映像内部，它将根本找不到任何东西，并且您会（可能是错误的）确信一切井井有条。
我真的很喜欢，当您进入微服务的体系结构时，您会获得大量布置在容器中的小功能块（它们的内容在您的掌中），您可以看到它们之间的流量。 每个容器都可以看作是一种黑匣子，从中可以期望严格定义动作。 一旦这个或那个容器开始以意外的方式运行或产生奇怪的结果，就有可能对此做出响应。 容器的特定图像组装和配置得越好，它们能否正常工作就越容易理解。
以及如何捕捉异常？ 使用诸如防病毒启发法，神经网络之类的工具？
在整个软件生命周期中，我们使用各种安全工具。 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, , ?
好问题。 , , , , . – Istio ( service mesh), 1.0. , , , «».
, - , .
, ?
C . , , , , !
! , : — .
DevOops 2018 «Modern security with microservices and the cloud» , «Practical steps for securing your container deployment» . .