你可能并不想把所有的遗留应用全部分解为微服务，或许你可以考虑从安全功能开始。

我为了给这篇文章起个标题，使出 “洪荒之力”，也很担心这会变成标题党。如果你点击它，是因为它激起了你的好奇，那么我表示抱歉 ^注1 。我当然是希望你留下来阅读的 ^注2 ：我有很多有趣的观点以及很多 ^注3 脚注。我不是故意提出微服务会导致安全问题——尽管如同很多组件一样都有安全问题。当然，这些微服务是那些安全方面的人员的趣向所在。进一步地说，我认为对于那些担心安全的人来说，它们是优秀的架构。

为什么这样说？这是个好问题，对于我们这些有系统安全 经验的人来说，此时这个世界才是一个有趣的地方。我们看到随着带宽便宜了并且延迟降低了，分布式系统在增长。加上部署到云愈加便利，越来越多的架构师们开始意识到应用是可以分解的，不只是分成多个层，并且层内还能分为多个组件。当然，均衡负载可以用于让一个层内的各个组件协同工作，但是将不同的服务输出为各种小组件的能力导致了微服务在设计、实施和部署方面的增长。

所以，到底什么是微服务呢？我同意维基百科的定义，尽管没有提及安全性方面的内容 ^注4 。 我喜欢微服务的一点是，经过精心设计，其符合 Peter H. Salus 描述的 UNIX 哲学 的前俩点：

1. 程序应该只做一件事，并尽可能把它做好。
2. 让程序能够互相协同工作。
3. 应该让程序处理文本数据流，因为这是一个通用的接口。

三者中最后一个有点不太相关，因为 UNIX 哲学通常被用来指代独立应用，它常有一个实例化的命令。但是，它确实包含了微服务的基本要求之一：必须具有“定义明确”的接口。

这里的“定义明确”，我指的不仅仅是可外部访问的 API 的方法描述，也指正常的微服务输入输出操作——以及，如果有的话，还有其副作用。就像我之前的文章描述的，“良好的系统架构的五个特征”，如果你能够去设计一个系统，数据和主体描述是至关重要的。在此，在我们的微服务描述上，我们要去看看为什么这些是如此重要。因为对我来说，微服务架构的关键定义是可分解性。如果你要分解 ^注5 你的架构，你必须非常、非常地清楚每个细节（“组件”）要做什么。

在这里，就要开始考虑安全了。特定组件的准确描述可以让你：

• 审查您的设计
• 确保您的实现符合描述
• 提出可重用测试单元来审查功能
• 跟踪实施中的错误并纠正错误
• 测试意料之外的产出
• 监视不当行为
• 审核未来可能的实际行为

现在，这些微服务能用在一个大型架构里了吗？是的。但如果实体是在更复杂的配置中彼此链接或组合在一起，它们会随之越来越难。当你让一小部分可以彼此配合工作时，确保正确的实施和行为是非常、非常容易的。并且如果你不能确定单个组件正在做它们应该作的，那么确保其衍生出来的复杂系统的正确行为及不正确行为就困难的多了。

而且还不止于此。如我已经在许多以往场合提过的，写足够安全的代码是困难的 ^注7 ，证实它应该做的更加困难。因此，有理由限制有特定安全要求的代码——密码检测、加密、加密密钥管理、授权等等——将它们变成小而定义明确的代码块。然后你就可以执行我上面提及所有工作，以确保正确完成。

还有，我们都知道并不是每个人都擅长于编写与安全相关的代码。通过分解你的体系架构，将安全敏感的代码限制到定义明确的组件中，你就可以把你最棒的安全人员放到这方面，并限制了 J.佛系.码奴 ^注8 绕过或降级一些关键的安全控制措施的危险。

它可以作为学习的机会：它对于设计/实现/测试/监视的兄弟们都是好的，而且给他们说：“听、读、标记、学习，并且引为己用 ^注9 。这是应该做的。”

是否应该将所有遗留应用程序分解为微服务？ 不一定。 但是考虑到其带来的好处，你可以考虑从安全入手。

