DevOps自动化治理

我如何卷入这真的很多东西,但是我想我会开始的地方至少我能够激发这个想法到纸上,然后我做一些进一步的文件但是…基因金,一部分革命,凤凰城项目的作者,邀请约40人每年去波特兰,我们已经做了7年,我们这些论文,成为论坛论文,电子书,我一直这样做,我认为,2014年是第一年，所以我每年都这么做。总的来说，我数了一下，包括今年，我们刚刚完成了四五本书，今年夏天就会出版，我想在七年内会有大约30本书，所以我一直在参与。其中一些我分享了我做过的项目，多年来我在很多书中只是一个漂浮者。所以，有些年我喜欢在不同的项目之间来回切换。
但我指出这一点的原因是，从2015年开始，我和一个工作组间接合作了这本电子书，所有这些都在知识共享协议中，你可以从IT革命论坛的论文中下载。它被称为“一个不太可能的联盟:DevOps和审计”，所以至少从DevOps It革命的角度来看是这样的。第一次关于如何审计和我们用DevOps做什么的对话应该有一个更紧密的对话。职责隔离，这类事情需要证明，我们在DevOps手册中也谈到过。我们讨论了某些模式的方式，如果你可以使用DevOps来交付软件，实际上可以像其他的一样应用于一些遵从性要求的PS想法。然后在2018年，这是一篇很棒的论文，这篇论文不是我写的，但我是一名顾问，正在围绕它工作。它的名字叫《亲爱的审计师》，很棒。
这实际上是一封给审计人员的道歉信。就像“嘿，我们真的很抱歉，你知道，我们应该这么做的，我们应该和你谈谈这件事的”，这不仅是道歉信，而且还有一份我们承诺要做的事情的清单，实际上，如果你谷歌“亲爱的审核员”实际上是一个关于这个的Github项目，这真的很好，主题是关于审计和DevOps的。
几年前，我开始想到我们如何从审计的管道角度做得更好，所以在去年的2019年，实际上，通常这些论坛大约在4月开始，我们通常在第四季度或第三季度或第四季度末的某个时候发布工作。因此，我组建了一个团队，真正专注于我们所说的DevOps自动化治理，它是一个参考架构，我会更详细地解释它。所以,几件事情前一年之前的两年让我真正感兴趣的,Capital One多年来一直积极参与这些论坛论文,多年来我们已经讨论管道、闸门的管道,在2017年,Capital One写了一本非常有趣的论文他们如何做,你知道,关注DevOps管道有一个分段称为“创造更好的管道”,这是什么他们谈论这些门,他们称之为16门。这些东西使得服务团队可以绕过像CABs这样的中央集权。换句话说，他们可以得到一种自动部署的许可，如果他们能证明这些东西确实来自源代码控制，它有最佳的分支策略，静态分析，所有这些东西。
我想我去年看过一个报告，他们说现在已经有30个了。但是在关于这个话题的讨论中，有这些门是很好的。但是，既然你有这些门，我们能不能把这些门变成证据?所以在一年左右的时间,我们一直有这样的对话,可以说是让我开始思考这个,然后在文章的同时,谷歌宣布一个开源项目叫做Grafeas事实证明这是一个项目,他们是用内部审计治理,它有很多功能,我认为很多功能还没有被利用,但在特定的一个认证,元数据认证,认证的证据。我开始思考，实际上Kit Merker，我的一个好朋友，也是青蛙，在青蛙公司工作，他找到我，问我为什么不考虑使用Grafeas，我们聊得很开心。这让我想到了去年，我试图把一群人聚集在一起，说“嘿，我们可以围绕这个自动化治理的想法创建一个参考架构吗?”
你知道，这些条款非常多，但我们有一个具体的章程，我们想在这个特别的。所以我们实际上发布了，这个出来了，它是知识共享协议，正如你们之前看到的，它是去年9月发布的实际上是来自Saber的Mike Nygard。你可能认识《释放它》中的Mike Nygard，他是断路器模式的发明者，Capital One的Tapabrata Pal, Steve Magill, Sam Guckenheimer，他一直积极参与微软的大部分基础设施，我自己，PNC的John Rzeszotarski, Dwayne Holmes，他在万豪管理Kubernetes的大型基础设施，还有Nike的Courtney Kissler。所以我们聚在一起讨论了几天，我们试着讨论，我们是否可以把它写进一篇论文，就参考架构而言，比如最终模型是一个微服务Java，在一个容器中，可以进入Kubernetes，使用Grafeas，实际上是kritis。所以我进入这个行业的一个目标是改变为审计师创造证据的语言。你知道，通常情况下，审核员进入一个站点，他们在附近的某个地方花费30天，与组织一起工作，观察变化，他们真正做的是，证据实际上是主观的。所以证据和证明，在这个对话中，意思是一样的。所以，改变主观证据的想法，主观证明变成客观证据或客观证明。
因此，目前人们在大多数大型企业中创建变更记录。然后是人类的讨论，比如苏要做这些事，鲍勃要读这些事，也许萨利想让苏多写几行。这些都是复杂的系统，所以它通常是一个人类电话游戏，试图记录变化的复杂性。然后审计员来了，看到了这个关于工会的讨论，主观的讨论作为证据，然后试图理解它，这是很辛苦的，有很多脱节，这是。它没有很高的效果。那么，我们真的能改变吗?让这些证据成为内置在自动化、非人为干预、自动化和内置在数字签名机制中的管道本身。所以它是一组签名，基本上变成了一个不可变的签名链表。所以，当我们坐下来考虑写这个东西的时候，它实际上是三个目标。一个是审核时间短，我们能不能把30天的审核变成半天的审核?
我们的想法是，除了主观的讨论和比较屏幕打印，我们实际上可以只是展示一个不可变的列表，我们真的不想叫它区块链，但它是基于区块链模型的，你可以只是展示一个人类没有改变的证据的不可变列表，实际上，没有人类的互动，所以，你只是看着这些不可变的列表，然后下一个，下一个，下一个。第二个问题是，我们能否提高疗效?我的意思是，事情的真相是，在过去的三四年里，我花了很多时间和CILs在一起，然后采访了一个组织中的很多人。大多数人，他们的大部分审计，我称之为安全和合规剧院，当你进入云原生和微服务的现代化时，这甚至不包括在内，甚至更糟糕。因此，他们认为他们需要在这种快速部署结构中进行认证，这是完全不相关的。所以你会发现在大多数组织中，审计的效率是非常低的。
那么我们能不能把审计的效率从20%提高到90%最后，但并非最不重要的是，如果我们能做到这一点，我们可以提出一个有说服力的论点，远离顾问委员会或CAB或中央集权的改变，你知道，如果你想想第一资本的原始文章。所以我们坐下来，我就不详细讲了因为这是参考架构。我只是想让你们了解这些想法，如果你们感兴趣，可以下载它的知识共享副本，它在itrevolution。com上。所以我们把它分成了七个阶段，我们的想法并不是真正关注人们如何看待管道，而是为认证创造边界。记住，每次我说的证明，都是指证据。那么，什么是认证的逻辑阻塞或边界，所以我们提出了一个开发构建，打包在它自己的阶段，非prod/prod，我们放置依赖和工件的原因，它在传统CI/CD路径的生命周期中，但依赖管理工件有自己的生命周期，有点异步。所以我们要确保大家都明白这一点。
然后我们达成共识，我们称之为公共控制和公共参与者，这些控制基本上就是证明。如果你还记得我之前说过的话，那就是耐克、第一资本、PNC、万豪和Saber集团。当一切都准备就绪，我们有大约75个认证。现在我不认为一个公司或一个组织或一个服务会使用所有这些，但它是一个参考工件，以显示可以完成什么。你可以看，我不会详细讲，但如果你在源代码阶段，比如出现在投票请求或单元测试覆盖率，干净的依赖关系，扫描，如果你到了构建阶段，单元测试，检测，输入/输出角度的不可变性，我还是故意讲得快一点，因为如果你感兴趣所有这些，每一个都写了出来，大概有两页，三页每一个控制点的聚合,依赖管理、许可检查,批准了外部资源,安全检查,老化,所以不允许失效构件,通过版本,包,公证,或签名的签名,或者如果你想从一个动物园管理员之类应用元数据操作时确保元数据不能砍,也不能站在中间的那个人,所以很多在这里,就像我说的75工件阶段,保留期，不可变的工件，产品阶段，如果你看看prod或prod或非prod，一些微妙的区别，但允许的配置。
所以，当你在处理Kubernetes和容器时，对手有很多机会通过错误的配置定义来创建对手。因此，确保你捕捉到这些类型的东西作为证据，然后我们试图做的是，然后通过并识别一个例子，不是建议，只是一个例子，控制点在哪里，它们来自哪里，像SonarQube或Checkmarx，然后当然是JFrog x射线，但这些都不是真正的建议，它真的只是一个。
对我们来说，“这有意义吗?”然后，“我们能快速浏览一下所有这些证明可能来自哪里吗?”随着项目的进行，我们并没有完成我们想要完成的所有事情。我们最终用Grafeas和Kubernetes给出了一个骨干架构的参考架构，我们想在管理控制器中做这个简单的_，它的符号非常简单。但真正有趣的是，当我们进行这些对话时，当我们在写论文时，你知道，晚上我们去吃饭，所有写论文的人都会出去玩，然后我们开始思考，如果你可以创建这个DevOps自动化治理架构，那么我们是否可以开始考虑模板，比如，这些事情的合适模板。
如果你能做到这一点，你真的能创建人类可读的代码来应用这些模板吗?所以这真的只是一次晚餐谈话，但其中一个银行走出去，全身心地投入到这个问题中。他们投入了大量的资源，我们现在称之为政策2022世界杯阿根廷预选赛赛程即代码。所以我们实际上打算在这个夏天做这件事，开始这个文件的第二个版本我们将真正关注政策我将向你们展示一些东西作为。
我是一名顾问，但其中一家银行真的把它提升到了一个全新的水平，并发布了参考架构。所以，这里有一些关于治理的原则，人类可读的，平台不可知的，持久的，我再一次让你们用幻灯片来读，条件参数。但事情是这样的，这家公司所做的是进入并创建了他们所谓的打包文件，政策是代码文件。有趣的是，这些都是人类可读的文件政策制定者们正在参与其中。实际的政策的人,所以现在发生了什么,服务所有者想经过这可以说是新定义的方式处理事情,和有很多的优点,所以人们想要做到这一点,他们必须去政策的人,这是由设计和政策的人,然后他们会想出一个人类可读的包文件将与该服务相关的定义,然后所以我们与之交谈过的证明之类的东西会被定义。如果你看一下管道版本控制，每个应用程序或服务都必须有实际组件的助记符，必须有服务的助记符，组件ID和版本。
然后你可以看到后面的单元测试覆盖率，然后你有一个拉请求审查，所以这些东西实际上是与服务所有者合作编写的，与实际的策略人员一起编写的，顺便说一下，现在策略人员来设计需求，这些变得不可变，因为它们实际上与工件一起存储在源代码控制中，以便他们可以交付服务。所以没有，你有DevOps自动化治理架构，我马上会向你展示它是如何进步的。每次你做合并时，你会拉入所有提交的证据，你会拉入当时的包文件和所有其他工件，这将是不可变的证据，最终会在Grafeas和认证存储中。
所以现在你两全其美了。你没有政策人员试图将电子表格提供给基础设施人员，服务人员，而服务人员不得不将这些电子表格解释为可能会被控制的东西，很少有证据。现在你什么都有了，门控和证据都集于一身了。这就是它很酷的地方，我将向你们展示一家银行正在使用的架构。他们现在使用的是OPA和Rego如果你还记得在那个包文件中，有一个版本控制管道，所有的服务都必须有助记组件反转。所以基本上你现在想到的是接口定义包文件是风险人员和服务所有者之间的合作然后实现可能是像Rego这样的东西。这里有一个实际使用包文件和Rego在Kubernetes中控制是否从策略角度允许某些事情的例子。
这真的非常非常酷。我的意思是，我们甚至在讨论下一个版本，如果你有了这些，你可以做政策航空预算，对吧?这是一个样本架构，它比这个要复杂一点，但你基本上把卡夫卡放在两端。实际上现在，我们正在尝试弄清楚我们是否可以加入，我说我们在顾问模式，但是，如果我们可以加入一个无服务器架构，当你得到总量级别时，像Kafka，无服务器实现，Knative，然后Kafka，然后进入这个执行者证据引擎，执行者可以与OPA集成。这真的很酷。希望在下一个参考体系结构定义中，我们能得到其中一些东西的开源，但无论如何，我们都会有一个非常健壮的参考体系结构，说明它是如何工作的。另一件很酷的事情是，今天大多数企业都有一个问题，根据我的经验，很少有企业。
其中一个问题，让我后退一步，在企业中审计的一个问题是，它是基于，大多数审计是基于传统的服务管理模型，其中每个更改都必须与服务所有者相关联，而服务所有者传统上与CNDBCI配置项相关联。
我不能告诉你,我参观了在过去,你知道,三、四年,任何大型机构,诚实地告诉我,CNDB比25%更准确…所以如果你的整个模型的证据在审计是基于这种错误的想法,而不是基于像Git,发生的事情你知道,Github,各地的詹金斯,或构建模型…就像,这个模型的美,就是为了玩,你必须真正定义，所以你真正开始创建一个紧急配置管理数据库，因为你必须找到一个助记组件反转，根据定义，所有在这个过程中建立和获得更多价值的服务实际上都成为紧急NDB。不仅如此，你还可以看到这种持续的审计回放，因为记得我之前说过，这些工件是不可变的，事实上你确切地知道哪个版本的包文件被推送了，实际上Rego文件也在那个时候被推送了，所以你总是可以返回并回放。
另一件事，记得我们讲过的航空预算，所以现在你可以分析持续的证据或者持续的遵守，如果你愿意或者我们所说的自动化管理，是失败的事情，对吧?我想讲的另一个话题是，那篇论文发表了，我已经讲了一年左右了然后在纽约有一个组织叫做开放网络用户组由一个叫Nick Lippis的人管理他们的董事会成员就像纽约乃至世界上最大的银行。今年的焦点之一是软件定义网络，SD-LAN，他们已经更多地转向DevOps，一些董事会成员看到了我们做的这篇论文，Nick Lippis认识我，所以他找到我，问我是否愿意帮助驱动基于我们做的那篇论文的云自动化治理。所以我们聚在一起，这次我们创造了，这真的很酷，因为参与这个项目的人有联邦快递，凯撒医疗集团，信诺，摩根大通，我认为……
是的，摩根大通，然后是间接的Don Duet，他是高盛的工程副总裁，他现在是独立的，我们专注于云提供商与租户的认证关系。现在我们很快地过一遍。再说一次，这是一本知识共享的书，一篇论文可以从ONUG获得。你知道，它很容易找到，你可以下载。你需要填写一些名字之类的东西，但这是一本免费的书。实际上，这篇论文得到了很多，大约一个月前，不到一个月前，《华尔街日报》写了一篇关于它的文章，他们采访了，它实际上是由联邦快递，信诺和凯撒医疗机构赞助的，所以赞助这篇论文的三个公民社会组织接受了《华尔街日报》的采访谈论了我们在这篇论文中所做的工作。所以非常非常重要的工作，我会试着再总结一遍，我不打算讲太多细节，就像我说的，我将留给你们，听众，读者，如果你们感兴趣的话，很明显，我的联系方式在这个演讲中随处可见，如果你们想谈论它的话。
如果有人认识我，我喜欢谈论或探索这些东西，但是……我们在这篇论文中的目标是，我们有三个目标，它们真正关注的是云提供商向这些云的租户或消费者展示证据。所以我们想确定的一件事是，我们能不能问问社区，我也想弄清楚的一件事是，最初我们坐下来的时候，每个人都说:“如果你能想到所有三家或五家云提供商，或者其他多少家云提供商，你就疯了。”尽管我们在这个团队上投入了大约250亿美元，但我从一开始就说，“我们不要担心试图说服亚马逊或谷歌或微软……因为那不应该是我们论文的重点。”我们的重点应该是，说服另外100家公司，这将代表1万亿美元的资产购买力”，如果他们都同意这篇论文，那么我们可能会，顺便说一下，我们将在今年夏天做第二个版本，三大云提供商中已经有两家加入，所以任务完成了。
这里有三件事。一个是，我们能得到一个统一的格式吗?所以这意味着，每个云提供商都同意创建一个统一的…某种类型的签名的标准化版本，告诉你与他们做的方式没有任何改变_。这个签名告诉你，你知道已知状态，他们不需要告诉任何IP他们是怎么做的，任何秘密只要保持简单，我知道没有这么简单，但想象一个检验和事件告诉你，你所看到的任何物体的姿态都没有改变。所以它的规模对启动顺序或启动基础设施的改变实际上会为对手创造新的机会，例如，所有事件审查的首要原则是，回到最后的改变。
想象一下，如果我们能在所有的提供者之间保持，规范化一个事件，它告诉我们每次我们做一个新的部署，或者每天一次，在这个序列中没有任何改变。或者出了问题，我们可以检查这个序列。再一次，更多的细节。第二点是，既然所有云提供商都能看到来自租户、消费者和所有API调用的所有Ingress请求，那么他们是否能够以某种规范化的格式将这些请求公开给租户呢?你想要这个的原因是，今天很多云的消费者会抓取日志，他们这样做，他们为不同的提供商抓取不同的日志，即使在扩大的结构中也没有标准化的方法，更不用说抓取日志之类的事情了，你知道，日志会变化。
我们能不能说，既然你看到了一切，你能不能把它吐回一个事件网关，我们可以通过某种Knative或某种类型的事件网关流程来处理，我们可以直接看到你看到的东西。因此，对于像服务请求伪造，或者一些逃逸活动，或者有些人不遵守规则，没有放置正确的元数据，有一个单一的控制点来识别任何可能给我们带来麻烦的异常行为会容易得多。最后但并非最不重要的是，从安全框架中寻找规范化的结构。所有不同的产品都有安全框架，他们使用hth华体会最新官方网站不同的语言，他们没有真正与安全专业人员交谈，所以，在论文中有更多的内容。
这是标准化的模型。就在这里结束，最后一件事是我们试图做的一件事是基于Gherkin创建伪代码它是基于YAML的，所以我想尝试探索一个不同的模型，看看我们是否可以尝试用Gherkin做一些事情。这里我有几个基于这两个模型的例子。引导完整性,这基本上就是一个小黄瓜的模型检查,看看如果,意图或校验和的引导顺序哈希已经改变了,然后这是一个,如果我们收到的所有入口流量的提供者,我们听,我们可以查找元数据,应该是如果它不是,那么我们可以去找有几分邪恶的演员像一个加密矿工等等。
像往常一样，我想以一个，我谈到Kit Merker，我谈到JFrog，我真的很喜欢JFrog家族，他们邀请我来演讲，我想这就是我喜欢他们的原因，我猜他们也喜欢我，但是这本书，这本《液体软件》讲了很多关于自动化治理的原则在组件管道中建立信任。这是另一种"我认为我在做正确的事"几年前，当我读这本书的时候，它谈到了格拉夫斯，它帮助我说，不止一个人告诉我这是必要的，一切都变得有条不紊。这是一本非常棒的书。我总是试图在结束这些演讲时说，这是一个快速的阅读，它真的完美地设置了心态。无论如何，非常感谢你们的聆听，我希望你们喜欢，如果你们对其中任何内容感兴趣，请联系我，我很容易找到。我喜欢讨论这些东西。