标签：基础 代码 终于有人把微服务架构讲清白了 容器 工程师 系统 DevSecOps IaC 编排 安全性
第一节介绍
随着基础设施即代码、微服务和容器等云原生技术的兴起，安全责任正在向工程和 DevOps 团队的方向迅速转移。由于工程师可以更好地控制更广泛的基础架构以及用于配置和管理基础架构的流程和系统，因此他们对基础架构安全性的责任越来越大。这种趋势应该是一个强有力的考虑因素，因为良好的 DevSecOps 使应用程序部署、操作和服务监视更容易、更安全。特别是，开发人员将负责保护他们构建的基础设施即代码，DevOps工程师将负责使其尽可能无缝。
基础结构即代码 （IaC） 改变了团队构建和管理基础结构的方式，也改变了保护基础结构的方式。但是，尽管 IaC 具有所有可扩展性、一致性和可管理性优势，但它也带来了自己的挑战。其中一个挑战是确保所有部署的 IaC 都是安全的，而不会中断发布速度。
第二节
什么是 IaC？
IaC 是指用于通过软件（而不是手动操作）管理和预配基础结构的技术和流程。无论是用于预配本地资源还是云资源，IaC 工具和流程都允许工程师使用代码模板和自动化构建流程一致且可靠地构建、部署和管理基础架构。
IaC 框架可以是必需的，它定义了达到所需结果所需的步骤，也可以是声明性的，它定义了最终结果的所需状态，自动化平台最终采取步骤来实现它。最常见的IaC工具是HashiCorp的Terraform，AWS CloudFormation和Azure资源管理器。与任何其他框架相比，完全开源的Terraform使IaC具有无限的可定制性和多云性，从而为周围的IaC生态系统铺平了道路。
IaC 允许像任何其他应用程序代码一样存储、版本控制和审核基础结构。但是，由于其瞬态性质，IaC 需要大量的生成过程才能将代码预配到正在运行的资源中。
图1：整个开发生命周期中的基础架构即代码
由于正在运行的资源与预配它们的 IaC 模板之间可能存在断开连接，因此可见性至关重要。确保开发团队在其代码库和交付流程中以及从运行时到运行时具有可见性，可确保保持不变性。这意味着对基础结构的所有更改都是通过 IaC 模板在源代码上进行的，而不是通过云控制台或操作已部署资源的脚本进行的。
Terraform 使用 HCL（HashiCorp 的一种特定于领域的语言）来定义带有代码的基础设施，您可以将这些代码签入版本控制或存储在 S3 存储桶中。
例如，以下模板将单个 EC2 实例定义为：
module "ec2_instance" {
source = "terraform-aws-modules/ec2-instance/aws"
version = "~> 3.0"
name = "single-instance"
ami = "ami-ebd02392"
instance_type = "t2.micro"
key_name = "user1"
monitoring = true
vpc_security_group_ids = ["sg-12345678"]
subnet_id = "subnet-eddcdzz4"
tags = {
Terraform = "true"
Environment = "dev" }}
可以使用Terraform CLI 在 AWS 上预置此 EC2 实例。
IaC 的挑战
与任何新兴技术一样，IaC也有其自身的一系列缺点，主要与缺乏凝聚力意识和增加复杂性有关。毫无疑问，采用 IaC 有一个学习曲线，这与设计上的手动基础结构预配不一致。替换已建立的流程和技术可能会造成破坏。
由于它可以与手动云编排并行运行，因此在没有完全可见性和协作的情况下实施 IaC 可能会导致混淆资源配置和管理方式和位置。完全采用后，其不可变性质意味着无需对已部署的正在运行的资源进行故障排除和修复，只需更新 IaC 模板即可重新预配它们。
对 IaC 预配的资源进行手动更改时，会失去不可变性，并引入服务损坏或意外行为的风险。此外，如果手动更改是配置错误的修正，则下次预配 IaC 时将覆盖该修复，从而使安全性留下重复性工作。与将任何新技术添加到已经复杂的基础架构堆栈时一样，IaC 也可能带来安全风险。
IaC 引入的主要安全风险包括：
- 基础设施在混合云环境中不断发展，部署在本地和多云环境中。能够有效地管理这些复杂部署的安全性，同时控制运营成本，这一点至关重要。
- 由于许多组织面临成本压力，可用于管理环境的资源较少。此问题会导致重大挫折：随着基础架构的增长，管理它的资源会减少或保持不变。
- 不断变化的威胁形势对组织提出了挑战，因为它既无情又似乎领先一步。公司数据和知识产权比以往任何时候都更容易受到更复杂和分层的云原生堆栈的攻击。
第一节
什么是 IaC 安全性？
基础设施即代码为嵌入一致且可扩展的云安全覆盖范围提供了难得的机会。IaC 安全性是指解决 IaC 中的云配置问题，而不是部署的云资源。由于 IaC 不代表基础结构本身，因此 IaC 安全性是达到目的的一种手段。它确保 IaC 的配置方式使其能够预配安全资源。IaC 安全性是一种主动的云安全方法，从历史上看，该方法已在运行时解决配置的云资源。如果使用 IaC，这种被动方法会在涉及云安全问题时引入风险和冗余。
云安全问题（通常称为配置错误）通常与保护对关键服务和客户数据的访问有关。每种云和资源类型都有自己的一组安全最佳做法（通常称为策略）和相应的合规性基准，IaC 是一种以编程方式识别违反这些策略的情况。组织还可以针对其基础结构和业务需求实施自己的策略。
IaC 安全性的工作原理
就像应用程序代码的静态分析一样，IaC 安全的最基本形式是能够扫描 IaC 以识别错误配置。扫描 IaC 涉及根据已知策略检查模板、文件、模块及其变量。当正确的设置缺少变量或值设置不正确时，会发生策略冲突。
由于每种云和资源类型都有自己的安全标准，因此可能有数百种（有时数千种）策略可能与您的堆栈相关。依靠开发人员来跟踪这些策略是不可能的，这就是为什么自动化是获得跨云环境全面覆盖的最佳方式。通过自动化 IaC 扫描，组织可以节省时间并提供仅通过手动工作无法实现的覆盖范围。有一些开源工具，如开放策略代理（OPA）和Bridgecrew的Checkov，使任何人都可以根据已知策略扫描IaC文件或目录。
下面是利用 Checkov 根据一些策略扫描 Terraform 的示例。
标签：基础,代码,终于有人把微服务架构讲清白了,容器,工程师,系统,DevSecOps,IaC,编排,安全性 来源：
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。