• 注1、有一点——有读者总是好的。
• 注2、这是我写下文章的意义。
• 注3、可能没那么有趣。
• 注4、在我写这篇文章时。我或你们中的一个可能会去编辑改变它。
• 注5、这很有趣，听起来想一个园艺术语。并不是说我很喜欢园艺，但仍然... ^注6
• 注6、有意思的是，我最先写的 “如果你要分解你的架构....” 听起来想是一个 IT 主题的谋杀电影标题。
• 注7、长期读者可能会记得提到的优秀电影 “The Thick of It”
• 注8、其他的什么人：请随便选择。
• 注9、不是加密 摘要 digest ：我不认同原作者的想法。

这篇文章最初出在爱丽丝、伊娃与鲍伯——一个安全博客上，并被许可转载。

via: https://opensource.com/article/17/11/microservices-are-security-issue

作者：Mike Bursell 译者：erlinux 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出

这三个问题可以帮你避开不实宣传。

不错，“区块链”这个概念异常的火热。

众所周知，我一直关注区块链及相关技术的成熟度发展情况，思考我们是否对其评价过高了；但从目前的情况来看，还没有这个迹象。我在文中提到的区块链技术是广义上的，包含了狭义上不属于区块链的分布式账本技术（DLT）。我对私有链permissioned blockchain更感兴趣，其中私有链的定义可以参考我的文章《区块链是安全性方面的话题吗？》。简而言之，我对加密货币之外的区块链业务应用特别感兴趣 ^注1 。

我们对区块链的技术成熟度的判断应该有一部分可以得到证实 ^注2 。如果我们判断正确，未来将会出现海量的区块链应用。这很可能会变成现实，但并不是所有的应用都是优秀的区块链应用，其中一部分很可能是非常糟糕的。

但区块链所处的技术成熟度意味着，大量业务将快速拥抱新技术 ^注3 ，但对于可能的前景却一知半解。促成这种情况的原因可以大致分为三种：

1. 对于涉及多用户数据存储的业务应用，在投入精力的情况下，几乎都可以改造为基于区块链的版本；
2. 很多区块链相关的会议和“专家”呼吁尽快拥抱区块链，否则可能会在半年内被淘汰 ^注4 ；
3. 完全理解区块链技术是很难的，支持其在企业中落地的往往是工程师。

对于最后一条，我必须补充几句，不然很容易被引起众怒 ^注5 。作为一名工程师，我显然无意贬低工程师。但工程师的天性使然，我们对见到的新鲜事物（亮点）热情澎湃，却对业务本身 深入 fully grok ^注6 不足，故对于新技术给业务带来的影响理解可能并不深刻。在业务领导者看来，这些影响不一定是有利的。

上面提到的三种促因可能导致一种风险，即在没有充分评估利弊的情况下，将业务改造为区块链应用。在另一文（区块链：每个人都应该参与进来吗？）中提到几个场景，用于判断一个业务什么情况下适合采用区块链技术。这些场景是有益的，但更进一步，我坚信人们更加需要的是，业务完全不适用区块链的几种简单的场景判定。我总结了三种场景判定，如果对于其中任何一个问题你给出了肯定的回答，那么很大概率上区块链不适合你。

场景判定 1：业务是否需要集中式的管控或授权？

如果你给出了肯定的回答，那么区块链不适合你。

例如，假设你是一个普通销售商，具有唯一的订单系统，那么对于何时发货你有唯一的授权，显然区块链不适合你。假设你是一个内容提供商，所有提供的内容都会经过唯一的编辑和发布过程，显然区块链不适合你。

经验总结：只有当任务对应的执行流程及相应的认证流程是分布于众多主体时，区块链是有价值的。

场景判定 2：业务使用经典数据库是否工作良好？

如果你给出了肯定的回答，那么区块链不适合你。

该场景似乎与上一个场景是强相关的，但并不总是如此。在一些应用中，处理流程是分布的，但信息存储是中心化的；在另外一些应用中，处理流程需要中心化的授权，但信息存储是分布的，即总有一个并不是分布式的。但如果业务使用经典数据库可以工作量良好的话，使用经典数据库是一个好主意。

经典数据库不仅性能良好，在设计与运营成本方面低比区块链或分布式账本，而且我们在这方面技术积累丰厚。区块链让所有人 ^注8 可以查看和持有数据，但间接成本和潜在成本都比较高昂。

场景判定 3：业务采用新技术是否成本高昂或对合作伙伴有负面效果？

