动态 DevOps 环境中的 IT 治理

动态 DevOps 环境中的 IT 治理

治理涵盖安全和生产力运营的协调，其目的是确保公司实现业务目标。 正在迁移到云端的客户可能处于实现治理的各个阶段。 每个阶段都有自己的挑战。 在这篇博文中（系列中的第一篇文章），我将讨论四步走的方法来自动化 AWS 服务的治理。

治理和 DevOps 环境

具有 DevOps 和敏捷思维的开发人员负责构建和运营服务。他们经常依靠中央安全小组制定和实施安全策略，寻求安全审查和批准，或实施最佳实践。

这些安全策略和规则并没有得到安全小组的严格执行。它们被视为开发人员为获得更多的使用 AWS 的灵活性而遵循的准则。然而，由于时间限制或重视度不足，开发人员可能并不总是遵循最佳实践和标准。如果这些最佳实践和规则得到严格执行，安全小组就可能成为瓶颈。

对于迁移到 AWS 的客户，这篇博文中描述的自动化治理机制将为开发人员保留灵活性，同时为安全团队提供控制。

在动态开发环境中，以下是一些常见的挑战：

• 通过捷径完成任务，例如将安全凭证硬编码在代码中。

• 成本管理，例如控制启动的实例的类型。

• 知识传递。

• 手动流程。

治理步骤

四步走的自动化治理方法：

在治理开始的时候，你需要实施一些（1）高风险操作的控制。在控制就绪后，你需要（2）监控你的环境，以确保你正确地配置了资源。监控将帮助你发现想要（3）尽快修复的问题。你还将需要定期地生成一份（4）审核报告，以展示所有内容都符合要求。

这篇博文中的例子协助阐明了四步走的自动化治理方法：中央 IT 团队允许其 Big Data 团队运行一个基于Amazon EMR集群的测试环境。该团队在 100 个 t2.medium 实例运行 EMR 任务，但是当一个团队成员使用 100 个 r3.8xlarge 实例来更快地完成任务时，业务会产生意外的费用。

中央 IT 团队关心治理，采取一些措施来防止这种情况再次发生：

• 控制要素：团队使用CloudFormation来限制实例的数量和类型，并使用AWS身份和访问管理来允许只有某个组可以修改 EMR 集群。

• 监控要素：团队使用 AWS 标记，AWS Config和AWS Trusted Advisor来监控 EMR 实例限制，并确定是否有人超额使用了被允许的实例数。

• 修复：团队创建一个自定义的 AWS Config 规则来终止那些不是指定类型的 EMR 实例。

• 审核：团队在 AWS Config 中审查 EMR 实例的生命周期。

控制

你可以通过标准化配置（通过 AWS CloudFormation），限制配置的选项（通过AWS服务目录）和控制权限（通过 IAM）来防范错误。

AWS CloudFormation 可以帮助你在单个软件包中控制工作流环境。 在这个示例中，我们使用 CloudFormation 模板来限制实例的数量和类型，使用 AWS 标记来控制环境。

例如，团队可以通过使用限制了实例类型和数量的 CloudFormation 来阻止选择 r3.8xlarge 实例类型的选用。

CloudForamtion 模板示例

包含标记的 EMR 集群

Java

{“Type” : “AWS::EMR::Cluster”,“Properties” : {“AdditionalInfo” : JSON object,“Applications” : [ Applications, … ],“BootstrapActions” [ Bootstrap Actions, … ],“Configurations” : [ Configurations, … ],“Instances” : JobFlowInstancesConfig,“JobFlowRole” : String,“LogUri” : String,“Name” : String,“ReleaseLabel” : String,“ServiceRole” : String,“Tags” : [ Resource Tag, … ],“VisibleToAllUsers” : Boolean}}

在 AWS 中AWS Service Catalog可用于分配经批准的产品（服务器，数据库，网站）。 这为 IT 管理员在哪些用户可以访问哪些产品的方面，提供了更多的灵活性。 AWS Service Catalog 还使他们有能力根据业务标准执行合规性。

AWS IAM 用于控制哪些用户可以访问哪些 AWS 服务和资源。 通过使用IAM角色，你可以避免在代码中使用 root 凭证来访问 AWS 资源。

在这个示例中，我们给予团队领导者完全的 EMR 访问包括控制台和 API 访问（不在此处介绍），并为开发者提供只读访问并且不提供控制台访问权限。 如果开发者想要运行这个任务，开发者只需要 PEM 文件。

IAM 策略

以下策略使团队领导者拥有的完全的 EMR 访问：

Java

{“Version”: “2012-10-17”,“Statement”: [{“Effect”: “Allow”,“Action”: [“cloudwatch:*”,“cloudformation:CreateStack”,“cloudformation:DescribeStackEvents”,“ec2:AuthorizeSecurityGroupIngress”,“ec2:AuthorizeSecurityGroupEgress”,“ec2:CancelSpotInstanceRequests”,“ec2:CreateRoute”,“ec2:CreateSecurityGroup”,“ec2:CreateTags”,“ec2:DeleteRoute”,“ec2:DeleteTags”,“ec2:DeleteSecurityGroup”,“ec2:DescribeAvailabilityZones”,“ec2:DescribeAccountAttributes”,“ec2:DescribeInstances”,“ec2:DescribeKeyPairs”,“ec2:DescribeRouteTables”,“ec2:DescribeSecurityGroups”,“ec2:DescribeSpotInstanceRequests”,“ec2:DescribeSpotPriceHistory”,“ec2:DescribeSubnets”,“ec2:DescribeVpcAttribute”,“ec2:DescribeVpcs”,“ec2:DescribeRouteTables”,“ec2:DescribeNetworkAcls”,“ec2:CreateVpcEndpoint”,“ec2:ModifyImageAttribute”,“ec2:ModifyInstanceAttribute”,“ec2:RequestSpotInstances”,“ec2:RevokeSecurityGroupEgress”,“ec2:RunInstances”,“ec2:TerminateInstances”,“elasticmapreduce:*”,“iam:GetPolicy”,“iam:GetPolicyVersion”,“iam:ListRoles”,“iam:PassRole”,“kms:List*”,“s3:*”,“sdb:*”,“support:CreateCase”,“support:DescribeServices”,“support:DescribeSeverityLevels”],“Resource”: “*”}]}