如果你给出了肯定的回答，那么区块链不适合你。

我曾听过这种观点，即区块链会让所有人获益。但这显然是不可能的。假设你正在为某个流程设计一个应用，改变合作伙伴与你及应用的交互方式，那么你需要判断这个改变是否符合合作伙伴的想法。不论是否涉及区块链，可以很容易的设计并引入一个应用，虽然降低了你自己的业务阻力，但与此同时增加了合作伙伴的业务阻力。

假设我为汽车行业生产发动机配件，那么使用区块链追溯和管理配件会让我受益匪浅。例如，我可以查看购买的滚珠轴承的生产商、生产时间和钢铁材料供应商等。换一个角度，假设我是滚珠轴承生产商，已经为40多个客户公司建立了处理流程。为一家客户引入新的流程会涉及工作方式、系统体系、储藏和安全性标准等方面的变更，这无法让我感兴趣，相反，这会导致复杂性和高开销。

总结

这几个场景判定用于提纲挈领，并不是一成不变的。其中数据库相关的那个场景判定更像是技术方面的，但也是紧密结合业务定位和功能的。希望这几个判定可以为区块链技术引进促因带来的过热进行降温。

• 注 1. 请不要误解我的意思，加密货币显然是一种有趣的区块链业务应用，只是不在本文的讨论范畴而已。
• 注 2. 知道具体是哪些部分是很有意义的，如果你知道，请告诉我好吗？
• 注 3. 坦率的说，它其实更像是一大堆技术的集合体。
• 注 4. 这显然是不太可能的，如果被淘汰的主体是这些会议和“专家”本身倒十分有可能。
• 注 5. 由于比方打得有些不恰当，估计还是会引起众怒。
• 注 6. 我太喜欢 grok 这个单词了，我把它放在这里作为我的工程师标志 ^注7 。
• 注 7. 你可能已经想到了，我读过Stranger in a Strange Land一书，包括删减版和原版。
• 注 8. 在合理的情况下。

原文最初发表于爱丽丝, 夏娃和鲍勃 – 一个安全性主题博客，已获得转载许可。

via: https://opensource.com/article/18/3/3-tests-not-moving-blockchain

作者：Mike Bursell 译者：pinewall 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出

题图抽象的形容了容器和虚拟机是那么的相似，又是那么的不同！

在近期的一些会议和学术交流会上，我一直在讲述有关 DevOps 的安全问题（亦称为 DevSecOps） ^注1 。通常，我首先都会问一个问题：“在座的各位有谁知道什么是容器吗？” 通常并没有很多人举手 ^注2 ，所以我都会先简单介绍一下什么是容器 ^注3 ，然后再进行深层次的讨论交流。

更准确的说，在运用 DevOps 或者 DevSecOps 的时候，容器并不是必须的。但容器能很好的融于 DevOps 和 DevSecOps 方案中，结果就是，虽然不用容器便可以运用 DevOps ，但我还是假设大部分人依然会使用容器。

什么是容器

几个月前的一个会议上，一个同事正在容器上操作演示，因为大家都不是这个方面的专家，所以该同事就很简单的开始了他的演示。他说了诸如“在 Linux 内核源码中没有一处提及到 容器 container 。“之类的话。事实上，在这样的特殊群体中，这种描述表达是很危险的。就在几秒钟内，我和我的老板（坐在我旁边）下载了最新版本的内核源代码并且查找统计了其中 “container” 单词出现的次数。很显然，这位同事的说法并不准确。更准确来说，我在旧版本内核（4.9.2）代码中发现有 15273 行代码包含 “container” 一词 ^注4 。我和我老板会心一笑，确认同事的说法有误，并在休息时纠正了他这个有误的描述。

后来我们搞清楚同事想表达的意思是 Linux 内核中并没有明确提及容器这个概念。换句话说，容器使用了 Linux 内核中的一些概念、组件、工具以及机制，并没有什么特殊的东西；这些东西也可以用于其他目的 ^注 5 。所以才有会说“从 Linux 内核角度来看，并没有容器这样的东西。”

然后，什么是容器呢？我有着虚拟化（ 管理器 hypervisor 和虚拟机）技术的背景，在我看来， 容器既像虚拟机（VM）又不像虚拟机。我知道这种解释好像没什么用，不过请听我细细道来。