以下策略使开发人员拥有只读访问：

Java

{
“Version”: “2012-10-17”,“Statement”: [{“Effect”: “Allow”,“Action”: [“elasticmapreduce:Describe*”,“elasticmapreduce:List*”,“s3:GetObject”,“s3:ListAllMyBuckets”,“s3:ListBucket”,“sdb:Select”,“cloudwatch:GetMetricStatistics”],“Resource”: “*”}]}

这些是IAM管理的策略。如果要更改权限，你可以创建自己的IAM自定义策略。

监测

尽可能使用AWS CloudTrail，Amazon Cloudwatch，Amazon VPC，Amazon S3和Elastic Load Balancing提供的日志。 你可以使用 AWS Config，Trusted Advisor 和 CloudWatch 的事件和警报来监控这些日志。

AWS CloudTrail 可用于在 AWS 中记录 API 调用。 它可以帮助你解决问题，确保你的环境安全，并生成审核报告。 例如，您可以使用 CloudTrail 日志来识别谁启动了那些 r3.8xlarge 实例。

AWS Config 可用于跟踪和执行规则，这些规则检查你的 AWS 资源的配置是否符合要求。你还可以根据你配置的规则一目了然地了解你的环境的合规性情况。

Amazon CloudWatch 可用于对配置不正确的资源进行监控和报警。 CloudWatch 的实体，包括监控指标，警报，日志和事件可帮助你监视 AWS 资源。使用监控指标（包括自定义的监控指标），你可以监控资源并获取可自定制的小控件的仪表板。 Cloudwatch 日志可以用于从 AWS 提供的日志和你的系统日志中传输数据，这有助于问题修复和审核。

CloudWatch 事件可以帮助你针对变更采取行动。 VPC 流日志，S3 和 ELB 日志为你提供数据，以便你在修复问题或优化环境时做出更明智的决定。

AWS Trusted Advisor 分析你的 AWS 环境，并提供四个方面的最佳实践建议：成本，性能，安全性和容错能力。这个在线资源优化工具还包括有关 AWS 资源限制的警告。

我们将使用 Trusted Advisor 来确保这种资源限制不会成为启动 100 个实例的瓶颈：

问题修复

根据违规情况以及监控和展现资源配置的能力，你可能想要在发现配置不正确的资源导致安全性冲突时采取行动。 重要的是修复问题不会导致没有预期的后果，并且为你的执行的操作维护可审计的记录。

你可以使用AWS Lambda自动化一切。 当你使用 Lambda 与Amazon Cloudwatch 事件来修复问题时，你可以采取终止实例行动或者将新实例添加到 Auto Scaling 。你可以针对任何 AWS API 调用采取行动。 你还可以使用 AWS Config 托管规则和自定义规则进行问题修复。 在根据 AWS Config 规则获取有关环境的信息时，你可以使用 AWS Lambda 针对这些规则执行操作。 这有助于自动化的问题修复。

AWS Config 查找运行中实例的类型

要解决我们示例中的问题，你可以实现AWS Config的自定义规则和触发器（例如，如果实例的类型大于.xlarge 或被拆除出 EMR 群集，则该实例会被关机）。

审计

你做为审计员，将会希望在年底或季度末准备一份审计报告。你可以使用 AWS Config 资源自动化你的报表系统。

你可以查看 AWS资源配置和历史记录，以便查看 r3.8xlarge 实例集群何时启动或者应用了哪个安全组。 你甚至可以搜索哪些被终止的实例。

AWS Config 资源

更多控制，监测和问题修复的示例

来自 AWS 专业服务团队的 Armando Leite 创建了一个利用 Cloudwatch Events 和 AWS Lambda 的治理框架示例来强制执行一组控件（无操作系统 root 的访问，无远程登录）。 当违规被注意到（监测）时，自动化措施会被采取来响应事件，并在必要时恢复到之前的良好状态（问题修复）。

• 通过 AWS Config 的自定义规则或 AWS CloudWatch 事件去触发工作流，来进行修复（例如，关闭实例）

• 监视用户的操作系统活动。 随着事件的发展，新的 Lambda 功能动态地启用更多的日志和订阅日志数据以实现进一步的实时分析。

• 如果监测的结果是适合，将系统恢复到之前的良好状态。

译者

殷实，AWS 专业服务咨询顾问，专注于企业客户在 AWS 上的运维和 DevOps 的评估，架构，设计和实施。

本文转载自 AWS 技术博客。

原文链接：

https://amazonaws-china.com/cn/blogs/china/it-governance-in-a-dynamic-devops-environment/