容器和虚拟机相似之处有哪些？

容器和虚拟机相似的一个主要方面就是它是一个可执行单元。将文件打包生成镜像文件，然后它就可以运行在合适的主机平台上。和虚拟机一样，它运行于主机上，同样，它的运行也受制于该主机。主机平台为容器的运行提供软件环境和硬件资源（诸如 CPU 资源、网络环境、存储资源等等），除此之外，主机还需要负责以下的任务：

1. 为每一个工作单元（这里指虚拟机和容器）提供保护机制，这样可以保证即使某一个工作单元出现恶意的、有害的以及不能写入的情况时不会影响其他的工作单元。
2. 主机保护自己不会受一些恶意运行或出现故障的工作单元影响。

虚拟机和容器实现这种隔离的原理并不一样，虚拟机的隔离是由管理器对硬件资源划分，而容器的隔离则是通过 Linux 内核提供的软件功能实现的 ^注6 。这种软件控制机制通过不同的“命名空间”保证了每一个容器的文件、用户以及网络连接等互不可见，当然容器和主机之间也互不可见。这种功能也能由 SELinux 之类软件提供，它们提供了进一步隔离容器的功能。

容器和虚拟机不同之处又有哪些？

以上描述有个问题，如果你对 管理器 hypervisor 机制概念比较模糊，也许你会认为容器就是虚拟机，但它确实不是。

首先，最为重要的一点 ^注7 ，容器是一种包格式。也许你会惊讶的反问我“什么，你不是说过容器是某种可执行文件么？” 对，容器确实是可执行文件，但容器如此迷人的一个主要原因就是它能很容易的生成比虚拟机小很多的实体化镜像文件。由于这些原因，容器消耗很少的内存，并且能非常快的启动与关闭。你可以在几分钟或者几秒钟（甚至毫秒级别）之内就启动一个容器，而虚拟机则不具备这些特点。

正因为容器是如此轻量级且易于替换，人们使用它们来创建微服务——应用程序拆分而成的最小组件，它们可以和一个或多个其它微服务构成任何你想要的应用。假使你只在一个容器内运行某个特定功能或者任务，你也可以让容器变得很小，这样丢弃旧容器创建新容器将变得很容易。我将在后续的文章中继续跟进这个问题以及它们对安全性的可能影响，当然，也包括 DevSecOps 。

希望这是一次对容器的有用的介绍，并且能带动你有动力去学习 DevSecOps 的知识（如果你不是，假装一下也好）。

• 注 1：我觉得 DevSecOps 读起来很奇怪，而 DevOpsSec 往往有多元化的理解，然后所讨论的主题就不一样了。
• 注 2：我应该注意到这不仅仅会被比较保守、不太喜欢被人注意的英国听众所了解，也会被加拿大人和美国人所了解，他们的性格则和英国人不一样。
• 注 3：当然，我只是想讨论 Linux 容器。我知道关于这个问题，是有历史根源的，所以它也值得注意，而不是我故弄玄虚。
• 注 4：如果你感兴趣的话，我使用的是命令 grep -ir container linux-4.9.2 | wc -l
• 注 5：公平的说，我们快速浏览一下，一些用途与我们讨论容器的方式无关，我们讨论的是 Linux 容器，它是抽象的，可以用来包含其他元素，因此在逻辑上被称为容器。
• 注 6：也有一些巧妙的方法可以将容器和虚拟机结合起来以发挥它们各自的优势，那个不在我今天的主题范围内。
• 注 7：很明显，除了我们刚才介绍的执行位。

原文来自 Alice, Eve, and Bob—a security blog ，转载请注明

（题图： opensource.com ）

作者简介：

原文作者 Mike Bursell 是一名居住在英国、喜欢威士忌的开源爱好者， Red Hat 首席安全架构师。其自从 1997 年接触开源世界以来，生活和工作中一直使用 Linux （尽管不是一直都很容易）。更多信息请参考作者的博客 https://aliceevebob.com ，作者会不定期的更新一些有关安全方面的文章。

via: https://opensource.com/article/17/10/what-are-containers

作者：Mike Bursell 译者：jrglinux 校对：wxy

本文由 LCTT 原创编译，Linux中国 荣誉推出