Category: 管理工具


使用“运行命令”管理一组实例

Emily Freebairn,亚马逊AWS软件开发工程师

翻译 Ye Zhou | 原文链接

通常,工程师希望在一组实例中执行操作任务。 但是,这些任务中的许多任务需要以受控的速度进行,并在出现问题时获得反馈。 此外,管理员还通常希望确保工程师只能执行指定的操作。

运行命令”是Amazon EC2系统管理器(SSM)的一部分,旨在让您远程和安全地管理实例。 “运行命令”提供了一种简单的方法来自动执行常见的管理任务,如运行shell脚本、安装软件或修补程序等等。 “运行命令”允许您在多个实例上执行命令,并提供对结果的可见性。通过与AWS身份和访问管理(IAM)的集成,您可以精确控制用户可以在实例上执行的操作权限。 “运行命令”执行的所有操作均由AWS CloudTrail记录,允许您审核对系统的更改。

在本文中,演示了如何执行命令来收集实例的诊断信息。 由于系统容量是按需添加,系统的容量会随时变化。为了减少实例出现意外的可能性,命令可以以受控的速度运行。 如果出现失败,您将收到通知以进行事后分析。 要确保您不会意外运行其他命令,请使用具有锁定权限的自定义操作来执行指定任务。

演练

在本节中,我将向您展示如何使用Auto Scaling设置实例,创建自定义SSM文档,然后在Auto Scaling组中的所有实例上运行命令。 同时展示了如何设置Amazon CloudWatch事件,以便在遇到问题时收到通知。

步骤1:使用Auto Scaling组启动实例

要使用“运行命令”,实例需要以下内容:

SSM代理与“运行命令”服务通信以接收命令并发送输出,并使用IAM角色授予调用服务的权限。

对于这篇文章,使用Auto Scaling组来创建一组正确配置的实例。 有关分步说明,请参阅Auto Scaling入门

这里是一个使用了五个实例的Auto Scaling组的示例。

步骤2:创建自定义文档

“运行命令”使用文档来指定要在实例上执行的操作。文档是由JSON定义的AWS资源,它们包括您指定的步骤和参数。

AWS提供了一组执行常见任务的文档,例如运行shell脚本,配置CloudWatch,安装应用程序等。 此外,您可以为自己的文档编写特定任务。 因为IAM策略允许您控制用户被授权使用哪些文档,因此可以通过将一个指定用户限制到某个文档子集来锁定该用户可以执行的操作。

这里是一个文档的例子,它找出最消耗内存的进程。

{
    "schemaVersion": "2.0",
    "description": "Instance Diagnostics",
    "parameters": { },
    "mainSteps": [
        {
            "action": "aws:runShellScript",
            "name": "collectInformation",
            "inputs": {
                "runCommand": [ "ps aux --sort '%mem' | head -5" ]
            }
        }
    ]
}

要创建自定义文档,请使用创建文档SSM API。

aws ssm create-document --name InstanceDiagnostics --content file://~/workspace/document.json --document-type Command
{
    "DocumentDescription": {
        "Status": "Creating", 
        "Hash": "92182f1392807f23556ecc3f9e1d950a575dce8e2a4b96d284b1b2fb93369db2", 
        "Name": "InstanceDiagnostics", 
        "Parameters": [], 
        "DocumentType": "Command", 
        "PlatformTypes": [
            "Linux"
        ], 
        "DocumentVersion": "1", 
        "HashType": "Sha256", 
        "CreatedDate": 1492636792.396, 
        "Owner": "040557870006", 
        "SchemaVersion": "2.0", 
        "DefaultVersion": "1", 
        "LatestVersion": "1", 
        "Description": "Instance diagnostics example."
    }
}

步骤3:设置CloudWatch事件

去年,我们在“运行命令”中添加了对命令状态更改的通知的支持。 设置CloudWatch事件通知时,您可以决定在每个实例或每个命令的基础上触发事件,并指定通知的状态。使用此功能,您可以选择在命令完成时收到通知,以进行必要的后续操作。

设置CloudWatch事件通知,以通过Amazon SNS通知并在命令完成时收到电子邮件。 首先创建一个在触发时发送电子邮件的SNS主题。

接下来,创建CloudWatch事件规则以在命令完成执行时触发SNS主题。

步骤4:测试一个实例上的命令

在将命令发送到整个实例组之前,请确保它按预期工作。

首先,检查测试实例是否正确设置并通过使用DescribeInstanceInformation API连接到该服务。 这将返回有关代理的状态、代理运行的平台以及其他实例信息。

aws ssm describe-instance-information --filters "Key=InstanceIds,Values=i-01222ecf7db201ca2"
{
    "InstanceInformationList": [
        {
            "IsLatestVersion": false, 
            "ComputerName": "ip-172-31-24-177.us-west-1.compute.internal", 
            "PingStatus": "Online", 
            "InstanceId": "i-01222ecf7db201ca2", 
            "IPAddress": "172.31.24.177", 
            "ResourceType": "EC2Instance", 
            "AgentVersion": "2.0.755.0", 
            "PlatformVersion": "2017.03", 
            "PlatformName": "Amazon Linux AMI", 
            "PlatformType": "Linux", 
            "LastPingDateTime": 1492637593.888
        }
    ]
}

接下来,使用先前创建的文档向上述实例发送命令

aws ssm send-command --document-name "InstanceDiagnostics" --instance-ids "i-01222ecf7db201ca2" 
{
    "Command": {
        "Comment": "", 
        "Status": "Pending", 
        "MaxErrors": "0", 
        "Parameters": {}, 
        "ExpiresAfter": 1492645288.475, 
        "ServiceRole": "", 
        "DocumentName": "InstanceDiagnostics", 
        "TargetCount": 1, 
        "OutputS3BucketName": "", 
        "NotificationConfig": {
            "NotificationArn": "", 
            "NotificationEvents": [], 
            "NotificationType": ""
        }, 
        "CompletedCount": 0, 
        "Targets": [], 
        "StatusDetails": "Pending", 
        "ErrorCount": 0, 
        "OutputS3KeyPrefix": "", 
        "RequestedDateTime": 1492638088.475, 
        "CommandId": "11cf0866-fdec-43a4-987b-b7a5f8ad60e9", 
        "InstanceIds": [
            "i-01222ecf7db201ca2"
        ], 
        "MaxConcurrency": "50"
    }
}

最后,检查以确保命令成功完成。

aws ssm list-commands --command-id 11cf0866-fdec-43a4-987b-b7a5f8ad60e9
{
    "Commands": [
        {
            "Comment": "", 
            "Status": "Success", 
            "MaxErrors": "0", 
            "Parameters": {}, 
            "ExpiresAfter": 1492645288.475, 
            "ServiceRole": "", 
            "DocumentName": "InstanceDiagnostics", 
            "TargetCount": 1, 
            "OutputS3BucketName": "", 
            "NotificationConfig": {
                "NotificationArn": "", 
                "NotificationEvents": [], 
                "NotificationType": ""
            }, 
            "CompletedCount": 1, 
            "Targets": [], 
            "StatusDetails": "Success", 
            "ErrorCount": 0, 
            "OutputS3KeyPrefix": "", 
            "RequestedDateTime": 1492638088.475, 
            "CommandId": "11cf0866-fdec-43a4-987b-b7a5f8ad60e9", 
            "InstanceIds": [
                "i-01222ecf7db201ca2"
            ], 
            "MaxConcurrency": "50"
        }
    ]
}

步骤4:用速度控制“命令运行”

现在,您可以将命令发送到您的一组实例。

“运行命令”公开了两个新概念,用于帮助您控制发送命令的速率。 您可以通过使用max-concurrency参数来控制多少个实例同时执行该命令。 您可以指定绝对的实例数,如10,或百分比,如50%。 系统将逐步创建更多的调用(命令和实例ID配对),直到达到最大并发限制,此时它将在创建下一个调用之前等待每个当前调用完成。

第二个参数max-errors允许您指定在“运行命令”停止向其他实例发送命令之前允许的错误数。 像最大并发一样,最大错误可以指定为绝对数或百分比。

向所创建的Auto Scaling组中的所有实例发送命令,举个例子,我们指定max-concurrency为40%、max-errors为100%。 您可以使用自动生成的Auto Scaling组标签,无需任何其他工作。 通过将max-concurrency设置为40%,您可以确保命令不会同时发送到所有实例。 将max-errors设置为100%将确保所有实例都运行命令,即使某些命令调用不成功。

因为您已设置CloudWatch事件通知,所以在命令完成时将会收到通知。 “运行命令”API的输出限制为1200个字符,因此指定一个S3的位置以确保捕获完整的输出。

aws ssm send-command --document-name "InstanceDiagnostics" --target "Key=tag:aws:autoscaling:groupName,Values=RunCommandASG" --max-concurrency 40% --max-errors 100% --output-s3-bucket-name "run-command-blog" --output-s3-key-prefix "diagnostics"
{
    "Command": {
        "Comment": "", 
        "Status": "Pending", 
        "MaxErrors": "100%", 
        "Parameters": {}, 
        "ExpiresAfter": 1492647224.49, 
        "ServiceRole": "", 
        "DocumentName": "InstanceDiagnostics", 
        "TargetCount": 0, 
        "OutputS3BucketName": "run-command-blog", 
        "NotificationConfig": {
            "NotificationArn": "", 
            "NotificationEvents": [], 
            "NotificationType": ""
        }, 
        "CompletedCount": 0, 
        "Targets": [
            {
                "Values": [
                    "RunCommandASG"
                ], 
                "Key": "tag:aws:autoscaling:groupName"
            }
        ], 
        "StatusDetails": "Pending", 
        "ErrorCount": 0, 
        "OutputS3KeyPrefix": "diagnostics", 
        "RequestedDateTime": 1492640024.49, 
        "CommandId": "666b0ea2-0004-4352-bddc-ac212e0e4090", 
        "InstanceIds": [], 
        "MaxConcurrency": "40%"
    }
}

步骤5:验证命令结果

当命令完成后,您将收到一封电子邮件中的SNS通知。

{
    "version": "0",
    "id": "8bb24048-9af4-4f88-a70d-47feba9da26c",
    "detail-type": "EC2 Command Status-change Notification",
    "source": "aws.ssm",
    "account": "040557870006",
    "time": "2017-04-19T22:38:19Z",
    "region": "us-west-1",
    "resources": [
        
    ],
    "detail": {
        "command-id": "666b0ea2-0004-4352-bddc-ac212e0e4090",
        "document-name": "InstanceDiagnostics",
        "requested-date-time": "2017-04-19T22:38:16.105Z",
        "expire-after": "2017-04-20T00:38:16.105Z",
        "output-s3bucket-name": "run-command-blog",
        "output-s3key-prefix": "diagnostics",
        "parameters": "",
        "status": "Success"
    }
}

使用ListCommands API来检查总体的命令状态。 这里会返回一些信息,例如命令的状态、有多少个实例被定位(TargetCount)以及完成了多少个调用(CompletedCount)。

aws ssm list-commands --command-id 666b0ea2-0004-4352-bddc-ac212e0e4090 
{
    "Commands": [
        {
            "Comment": "", 
            "Status": "Success", 
            "MaxErrors": "100%", 
            "Parameters": {}, 
            "ExpiresAfter": 1492647224.49, 
            "ServiceRole": "", 
            "DocumentName": "InstanceDiagnostics", 
            "TargetCount": 5, 
            "OutputS3BucketName": "run-command-blog", 
            "NotificationConfig": {
                "NotificationArn": "", 
                "NotificationEvents": [], 
                "NotificationType": ""
            }, 
            "CompletedCount": 5, 
            "Targets": [
                {
                    "Values": [
                        "RunCommandASG"
                    ], 
                    "Key": "tag:aws:autoscaling:groupName"
                }
            ], 
            "StatusDetails": "Success", 
            "ErrorCount": 0, 
            "OutputS3KeyPrefix": "diagnostics", 
            "RequestedDateTime": 1492640024.49, 
            "CommandId": "666b0ea2-0004-4352-bddc-ac212e0e4090", 
            "InstanceIds": [], 
            "MaxConcurrency": "40%"
        }
    ]
}

现在,您需要从指定实例收集的诊断信息。 使用GetCommandInvocation API。 这里会返回命令的输出,包括有关命令执行的更多详细信息,如开始执行时间以及执行了多久。

aws ssm get-command-invocation --command-id 666b0ea2-0004-4352-bddc-ac212e0e4090 --instance-id i-01222ecf7db201ca2
{
    "Comment": "", 
    "ExecutionElapsedTime": "PT0.004S", 
    "ExecutionEndDateTime": "2017-04-19T22:13:47.122Z", 
    "StandardErrorContent": "", 
    "InstanceId": "i-01222ecf7db201ca2", 
    "StandardErrorUrl": "https://s3-us-west-1.amazonaws.com/run-command-blog/diagnostics/666b0ea2-0004-4352-bddc-ac212e0e4090/i-01222ecf7db201ca2/awsrunShellScript/0.diagnose/stderr", 
    "DocumentName": "InstanceDiagnostics", 
    "StandardOutputContent": "eth0      Link encap:Ethernet  HWaddr 02:9B:C5:26:4B:00  \n          inet addr:172.31.24.177  Bcast:172.31.31.255  Mask:255.255.240.0\n          inet6 addr: fe80::9b:c5ff:fe26:4b00/64 Scope:Link\n          UP BROADCAST RUNNING MULTICAST  MTU:9001  Metric:1\n          RX packets:9905 errors:0 dropped:0 overruns:0 frame:0\n          TX packets:3260 errors:0 dropped:0 overruns:0 carrier:0\n          collisions:0 txqueuelen:1000 \n          RX bytes:11135049 (10.6 MiB)  TX bytes:514905 (502.8 KiB)\n\nlo        Link encap:Local Loopback  \n          inet addr:127.0.0.1  Mask:255.0.0.0\n          inet6 addr: ::1/128 Scope:Host\n          UP LOOPBACK RUNNING  MTU:65536  Metric:1\n          RX packets:2 errors:0 dropped:0 overruns:0 frame:0\n          TX packets:2 errors:0 dropped:0 overruns:0 carrier:0\n          collisions:0 txqueuelen:1 \n          RX bytes:140 (140.0 b)  TX bytes:140 (140.0 b)\n\n", 
    "Status": "Success", 
    "StatusDetails": "Success", 
    "PluginName": "diagnose", 
    "ResponseCode": 0, 
    "ExecutionStartDateTime": "2017-04-19T22:13:47.122Z", 
    "CommandId": "666b0ea2-0004-4352-bddc-ac212e0e4090", 
    "StandardOutputUrl": "https://s3-us-west-1.amazonaws.com/run-command-blog/diagnostics/666b0ea2-0004-4352-bddc-ac212e0e4090/i-01222ecf7db201ca2/awsrunShellScript/0.diagnose/stdout"

最后,因为你设置了一个S3存储桶,所有的命令调用的输出结束将保存在你指定的 S3的位置。

结论

在本文中,展示了如何使用“运行命令”以及其他AWS服务来对一组实例执行管理操作。“运行命令”提供了一种简单且可扩展的方式来管理您的实例。 您可以控制发送命令的速率,使用细粒度的权限,并使用通知来简化工作流程。

关于作者

Emily Freebairn是亚马逊EC2系统管理团队的软件开发工程师。 她已经在亚马逊工作了四年,从事Amazon EC2和系统管理器的“运行命令”和其他功能。 在工作之余,她喜欢帆船和跳舞。

使用 AWS CloudFormation StackSets 跨多个 AWS 账户和区域配置资源

AWS CloudFormation 可帮助 AWS 客户实施基础设施即代码模型。客户现在无需手动设置自己的环境和应用程序,他们可以生成一个模板,然后使用它来创建所有必需的资源 (统称为 CloudFormation 堆栈)。此模型彻底消除了人工错误的可能,提高了效率,能够确保始终一致的配置。

今天,我准备为大家介绍一个让 CloudFormation 变得更加有用的新功能。此功能可帮助您应对在包含多个 AWS 账户和/或 AWS 区域的情况下使用基础架构即代码时的挑战。快速回顾:

账户 – 正如前面提到的那样,很多组织使用大量的 AWS 账户,通常用 AWS Organizations 将这些账户组织为分层结构,分组为不同的组织部门 (OU) (阅读 AWS Organizations – 基于策略的多 AWS 账户管理了解更多信息)。我们的客户使用多个账户满足业务部门、应用程序和开发人员所需。他们通常为每一个应用程序的开发、测试、生产前调试及生产阶段创建不同的账户。

区域 – 客户也可以充分利用数量众多 (一直在增长) 的 AWS 区域。他们构建跨越两个或更多区域的全球应用程序,实施精巧的多区域灾难恢复模型,实时复制 S3AuroraPostgreSQLMySQL 数据,为依据国家和地区法规存储和处理敏感数据选择位置。

多账户和多区域的扩展对管理和一致性带来了新的挑战。客户告诉我们,他们希望确保每一个新账户都按照其内部标准进行设置。首先他们需要一致、可靠地设置 IAM 用户和角色、VPC 和 VPC 子网、安全组、配置规则、日志记录和 AWS Lambda 函数。

介绍 StackSet
为了满足这些重要的客户需求,我们今天推出 CloudFormation StackSet。现在通过几次单击操作,即可在 CloudFormation 模板中定义 AWS 资源配置,然后跨多个 AWS 账户和/或区域进行部署。您可以用它来设置 AWS 功能的基准水平,以满足上述跨账户和跨区域情形的需要。设置之后,可将覆盖范围轻松扩展到更多的账户和区域。

该功能始终只适用于多账户情形。管理员账户 拥有一个或多个 StackSet,用于控制对一个或多个目标账户 的部署。管理员账户必须包含一个可担任的 IAM 角色,目标账户必须信任管理员账户。要了解具体的操作方法,请阅读 StackSet 文档中的先决条件

每个 StackSet 都引用一个 CloudFormation 模板,它包含一系列账户和区域。所有操作都适用于 StackSet 中账户和区域的叉积。如果 StackSet 引用三个账户 (A1、A2 和 A3) 和四个区域 (R1、R2、R3 和 R4),则有 12 个目标:

  • 区域 R1:账户 A1、A2 和 A3。
  • 区域 R2:账户 A1、A2 和 A3。
  • 区域 R3:账户 A1、A2 和 A3。
  • 区域 R4:账户 A1、A2 和 A3。

部署模板按账户/区域对启动 CloudFormation 堆栈的创建。模板按顺序部署到区域 (您控制顺序),再部署到区域中的多个账户 (您控制并行量)。您可以设置错误阈值,以便在堆栈创建失败时终止部署。

您可以使用现有 CloudFormation 模板 (注意确保它们已准备好跨账户和区域工作)、创建新模板,或使用我们提供的示例模板。我们还要发布对 AWS 分区 (除了中国的几个区域外的其他所有公共区域) 的支持,希望不久将扩展到其他区域。

使用 StackSet
您可以从 CloudFormation 控制台、通过 CloudFormation API 或使用命令行创建和部署 StackSet。

如果使用控制台,首先单击 Create StackSet。我可以使用自己的模板,也可以使用一个示例模板。我使用最后一个示例 (添加配置规则加密卷):

单击 View template 了解模板及规则:

为 StackSet 提供名称。我选择的模板接受可选参数,可以现在输入:

接下来,选择账户和区域。我可以直接输入账号,引用 AWS 组织单元或上传一组账号:

我可以设置区域并控制部署顺序:

我还可以设置部署选项。完成后,单击 Next 继续:

我可以向 StackSet 添加标签。它们将应用于部署期间创建的 AWS 资源:

部署开始,我可以从控制台中跟踪状态:

我可以打开“Stacks”部分查看每个堆栈。开始时,每个堆栈的状态都是 OUTDATED,这表明模板尚未部署到堆栈;成功部署后,状态变为 CURRENT。如果无法删除某个堆栈,其状态将变为 INOPERABLE

初始部署完成后,可以单击 Manage StackSet 添加更多账户和/或区域来创建更多堆栈:

现在提供
这项新功能现已推出,您可以立即开始使用,无需额外费用 (只为您自己创建的 AWS 资源付费)。

Jeff

另外,如果您创建了一些有用的模板,愿与其他 AWS 用户分享,请向我们的 AWS 实验室 GitHub 存储库发送提交请求。

全新 – Amazon CloudWatch 高精度自定义指标和警报

Amazon CloudWatch 自 2009 年年初以来一直是 AWS 的重要组成部分。CloudWatch 与 Auto ScalingElastic Load Balancing 三个产品包组合在一起发布,它已发展成为功能极强、面向 AWS 云中运行的 AWS 资源和应用程序的监控服务。CloudWatch 自定义指标 (早在 2011 年发布) 可用在 CloudWatch 中存储业务和应用程序指标、以图形方式查看这些指标,并基于 CloudWatch 警报启动操作。不用说,这些年来,我们的 CloudWatch 增强了很多的功能!最近的一些增强功能包括延长指标保留期 (以及一项用户界面更新)、控制面板控制面板 API/CloudFormation 支持以及控制面板上的警报

一开始,指标是按照五分钟的时间间隔存储的;后来,在 2010 年,应客户请求缩短到一分钟 (也称为详细监控)。这是一个广受欢迎的改变,但现在我们可以做得更好。我们的客户在流式传输视频、开展限时抢购、每天上百次部署代码,并随着情况的变化非常快速地扩展和缩减应用程序。对于所有这些情况,一分钟为时间间隔还是太长了。这样有可能错过重要的瞬间高峰;分散 (然而事实上相关) 的事件难以跨越时间进行关联,并且在发生故障时的 MTTR (平均修复时间) 过高。

全新的高精度指标
今天,我们将增加对高精度自定义指标的支持,我们还计划以后逐渐增加对 AWS 服务的支持。现在您的应用程序可以以 1 秒的精度将指标发布到 CloudWatch。在发布指标数秒后您就可以在屏幕上滚动查看这些指标,您还可以设置高精度 CloudWatch 警报,可以精细到每 10 秒评估一次。

想象一下可用内存较少时发出警报。这通常是一种瞬时的情况,如果取样不够频繁,将很难捕获到。使用高精度指标,您可以在数秒内查看、检测 (通过警报) 到这种情况并相应地执行操作。

在此例中,右侧的警报不会触发,您也不会知道出现了问题。

发布高精度指标
您可以用两种不同的方式发布高精度指标:

  • APIPutMetricData 函数现在接受可选 StorageResolution 参数。将此参数设置为 1 可发布高精度指标;省略它 (或设置为 60) 可按照标准的 1 分钟精度发布指标。
  • collectd 插件 – collectd 的 CloudWatch 插件已更新,现在支持高精度指标的收集和发布。您需要在该插件的配置文件中设置 enable_high_definition_metrics 参数。

CloudWatch 指标随时间累积;随着指标存在时间变长,精度将大大降低。下面是时间设置:

  • 1 秒指标可用 3 小时。
  • 60 秒指标可用 15 天。
  • 5 分钟指标可用 63 天。
  • 1 小时指标可用 455 天 (15 个月)。

当您调用 GetMetricStatistics 时,可以指定 1、5、10、30 或 60 秒的任意倍数作为高精度指标。您可以指定 60 秒的任意倍数作为标准指标。

快速演示
我选用我最近的 EC2 实例,它安装了最新版本的 collectd 和 Python 插件:

$ sudo yum install collectd collectd-python

然后我下载该插件的设置脚本,让它变成可执行文件,然后运行:

$ wget https://raw.githubusercontent.com/awslabs/collectd-cloudwatch/master/src/setup.py
$ chmod a+x setup.py
$ sudo ./setup.py

我已创建一个合适的 IAM 角色,并将它添加到我的实例中;在设置过程中自动检测到了它。有人要求我启用高精度指标:

collectd 在数秒内开始运行并发布指标。我打开 CloudWatch 控制台查看:

然后我放大,详细查看指标:

我还以 10 秒的时间间隔创建一个警报来检查 memory.percent.used 指标。这样我可以更方便地检测短时间内使用很多内存的情况:

现在提供
现在,高精度自定义指标和警报在所有公共 AWS 区域都可用,并且很快还会支持 AWS GovCloud (US)

目前您每个月可以免费存储 10 个指标;有关更多信息,请参阅 CloudWatch 定价页面。高精度指标的定价与标准精度指标相同,如果需要使用更多指标,用量套餐可以为您节省费用 (对于每个指标)。高精度警报价格为每月每个警报 0.30 美元。

新功能- Collectd的Amazon CloudWatch插件

原文:https://aws.amazon.com/blogs/aws/new-cloudwatch-plugin-for-collectd/

作者:Jeff Barr


我在2011年已介绍过Cloud Watch的特性,“您可以在Cloud Watch中查看图表、设置告警、并根据这些指标启动自动化操作,所使用的这些AWS资源指标会被存储于Cloud Watch中 。”您目前已有能力在Amazon Cloud Watch中存储一段时间范围内的业务、应用及系统的指标数据(参阅“Amazon Cloud Watch定制新指标”了解更多信息)。

今天我们将简化系统统计信息的采集过程,使用一个新的 CloudWatch plug for colletd将采集数据发送至CloudWatch中 。并通过collectd 多种类型信息的统计采集能力与cloudwatch存储、展示、警报和告警的功能的整合,您可以更好地获取EC2实例、本地硬件以及运行于其上应用程序的运行状态及其性能信息。该插件已经作为一个开源项目发布,我们期待您的反馈。

Collectd守护进程采用C语言编写,具有高性能和可移植性。它支持上百个插件 ,允许您收集有关ApacheNginx Web服务器性能统计数据、memory usage uptime等信息。

安装与配置

为了演示这些功能,我在EC2实例上安装并配置了Collectd服务及新Cloudwatch插件。

首先我创建了一条IAM策略,它具备将指标数据写入CloudWatch的权限:

然后我创建了一个IAM角色,允许EC2(运行collectd程序的实例)使用上述所建的策略:

如果我计划使用Collectd 插件从本地服务器或运行中的EC2实例收集统计信息,那请跳过这些步骤,采用创建一个具有适当权限的IAM用户作为替代方法。在我完成上述工作后,会将该用户的证书放在本地服务器或EC2实例中。

在策略和角色配置完毕后,选择该角色来启动一个EC2实例

登录并安装Collectd :

$ sudo yum -y install collectd

然后获取插件和安装脚本,设置脚本为可执行,并运行该脚本:

$ chmod a+x setup.py

$ sudo ./setup.py

回答一些交互问题确认安装过程无误,在完成配置之后就可启动Collectd :

Installing dependencies ... OK

Installing python dependencies ... OK

Copying plugin tar file ... OK

Extracting plugin ... OK

Moving to collectd plugins directory ... OK

Copying CloudWatch plugin include file ... OK

Choose AWS region for published metrics:

1. Automatic [us-east-1]

2. Custom

Enter choice [1]: 1

Choose hostname for published metrics:

1. EC2 instance id [i-057d2ed2260c3e251]

2. Custom

Enter choice [1]: 1

Choose authentication method:

1. IAM Role [Collectd_PutMetricData]

2. IAM User

Enter choice [1]: 1

Choose how to install CloudWatch plugin in collectd:

1. Do not modify existing collectd configuration

2. Add plugin to the existing configuration

Enter choice [2]: 2

Plugin configuration written successfully.

Stopping collectd process ... NOT OK

Starting collectd process ... OK

$

在Collectd运行并且插件安装配置完成后,下一步是确定感兴趣的统计信息,并配置插件将它们发布至CloudWatch中(每个指标的采集成本也是一个需考虑因素)。

文件/opt/collectd-plugins/cloudwatch/config/blocked_metrics包含已收集但尚未发布到CloudWatch的指标列表:


$ cat /opt/collectd-plugins/cloudwatch/config/blocked_metrics

# This file is automatically generated - do not modify this file.

# Use this file to find metrics to be added to the whitelist file instead.

cpu-0-cpu-user

cpu-0-cpu-nice

cpu-0-cpu-system

cpu-0-cpu-idle

cpu-0-cpu-wait

cpu-0-cpu-interrupt

cpu-0-cpu-softirq

cpu-0-cpu-steal

interface-lo-if_octets-

interface-lo-if_packets-

interface-lo-if_errors-

interface-eth0-if_octets-

interface-eth0-if_packets-

interface-eth0-if_errors-

memory--memory-used

load--load-

memory--memory-buffered

memory--memory-cached

如您对内存消耗关注,可添加了一行到

/opt/collectd-plugins/cloudwatch/config/whitelist.conf

memory--memory-.*

Collectd配置文件(/etc/collectd.conf)中包含Collectd附加设置及插件设置。不需要做任何修改。

重新启动Collectd,以便所做的调整生效:

$ sudo service collectd restart

为了模拟内存消耗,可执行了一些消耗内存的程序,然后打开CloudWatch Console来查找并显示自定义指标:

该截图包括了对CloudWatch控制台即将推出增强功能的预览;如果看起来不一致也不必担心(请关注获取更多信息)。
如果监控一个生产实例,您还可以安装更多Collectd插件。以下是Amazon Linux AMI可用插件列表:

$ sudo yum list | grep collectd
collectd.x86_64                        5.4.1-1.11.amzn1               @amzn-main

collectd-amqp.x86_64                   5.4.1-1.11.amzn1               amzn-main

collectd-apache.x86_64                 5.4.1-1.11.amzn1               amzn-main

collectd-bind.x86_64                   5.4.1-1.11.amzn1               amzn-main

collectd-curl.x86_64                   5.4.1-1.11.amzn1               amzn-main

collectd-curl_xml.x86_64               5.4.1-1.11.amzn1               amzn-main

collectd-dbi.x86_64                    5.4.1-1.11.amzn1               amzn-main

collectd-dns.x86_64                    5.4.1-1.11.amzn1               amzn-main

collectd-email.x86_64                  5.4.1-1.11.amzn1               amzn-main

collectd-generic-jmx.x86_64            5.4.1-1.11.amzn1               amzn-main

collectd-gmond.x86_64                  5.4.1-1.11.amzn1               amzn-main

collectd-ipmi.x86_64                   5.4.1-1.11.amzn1               amzn-main

collectd-iptables.x86_64               5.4.1-1.11.amzn1               amzn-main

collectd-ipvs.x86_64                   5.4.1-1.11.amzn1               amzn-main

collectd-java.x86_64                   5.4.1-1.11.amzn1               amzn-main

collectd-lvm.x86_64                    5.4.1-1.11.amzn1               amzn-main

collectd-memcachec.x86_64              5.4.1-1.11.amzn1               amzn-main

collectd-mysql.x86_64                  5.4.1-1.11.amzn1               amzn-main

collectd-netlink.x86_64                5.4.1-1.11.amzn1               amzn-main

collectd-nginx.x86_64                  5.4.1-1.11.amzn1               amzn-main

collectd-notify_email.x86_64           5.4.1-1.11.amzn1               amzn-main

collectd-postgresql.x86_64             5.4.1-1.11.amzn1               amzn-main

collectd-rrdcached.x86_64              5.4.1-1.11.amzn1               amzn-main

collectd-rrdtool.x86_64                5.4.1-1.11.amzn1               amzn-main

collectd-snmp.x86_64                   5.4.1-1.11.amzn1               amzn-main

collectd-varnish.x86_64                5.4.1-1.11.amzn1               amzn-main

collectd-web.x86_64                    5.4.1-1.11.amzn1               amzn-main

需了解事项

如果您使用的是5.5或更新版本的Collectd ,则会在默认情况下发布四个指标:

  • df-root-percent_bytes-used – disk utilization
  • memory–percent-used – memory utilization
  • swap–percent-used – swap utilization
  • cpu–percent-active – cpu utilization

如果您不希望发布它们,您可以从whitelist.conf文件中删除这些指标。

在Amazon Linux AMI,Ubuntu,RHEL和CentOS的软件仓库中,目前提供了较旧版本的Collectd; 如果从源代码或自定义repo进行构建安装,请注意默认行为的变化。

更多

除了本次所展示的内容外, 您可以安装更多的插件,然后配置whitelist.conf来向CloudWatch发布更多的指标。同时您可以创建CloudWatch警报 ,自定义仪表盘等。

要开始使用,请访问AWS Lab on GitHub,并下载collectd plugin for CloudWatch

译者介绍

 

倪晓峻,AWS专业服务顾问,负责基于AWS云计算项目的咨询和设计,具有超过十五年以上企业客户服务经验,致力于AWS服务在国内和全球的项目实施。在企业级解决方案,混合云架构,运营集成等领域有着广泛的设计与实践经验。在加入AWS之前曾任职VMware;HPE专业服务顾问,从事云计算/虚拟化架构设计及运维咨询工作,两次获得省部级科技进步奖励,参与OGC ITIL V3中文版的审定工作 。

 

 

使用 Amazon EC2 Run Command 在不使用 SSH 访问的情况下大规模地管理实例

以下博文的投稿者为 Ananth Vaidyanathan (EC2 Systems Manager 高级产品经理) 和 Rich Urmston (Pegasystems 公司云架构高级总监),介绍了如何使用 EC2 Run Command 在不使用 SSH 的情况下管理大量 EC2 实例。

-Jeff


企业通常具有若干托管环境和成千上万的 Amazon EC2 实例。安全地管理系统非常重要,同时也要避免棘手的安全外壳 (SSH)。Run CommandAmazon EC2 Systems Manager 的一部分,可以让您以可控制和可审查的方式对实例 (或使用标签的实例组) 运行远程命令。这有效地提升了每天都要依赖 Run Command 服务的 Pega 云操作的效率。

您可以通过标准 IAM 角色和策略控制 Run Command 访问,定义文档以获取输入参数,控制用于返回命令输出的 S3 存储桶。您还可以与其他 AWS 账户共享文档或将文档公开。总而言之,Run Command 提供了一组很有用的远程管理功能。

优于 SSH

Run Command 优于 SSH 且 Pegasystems 已将其作为主要远程管理工具的原因如下:

Run Command 所需时间较短 – 安全地连接到一个实例需要几个步骤,例如要连接的跳转盒或要列入白名单的 IP 地址等。使用 Run Command,云操作工程师可以直接从笔记本电脑调用命令,而不必找到密钥甚至实例 ID。相反,系统安全性依赖于 AWS 身份验证、IAM 角色和策略。

Run Command 操作完全经过审查 – 使用 SSH,无法真正控制他们的操作,也没有审查跟踪。使用 Run Command,每个调用的操作都会在 CloudTrail 中进行审查,包括调用用户的信息、运行命令的实例、参数和操作状态。您拥有完全控制权,能够限制工程师可以在系统上执行的功能。

Run Command 无需管理 SSH 密钥 – Run Command 利用标准 AWS 凭证、API 密钥和 IAM 策略。通过与企业身份验证系统的集成,工程师可以根据其企业凭证和身份与系统进行交互。

Run Command 可以同时管理多个系统 – 使用 SSH 完成某些简单任务会很麻烦,如查看 Linux 服务的状态或在托管实例队列中检索日志文件。Run Command 允许您通过 ID 或标签指定实例列表,并在指定队列中并行调用命令。除非是最小的 Pega 群集,否则这会在进行故障排查或管理时提供巨大的优势。

Run Command 使自动化复杂任务更容易 – 实现操作任务标准化需要详细的程序文档或描述准确命令的脚本。在整个队列中管理或部署这些脚本会很麻烦。Run Command 文档提供了一种封装复杂功能并处理文档管理和访问控制的简单方式。当与 AWS Lambda 结合使用时,文档提供了强大的自动化平台来处理任何复杂任务。

示例 – 重新启动 Docker 容器

下面是一个用于重新启动 Docker 容器的简单文档示例。它包含一个参数,即要重新启动的 Docker 容器的名称。它使用 AWS-RunShellScript 方法调用命令。该服务自动收集输出并将输出返回调用方。有关最新文档架构的示例,请参阅创建 Systems Manager 文档

{
  "schemaVersion":"1.2",
  "description":"Restart the specified docker container.",
  "parameters":{
    "param":{
      "type":"String",
      "description":"(Required) name of the container to restart.",
      "maxChars":1024
    }
  },
  "runtimeConfig":{
    "aws:runShellScript":{
      "properties":[
        {
          "id":"0.aws:runShellScript",
          "runCommand":[
            "docker restart {{param}}"
          ]
        }
      ]
    }
  }
}

在 Pegasystems 上实际应用 Run Command

Pegasystems 配置系统位于AWS CloudFormation上,后者用于部署和更新 Pega 云资源。在此之上是 Pega Provisioning Engine,这是一个无服务器的基于 Lambda 的服务,它管理着 CloudFormation 模板和 Ansible 操作手册库。配置管理数据库 (CMDB) 跟踪每个部署和更新的所有配置详细信息和历史记录,并使用分层目录命名约定布置其数据。下图显示了不同系统的集成方式:

对于云系统管理,Pega 操作使用名为 cuttysh 的命令行版本和基于 Pega 7 平台的图形版本,名为 Pega Operations Portal。这两种工具都允许您浏览部署环境的 CMDB,查看配置设置,并通过 Run Command 与部署的 EC2 实例进行交互。

CLI 演示

下面是一个 CLI 演示,用于查看客户部署并使用 Run Command 与实例交互。启动 cuttysh 工具可以显示 CMDB 的根目录和配置客户的列表:

% cuttysh
d CUSTA
d CUSTB
d CUSTC
d CUSTD

您可以使用标准 Linux shell 命令 (例如 cdlscatgrep) 与 CMDB 进行交互。带有 s 前缀的项目表示可查看其属性的服务。带有 d 前缀的项目表示 CMDB 层次结构中可导航的子目录。在此示例中,将目录更改为 CMDB 层次结构的客户 CUSTB 部分,然后再将其更改为名为 env1 的配置 Pega 环境,位于 Dev 网络下。此工具显示了为该环境配置的项目。这些条目映射到配置的 CloudFormation 模板。

> cd CUSTB
/ROOT/CUSTB/us-east-1 > cd DEV/env1

ls –l 命令显示配置资源的版本。这些版本号映射到源代码控制 – CloudFormation、Ansible 和构成 Pega 云版本的其他组件的托管项目。

/ROOT/CUSTB/us-east-1/DEV/env1 > ls -l
s 1.2.5 RDSDatabase 
s 1.2.5 PegaAppTier 
s 7.2.1 Pega7 

现在,使用 Run Command 与部署的环境进行交互。要执行此操作,可使用 attach 命令并指定要进行交互的服务。在以下示例中,可挂载到 Pega Web Tier。使用 CMDB 和实例标签中的信息,CLI 可以找到相应的 EC2 实例,并显示有关它们的一些基本信息。此部署有三个实例。

/ROOT/CUSTB/us-east-1/DEV/env1 > attach PegaWebTier
 # ID         State  Public Ip    Private Ip  Launch Time
 0 i-0cf0e84 running 52.63.216.42 10.96.15.70 2017-01-16 
 1 i-0043c1d running 53.47.191.22 10.96.15.43 2017-01-16 
 2 i-09b879e running 55.93.118.27 10.96.15.19 2017-01-16 

在这里,您可以使用 run 命令调用 Run Command 文档。在以下示例中,您可以对实例 0 (列表中的第一个实例) 运行 docker-ps 文档。EC2 执行命令并将输出返回到 CLI,CLI 将显示输出。

/ROOT/CUSTB/us-east-1/DEV/env1 > run 0 docker-ps
. . 
CONTAINER ID IMAGE             CREATED      STATUS        NAMES
2f187cc38c1  pega-7.2         10 weeks ago  Up 8 weeks    pega-web

使用相同的命令和已定义的其他文档,您可以重新启动 Docker 容器,甚至将文件的内容撤回到本地系统。当您获得文件时,Run Command 还会在 S3 存储桶中留下一个副本,以备您希望将链接传递给同事。

/ROOT/CUSTB/us-east-1/DEV/env1 > run 0 docker-restart pega-web
..
pega-web

/ROOT/CUSTB/us-east-1/DEV/env1 > run 0 get-file /var/log/cfn-init-cmd.log
. . . . . 
get-file

Data has been copied locally to: /tmp/get-file/i-0563c9e/data
Data is also available in S3 at: s3://my-bucket/CUSTB/cuttysh/get-file/data

现在,利用 Run Command 可一次完成多个操作。在以下示例中,您挂载到具有三个正在运行的实例的部署,并希望查看每个实例的正常运行时间。将 par (并行) 选项与 run配合使用,CLI 将指示 Run Command 对所有实例并行执行正常运行时间文档。

/ROOT/CUSTB/us-east-1/DEV/env1 > run par uptime
 …
Output for: i-006bdc991385c33
 20:39:12 up 15 days, 3:54, 0 users, load average: 0.42, 0.32, 0.30

Output for: i-09390dbff062618
 20:39:12 up 15 days, 3:54, 0 users, load average: 0.08, 0.19, 0.22

Output for: i-08367d0114c94f1
 20:39:12 up 15 days, 3:54, 0 users, load average: 0.36, 0.40, 0.40

Commands are complete.
/ROOT/PEGACLOUD/CUSTB/us-east-1/PROD/prod1 > 

总结

Run Command 通过提供更快的系统访问和跨一组实例运行操作,可以提高工作效率。Pega 云操作将 Run Command 与其他操作工具集成,为管理系统提供了一种简单安全的方法。这大大提高了操作效率,并更好地控制了每个主体在托管部署可以执行的操作。Pega 持续改进过程会定期评估操作者需要访问权限的原因,并将这些操作转换为新的 Run Command 文档以添加到库中。事实上,它们的长期目标是停止在启用 SSH 时部署云系统。如果您有任何问题或建议,请给我们留言!

-Ananth 和 Rich

使用Amazon EC2 Systems Manager取代堡垒机

通常情况下,堡垒机(也称为“跳转机”)是在系统中访问私有主机的一个最佳实践。例如,您的系统可能包含一个不希望被公开访问的应用服务器,当需要在这台服务器上进行产品的更新或系统补丁程序的管理时,您通常会登录到堡垒机,然后从那里访问(即“跳转到”)应用服务器。

本文将向您介绍使用Amazon EC2 Systems Manager替换您的堡垒机,实现在服务器上运行命令的同时缩小系统攻击平面并获取更好的可见性。

堡垒机方案

堡垒机最好仅向特定的IP地址范围开放,这个地址范围通常可设定为您单位的企业网络。使用堡垒机的好处是,任何对内部服务器的访问都被限定到一种方式:通过单个或一组堡垒机。为了获取进一步的隔离,堡垒机通常被安放在单独的VPC中。

这种设计方案如下图所示:

应用服务器运行在与管理VPC对等相连的一个VPC的私有子网中。 应用服务器设定了一个安全组规则,其仅允许来自管理VPC中堡垒机所在安全组的22端口访问(本文的示例仅针对端口22和SSH访问。Windows用户可将其相应的替换为端口3389和RDP访问)。同样,堡垒机也设定了一个安全组规则,其仅允许来自公司网络IP地址空间的22端口访问。

由于应用服务器运行在私有子网中,所以它只能通过VPC公共子网中的NAT网关来建立出站公网连接。

假设您希望查看应用程序服务器的网络接口,您需要执行以下步骤:

  1. 将应用服务器的私钥安装在堡垒机上。
  2. 从可信网络(如公司网络)发起,在堡垒机上建立SSH会话。
  3. 从堡垒机发起,建立SSH会话到应用服务器。
  4. 运行“ifconfig”命令。
  5. 如需保存命令的结果,您可以复制和粘贴命令的输出,或者将输出重定向到文件。

这个方案中的安全措施限制了对应用服务器和堡垒机的访问,但堡垒机模式存在一些缺点:

  • 像任何基础设施服务器一样,堡垒机必须进行管理和维护。
  • 运行时会产生成本。
  • 允许堡垒机访问的每个安全组都需要设置一个安全组入口规则,即SSH(用于Linux)的22端口或RDP的3389端口(用于Windows服务器)。
  • 堡垒机和应用服务器的RSA密钥需要进行管理、保护和轮换。
  • SSH操作无缺省日志记录。

替代方案

Systems Manager允许您在被管理的服务器上远程执行命令,而不使用堡垒机(此功能称为EC2 Run Command)。安装于服务器上的代理程序会自动轮询Systems Manager以确定是否有命令在等待执行。

此方案具备以下优点:

  • 使用AWS托管服务,这意味着Systems Manager组件具备高可用性。
  • Systems Manager通过IAM策略设定是否允许用户或角色远程执行命令。
  • Systems Manager代理程序需要IAM角色和策略才能允许它们调用Systems Manager服务。
  • Systems Manager不可更改的记录每个执行的命令,从而提供了可审计的命令历史,包括:

 o   执行命令的内容

 o   执行命令的主体

 o   执行命令的时间

 o   命令的输出摘要

  • 当AWS CloudTrail在当前区域中启用时,CloudTrail会记录每个事件,并写入Amazon CloudWatch Logs。
  • 使用CloudTrail和CloudWatch规则,您可以将Systems Manager事件用作自动响应的触发器,例如Amazon SNS通知或AWS Lambda函数调用。
  • Systems Manager可以选择将命令历史记录和每个命令的全部输出存储在Amazon S3中。
  • Systems Manager可以选择发布消息到SNS主题,从而在命令开始执行时和完成时通知订阅者。
  • Systems Manager是基于代理程序的,这意味着它不限于管理Amazon EC2实例。它还可以管理运行在自有数据中心或者另一个云服务提供商的非AWS服务器上。
  • 无需管理SSH密钥。

Systems Manager本身没有成本,但是您需要支付Systems Manager所管理的资源(如EC2实例、SNS消息和S3存储等)的成本。

Systems Manager代理程序

Systems Manager代理是运行在被管理的服务器上的开源可执行程序,支持Linux和Windows操作系统(请参见支持的详细操作系统版本列表)。

Systems Manager代理通过IAM角色与Systems Manager进行通信。这个角色必须具有足够权限与Systems Manager及其辅助服务进行交互。IAM已经提供了一个名为AmazonEC2RoleforSSM的托管策略,为您预先定义了这些权限:允许代理程序获取并回复Systems Manager消息、发布CloudWatch指标、并将日志文件写入S3。

Systems Manager代理通过HTTPS协议与Systems Manager通信,这意味着服务器和Systems Manager服务之间的通信是被加密的,而且安全组也不需要特殊的出口规则。

理想情况下,您可以在实例引导时安装代理程序。您可以将其安装在已经运行的EC2实例或非AWS的服务器上。例如,您可以通过EC2实例的user data在系统引导时使用yum安装Systems Manager代理:

#!/bin/bash
cd /tmp
curl https://amazon-ssm-region.s3.amazonaws.com/latest/linux_amd64/amazon-ssm-agent.rpm -o amazon-ssm-agent.rpm
yum install -y amazon-ssm-agent.rpm

关于安装Systems Manager代理的更多信息,请参考以下链接:Installing SSM Agent.

优化后的系统架构

现在您已了解了Systems Manager的众多优点,下面我们看一下如何据此优化您的系统架构。

如下图所示,Systems Manager消除了系统对堡垒机的需求,从而简化了系统架构。 用户不再直接与应用服务器进行交互,Systems Manager成为了执行命令的代理。

在此设计中,Systems Manager代理程序驻留在应用服务器上,使其成为 “受管实例”——这意味着它可以从Systems Manager接收命令。 要执行一个命令,只需在Systems Manager中创建一个命令请求,并派发到该实例或一组实例上运行。

创建命令请求时,您可以选择一个用于存储命令执行结果的S3存储桶,和用于发送执行通知的SNS主题。 您还可以创建通过Systems Manager事件触发的CloudWatch事件。

操作演示

您可以使用下面的【Launch Stack】链接来启动一个AWS CloudFormation栈,后者将创建上述架构,然后运行命令并在Systems Manager控制台中查看结果。最后,您可以销毁整个CloudFormation栈。

注:该链接会在北弗吉尼亚州区域启动相关资源,并产生相应的成本。SSM 只在如下区域可应用。

1.选择Launch Stack打开CloudFormation控制台(请确保您已经使用您的AWS账户登录)并启动CloudFormation模板。选择Next。

2.对于Stack name,请使用缺省的ssm-demo或输入自定义名称。 对于通知电子邮件,请输入您的电子邮件地址,以在Systems Manager执行操作时通知您。CloudFormation模板启动后,您将收到一个订阅确认邮件,您必须确认才能收到后续的通知。选择Next 。

3.在Review 屏幕上,确认允许CloudFormation创建IAM角色。选择Create

4.要查看栈的创建进度,请选择Refresh,然后选择ssm-demo栈以查看启动过程。

5.当栈成功启动时,状态会从CREATE_IN_PROGRESS更改为CREATE_COMPLETE 。 要查看本文后面需要使用的输出值,请选择Outputs.

这个CloudFormation模板创建的资源将在本文的后面中使用。您应该看到下表中列出的值。

Output名称 示例值 用途
S3Bucket S3Bucket ssm-output-history -account-id – 区域 S3桶用于存储命令的输出
ApplicationHostInstance id-instance-id 用于执行命令的EC2实例
SnsTopicArn arn:aws:sns: region : account-id :SsmNotificationTopic 用于发送命令执行通知的SNS主题
RoleArn arn:aws:iam :: account-id :role / SsmNotificationRole- region 用于向SNS发送通知的角色

Systems Manager演示

在本节中,您将使用Systems Manager发出与上文堡垒机方案中相同的“ifconfig”命令来查看应用服务器的网络接口配置。

首先,您需要指定要在其上执行命令的实例。在Systems Manager执行命令之后,它会报告执行状态,显示输出,并将输出的历史存储在S3桶中,并向您发送一封电子邮件通知。

Systems Manager代理以root权限运行,管理员在授予用户执行Systems Manager命令的权限时应注意这一点。

要使用Systems Manager,请按照下列步骤操作:

1.登录到您的AWS帐户并跳转到EC2控制台

2.在左侧导航窗格的SYSTEMS MANAGER 下 ,选择Managed Instances

注意:如果您看到“欢迎使用EC2系统管理器 ”的界面,而非受管实例列表,请确保您的系统已满足以下条件:

  • 您正在查看的EC2控制台与您启动CloudFormation模板的区域相同
  • 至少有一个实例正在运行Systems Manager代理
  • 运行Systems Manager代理的实例具有关联的实例角色,并具有允许Systems Manager操作的策略
  • 实例已完成初始化(通常只有几分钟)

3.选择本文前面CloudFormation模板创建的实例,然后选择 Run a command.4.在Run a command屏幕上,向下滚动命令文档列表并选择AWS-RunShellScript,平台类型是Linux。如果您使用Windows服务器,请选择AWS-RunPowerShellScript。本文不会涉及命令文档列表中的其他命令,但您可以在工作中根据实际用途选择使用其他命令文档。
5.确保选择了前文CloudFormation模板创建的EC2实例。
6.在Commands输入框中输入以下命令:

ifconfig

这会发出一个命令来查看主机的网络接口配置。 您可以在这里输入任何有效的bash命令(对于Linux),例如:安装补丁程序,执行应用程序,或更新配置文件等。

7.输入以下值,然后选择Run

  • 对于S3存储桶,请输入上文CloudFormation模板创建的存储桶名称(将S3前缀值留空)。
  • 对于角色ARN,输入从CloudFormation模板创建的ARN。
  • 对于SNS主题ARN,输入从CloudFormation模板创建的ARN。
  • 对于Notify me on,选择全部。
  • 对于Notify me for,选择命令。
  • 所有其他字段采用默认值。

8.在你启动这个要求之后, 选择 View Managed Instances.

9.如需查看命令历史,在 SYSTEMS MANAGER SERVICES,选择 Run Command.

10.要在Systems Manager控制台上查看命令的简要输出,请选择 Output, 然后再选择View Output.

对于较长的输出,您可以在先前指定的S3存储桶中查看完整的命令输出。此外,您应该在几分钟内收到一封电子邮件,通知您Systems Manager的命令已执行完成。

注意:如果您没有收到电子邮件通知,请确保您在启动CloudFormation栈时收到的SNS主题确认邮件中,点击链接确认接收SNS通知。

截至目前,您已经在应用服务器上成功执行了一个命令,而没有使用堡垒机或直接访问服务器。您可以审核命令的执行,并使用现有的IAM框架来控制对服务器的访问,而无需管理专用的RSA密钥。有关使用IAM框架控制Systems Manager的权限的详细信息,请参阅Configuring Access to Systems Manager

要清理CloudFormation模板创建的资源,请确保删除CloudFormation栈。如果您使用Systems Manager时将执行日志存储在存储桶中,您在删除栈之前必须手动删除存储桶及其内容。

下一步

大多数AWS服务都包含强大的API让您实现服务交互的自动化。使用控制台是学习和理解远程命令执行过程的好方法,但自动化这一能力提供了一种可靠和规范的方式来管理用户对此功能的使用。

例如,许多组织都依靠人员的轮值来支持生产环境。由于Systems Manager支持IAM集成,您可以根据人员上岗的特定时间段来自动授予或撤消Systems Manager调用权限。

在上文的示例中,您在控制台中执行了一个随意的命令。实际工作中,您将执行存储在具备访问控制的源代码库中的脚本,并可将此功能集成到现有的运维工作流程中,实现请求的跟踪、审批或拒绝。另外,使用AWS CLI、AWS API和AWS SDK,您还可以实现Systems Manager的全程自动化。

更多Systems Manager的特性

远程命令执行只是Systems Manager的一个功能。 其他功能包括:自动补丁管理,服务器软件清单,AMI自动化和参数库等。更多详细信息,请参阅Amazon EC2 Systems Manager产品详细信息页面。

总结

本文介绍了如何在EC2实例上远程执行命令,同时减少系统的攻击平面并简化系统的架构。您还可以使用AWS的IAM、日志和警报等服务帮助您获取服务器上所执行命令的详细信息。

您可能会遇到此解决方案无法满足的SSH或RDP的用例,例如SSH隧道或依赖于SSH的专有软件。希望这篇文章为您提供了关于如何访问和管理服务器的新思路。

 

译者介绍

寇欣,亚马逊AWS中国区专业服务部咨询顾问,加入AWS之前,在IT和云计算行业积累了丰富的云服务架构和应用软件架构的经验。历任Oracle电信事业部专业服务部门资深顾问、中国移动研究院云计算研究员、Lucent Tech研发中心系统架构师。

新增 – 面向 Amazon CloudWatch 控制面板的 API 和 CloudFormation 支持

我们在几年前发布了 CloudWatch 控制面板。在专为这次发布撰写的文章中,我介绍了如何以交互方式创建控制面板,以便以图形形式显示所选的 CloudWatch 指标。发布之后,我们增加了其他功能,包括全屏模式、深色主题、控制 Y 轴的范围、简化的重命名、持久性存储和新的可视化选项

新 API 和 CLI

虽然控制台支持非常有利于交互式使用,但许多客户要求我们提供对控制面板及其中小部件的编程式创建和操作的支持。这些客户想要动态构建和维护控制面板,从而在创建和销毁相应的 AWS 资源时添加和删除小部件。其他客户则希望在两个或多个 AWS 账户中设置和维护一组一致的控制面板。

我非常高兴地宣布,面向 CloudWatch 控制面板的 API、CLI 和 AWS CloudFormation 支持现已推出,您可以立即开始使用!

我们新增了四个 API 函数 (和等效的 CLI 命令):

ListDashboards / aws cloudwatch list-dashboards – 用于提取账户内所有控制面板的列表,或共享通用前缀的子集。

GetDashboard / aws cloudwatch get-dashboard – 用于提取单个控制面板的详细信息。

PutDashboard / aws cloudwatch put-dashboard – 用于创建新控制面板或更新现有控制面板。

DeleteDashboards / aws cloudwatch delete-dashboards – 用于删除一个或多个控制面板。

控制面板概念 我将要向您展示如何使用这些函数和命令。在转入正题之前,我应该介绍几个重要的控制面板概念和属性。

全局 – 控制面板是 AWS 账户的一部分,但未与特定 AWS 区域关联。每个账户最多可以包含 500 个控制面板。

命名 – 每个控制面板都有一个在 AWS 账户内唯一的名称。名称最长可达 255 个字符。

网格模式 – 每个控制面板都由网格单元格组成。网格包括 24 个单元格,高度可根据需要调整。控制面板中的每个小部件可位于一组特定的网格坐标上,大小可跨越一个整数的网格单元格。

小部件 (可视化) – 每个小部件可以显示文本或一组 CloudWatch 指标。文本通过 Markdown 指定;指标可以显示为单个值,或以折线图或堆积面积图的形式显示。每个控制面板最多可以包含 100 个小部件。显示指标的小部件还可以与 CloudWatch 警报相关联。控制面板有 JSON 表示形式,现在您可以在控制台中看到并编辑它。只需单击 Action 菜单并选择 View/edit source 即可:

下面是我的控制面板源:

您可以使用此 JSON 作为您自己的应用程序的起点。如您所见,控制面板中每个小部件的 widgets 数组中都有一个条目;每个条目描述一个小部件,从其类型、位置和大小开始。

使用 API 创建控制面板

假设我要在特定区域为我的每个 EC2 实例创建一个含有小部件的控制面板。我会使用 Python 和适用于 Python 的 AWS 软件开发工具包,然后按如下所示开始创建 (请原谅我的代码不够专业):

import boto3
import json

cw  = boto3.client("cloudwatch")
ec2 = boto3.client("ec2")

x, y          = [0, 0]
width, height = [3, 3]
max_width     = 12
widgets       = []

接着,我直接对实例进行迭代,以便为每个实例创建 widget 词典,并将其附加在 widgets 数组中:

instances = ec2.describe_instances()
for r in instances['Reservations']:
    for i in r['Instances']:

        widget = {'type'      : 'metric',
                  'x'         : x,
                  'y'         : y,
                  'height'    : height,
                  'width'     : width,
                  'properties': {'view'    : 'timeSeries',
                                 'stacked' : False,
                                 'metrics' : [['AWS/EC2', 'NetworkIn', 'InstanceId', i['InstanceId']],
                                              ['.',       'NetworkOut', '.',         '.']
                                             ],
                                 'period'  : 300,
                                 'stat'    : 'Average',
                                 'region'  : 'us-east-1',
                                 'title'   : i['InstanceId']
                                }
                 }

        widgets.append(widget)

我更新循环内的位置 (xy),并形成一个网格 (如果我不指定位置,则小部件会从左向右、从上至下进行排列):

        x += width
        if (x + width > max_width):
            x = 0
            y += height

处理完所有实例后,我创建一个 JSON 版本的小部件数组:

body   = {'widgets' : widgets}
body_j = json.dumps(body)

接下来,我创建或更新我的控制面板:

cw.put_dashboard(DashboardName = "EC2_Networking",
                 DashboardBody = body_j)

运行代码后,会获得以下控制面板:

CloudWatch 团队建议,以编程方式创建的控制面板应包括文本小部件 (用于说明控制面板是自动生成的) 以及指向所使用的源代码或 CloudFormation 模板的链接。这样可防止用户在外部对控制面板进行手动更改。如前所述,每个指标小部件还可以与一个 CloudWatch 警报相关联。您可以通过编程方式或使用 CloudFormation 模板来创建警报,如示例 CPU 使用率警报。如果您决定这样做,则警报阈值会显示在小部件中。要详细了解此操作,请阅读 Tara Walker 近期发布的文章 Amazon CloudWatch 发布了控制面板警报功能。更进一步的操作是,我可以使用 CloudWatch Events 和 Lamba 函数来跟踪某些资源的创建与删除,并在发生更改时更新控制面板。要了解如何执行此类操作,请阅读使用 AWS Lambda 让 CloudWatch 控制面板保持最新

使用 CLI 访问控制面板 我还可以通过命令行访问和操作我的控制面板。例如,我可以生成一个简单的列表:

$ aws cloudwatch list-dashboards --output table
----------------------------------------------
|               ListDashboards               |
+--------------------------------------------+
||             DashboardEntries             ||
|+-----------------+----------------+-------+|
||  DashboardName  | LastModified   | Size  ||
|+-----------------+----------------+-------+|
||  Disk-Metrics   |  1496405221.0  |  316  ||
||  EC2_Networking |  1498090434.0  |  2830 ||
||  Main-Metrics   |  1498085173.0  |  234  ||
|+-----------------+----------------+-------+|

然后,我删除 Disk-Metrics 控制面板:

$ aws cloudwatch delete-dashboards --dashboard-names Disk-Metrics

此外,也可以检索用于定义控制面板的 JSON:

使用 CloudFormation 创建控制面板

控制面板还可以在 CloudFormation 模板中进行指定。下面是一个简单的 YAML 格式的模板 ( DashboardBody 仍以 JSON 指定):

Resources:
  MyDashboard:
    Type: "AWS::CloudWatch::Dashboard"
    Properties:
      DashboardName: SampleDashboard
      DashboardBody: '{"widgets":[{"type":"text","x":0,"y":0,"width":6,"height":6,"properties":{"markdown":"Hi there from CloudFormation"}}]}'

我将模板放置在一个文件中,然后使用控制台或 CLI 创建堆栈:

$ aws cloudformation create-stack --stack-name MyDashboard --template-body file://dash.yaml
{
    "StackId": "arn:aws:cloudformation:us-east-1:xxxxxxxxxxxx:stack/MyDashboard/a2a3fb20-5708-11e7-8ffd-500c21311262"
}

下面是控制面板:

现已推出

此功能现已推出,您可以立即开始使用。您可以免费创建 3 个控制面板,每个控制面板最多包含 50 项指标;如果创建的控制面板超过 3 个,则每月需支付 3 USD (相关价格信息,请访问 CloudWatch 定价页面)。您每月最多可以免费调用 100 万次新 API 函数;如果超出此范围,则每调用 1000 次需支付 0.01 USD。

-Jeff

通过AWS Config 管理AWS服务配置

在之前的一篇安全相关的文章《从永恒之蓝开始,安全防范没有结束》中,提到通过AWS Config自动规范AWS服务的安全、合规方面的配置。

为更好遵从各行业的合规要求,构建安全的IT环境,企业的安全团队一般都会在明确安全/管理边界的前提下,选择相关安全框架,用对应的风险评估方法梳理出符合自身业务特点的安全模型。根据安全模型,通常也会用各种文档标准化抽象为各种管理策略,例如可能包含以下常见的内容:

  • 用户权限策略
  • 访问控制策略
  • 服务器安全策略
  • 应用接入策略
  • 网络分区策略
  • 数据传输策略
  • 数据存储策略
  • 备份归档策略
  • 日志记录策略
  • 审计管理策略

……….

在实际的应用场景中,标准策略可能会因为业务的变化或管理方式的变化动态调整,如何持续评估和审核在AWS云端的资源配置的合规性是否与企业规划一致?如何帮助用户在云端更好的实现变更管理,安全分析甚至自动修正不合规的配置 ?这种场景下,可以考虑用AWS Config 服务来帮忙。

一、AWS config 是什么

AWS Config 是一项托管服务,借助 Config您可以盘点AWS 资源、查看配置更改以及 AWS 资源之间的关系并深入探究详细的资源配置历史记录。使用 Config,还能通过自定义规则来定义所需的资源配置、内部最佳实践和指南,并依据这些规则评估您记录的配置。

AWS Config的主要应用功能:

  • 评估您 AWS 资源配置是否具备所需设置。
  • 获得与您的 AWS 账户关联的受支持资源的当前配置快照。
  • 检索您的账户中的一个或多个资源配置。
  • 检索一个或多个资源的历史配置。
  • 在资源被创建、修改或删除时接收通知。
  • 查看不同资源之间的关系。例如,您可能想要找到使用特定安全组的所有资源

AWS Config工作原理

更多AWS Config的信息可以参考https://aws.amazon.com/cn/config/

二、 AWS config 配置测试

为了更好了解AWS Config的工作过程,以下 将以AWS安全组的配置监控为例做一个简短测试 。

1. 测试场景:

  • 一个为web服务器配置的安全组,该安全组策略只允许对Internet开放HTTP和HTTPS两个端口;
  • 配置AWS Config 规则,当该安全组配置规则中添加了其他端口时,AWS Config 自动记录,并触发修复机制自动删除新加入的不合规的配置。

2. 配置过程

a. 权限准备。为成功配置AWS Config 规则,需要创建IAM 角色,授予 AWS Config 权限,使其可以访问Amazon S3 存储桶、Amazon SNS 主题,获取受支持的 AWS 资源的配置详细信息。IAM内置了一个AWSConfigRole的托管策略 。

新建一个IAM Role 命名为awsconfigrole, 可以直接附加该策略:

另外,测试过程中将使用lambda自动对安全组执行安全组操作,cloudwatch log操作,也需要建立好对应的IAM role并编辑策略赋予对应的权限,在测试中该IAM role为:awsoncifgec2security

{

    "Version": "2012-10-17",

    "Statement": [

        {

            "Effect": "Allow",

            "Action": [

                "logs:CreateLogGroup",

                "logs:CreateLogStream",

                "logs:PutLogEvents"

            ],

            "Resource": "arn:aws:logs:*:*:*"

        },

        {

            "Effect": "Allow",

            "Action": [

                "config:PutEvaluations",

                "ec2:DescribeSecurityGroups",

                "ec2:AuthorizeSecurityGroupIngress",

                "ec2:RevokeSecurityGroupIngress"

            ],

            "Resource": "*"

        }

    ]

}

b. 配置AWS Config Setting。在AWS 控制台,打开 AWS Config ,具体过程可以参考:http://docs.aws.amazon.com/zh_cn/config/latest/developerguide/gs-console.html

在本测试过程中,我们选择资源类型为SecurityGroup:

在配置过程中,指定一个存储桶保存日志,并指定预先为AWS Config 的IAM Role ,当然也可以在这个步骤选择新建角色:

在上述页面中,可以选择是否通过SNS 启用通知将信息流式传输到 Amazon SNS 主题,发送配置历史记录传输、配置快照传输和合规性等通知。

在Resources页面中验证一下,评估的对象是否能正常的筛选出来,本例中我们是对测试的安全组进行查找:

c. AWS Config 规则配置。AWS Config提供一些内置的规则,也支持自定义规则创建。在前文中提及测试的背景中需要通过自动机制保证安全组规则符合设定的合规配置,我们将通过lambda完成该步骤。在创建规则的过程中,按向导设置规则名称,点击新建lambda功能按钮:

在lambda创建过程中,选择blank blueprint 并为函数指定runtime为python2.7 ,将准备好的代码保存在s3(可以在github中找到相关代码参考,比如https://github.com/awslabs/aws-config-rules )并上传。

Lambda函数主要完成以下工作:

  • lambda函数中按照要求只开启tcp 80 和tcp 443端口;
  • 如果有其他端口添加到配置规则中将被删除,最终保证安全组的配置规则条目中只有tcp80和tcp443相关的配置;
  • 相关的操作将记录在cloudwath logs中。

在创建过程中,为lambda指定对应的IAM Role.

lambda创建完成后,需要在AWS Config 规则页面中指定Lambda ARN,  配置触发器。本例中,当安全组配置发生变化时即触发对安全组的评估,也可以配置按照时间周期的评估对象。 另外,为了详细记录评估信息,为规则启用debug级别的记录。

 

AWS config  规则后,当前的安全组配置将自动被评估。

d. 验证。为触发AWS Config 对安全组的评估, 我们在对应的安全组规则中除tcp 80 和tpc443,额外新添加tcp445 端口。在cloudwathc logs中创建了logs group,可以进行相关日志查看:

在日志中可以清楚看到对安全组有revoking的行为,操作的端口正是额外添加的tcp445 , 并且最终将安全组只开启tcp80 和tcp443 端口。

三、进一步讨论

在上述测试过程中,大致可以了解AWS Config的工作机制和配置流程,下面进一步对一些场景的应用场景做进一步说明。

资产发现

AWS Config 不仅会发现账户中的资源、记录其当前配置并捕获对这些配置所做的任何更改,Config 还会保留已删除资源的详细配置信息。所有资源及其配置属性的完全快照在您的账户中提供完整的资源库。

持续安全分析

AWS Config 提供的数据可使您持续监控您的资源配置情况,并评估这些配置是否具有潜在的安全弱点。对您的资源配置进行更改,将触发系统发送 Amazon Simple Notification Service (SNS) 通知,这些通知可发送给您的安全团队,以便他们查看通知并采取相应措施。发生潜在的安全事件后,您可以使用 Config 查看资源的配置历史记录并检查您的安全状况。

正如测试过程中展示,企业IT团队只需明确制定相关的策略,配置AWS Config规则,AWS Config提供了托管规则和自定义规则,能满足各种就能持续监控相关的安全标准是否合规。借助 AWS Config,利用 AWS Lambda 中的自定义规则将合规性要求编制成代码,这些代码会定义资源配置内部最佳实践和指南。您可以使用 Config 自动评估您的资源配置和资源更改,从而确保整个 AWS 基础设施实现持续合规性和自主监管。通过这个机制,为企业的安全自动化提供了一个可行选项。

变更管理

在创建、更新或删除资源时,AWS Config 会将这些配置更改流式传输到 Amazon Simple Notification Service (SNS),如此便会收到所有配置更改通知。根据通知机制也可以考虑引入基于事件触发的机制,进一步集成各个管理环节。

在AWS Config按照既定规则完成评估后,可以在规则的详细信息中查看到具体的变更事件记录:

审计

AWS CloudTrail 将记录账户上的用户 API 活动,将保存有关 API 操作的完整详细信息,如发起人的身份、该 API 调用的时间、请求参数和 AWS 服务返 。AWS Config 与AWS CloudTrail 集成 ,回答“谁进行了修改此资源的 API 调用?”例如下图, 使用集成的 AWS CloudTrail 信息,可以发现是哪个用户错误配置了安全组。

综合上述讨论,企业内部资产管理团队可以清楚明确当前在AWS云端的数字资产,安全团队可以将严格制定的安全体系持续的在云端自动化运行,任何相关的变更和配置管理都能详尽的记录,方便后续的审计。

更多关于AWS Config的一些常见问题可参考:https://aws.amazon.com/cn/config/faq/

作者介绍

李艺明

AWS解决方案架构师,负责基于AWS的云计算方案架构规划和咨询。在企业数字化转型,物联网和大规模并发场景有广泛的规划和实践经验。拥有超过10年的IT从业经验,为各种规模的企业客户提供IT项目实施和顾问服务。在加入AWS之前,服务于微软担任解决方案工程师,负责Windows Azure方案和架构设计,在此之前负责企业私有云和企业协同应用系统的架构规划和设计。

使用AWS Lambda和Amazon DynamoDB自动管理AWS CloudFormation模板中的Parameters和Mappings

背景介绍

相信AWS的用户对AWS CloudFormation都不会陌生。AWS CloudFormation是实现IAC(Infrastructure as Code)自动化运维的一项重要服务,可以帮助用户对 AWS资源进行建模和设置,以便能花较少的时间管理这些资源。CloudFormation中有两个重要选项:Mappings段和Parameters段,可以帮助用户组织模板里的参数和映射,让用户更好地自定义堆栈,以实现模板的重用和复用。比方说可以用Mappings管理对应AWS上不同region的AMI ID,或者管理企业内部的不同部门。

但是当用户所在的组织越来越多地采用IAC自动化时,mappings和parameters的数量也会急剧增长,给CloudFormation模板的编写和维护带来复杂度。

解决方案

本文里我们介绍一种方法:用当前流行的Serverless计算AWS Lambda 和Amazon DynamoDB自动地管理AWS CloudFormation模板中的Parameters和Mappings。

本文中主要用到了以下几种 AWS服务:

1、DynamoDB表:Amazon DynamoDB是一个NoSQL数据库,这里我们采用它保存CloudFormation模板中所有的mappings和parameters。不仅可以实现集中存放,而且可以依赖DynamoDB的接口实现方便快速地增删和查找。比方说在我们的sample code中,整个企业采用这样一张表:partition key包括组名(比如说team1、team2等)和环境(比如说development、test、production等),sort key保存应用的名字。这个表里的数据类似这样:

当我们把这些数据都insert到DynamoDB中后,可以在AWS console里看到表中的内容是这样的:

2、Lambda方法:AWS Lambda又称为Serverless的计算,通过它你可以运行你的code而不需要预配置或者管理任何服务器。这里我们采用Lambda方法实现CloudFormation和DynamoDB之间的关联,它从CloudFormation模板接收primary key和sort key作为输入,查找DynamoDB表,并且返回所有的key-value数据。

3、Custom lookup resource:这是CloudFormation里的一个自定义资源,与一个Lambda方法绑定。CloudFormation除了可以定义已有的AWS资源,还支持几种自定义资源,包括这种以Lambda方法作为后端的自定义资源。当这种自定义资源创建、更新或者删除时,CloudFormation自动地向Lambda API发起请求,引发方法并将请求的数据传给Lambda方法,本例中所请求的数据是primary key,返回的数据是key-value数据。通常在一个组织中只需要建立这一个custom resource,所有的CloudFormation模板都可以复用它。下图是sample code里建立的custom resource:

让我们将这几种服务组合起来,并且定义好它们之间的交互顺序,整个解决方案就是下图展示的这样:

那么整个的交互顺序如下:

1、用户创建DynamoDB表,插入所需的mappings和parameters数据。

2、CloudFormation模板中的custom resource调用Lambda方法,用组名和环境名称(“teamname-environment”)作为partition key,用应用名称(”appname”)作为sort key。

3、Lambda方法用partition key和sort key作为输入查询DynamoDB表。

4、DyanamoDB将结果返回给Lambda方法。

5、Lambda方法将这些key-value数据作为结果返回给模板中的custom resource。

6、custom resource拿到数据后,堆栈里的其他资源可以通过Fn::GetAtt的方式获得这些数据。

结论

通过这种方式,可以将我们创建堆栈所需的固定部分保存在模板中,而将可变部分mappings和parameters保存在方便增删改查的DynamoDB中,用Lambda实现两者之间的关联。对于大型组织来说,这样可以提高运维效率,也是使用CloudFormation的一种最佳实践。

参考

可以在我们的网站上下载到相关的sample code:https://github.com/awslabs/custom-lookup-lambda

关于AWS Lambda的更多内容请参考网站:https://aws.amazon.com/lambda/

关于CloudFormation自定义资源的更多内容请参考网站:http://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/template-custom-resources.html

作者介绍

张芸

AWS云架构咨询顾问,获得AWS解决方案架构师专业级认证和DevOps工程师专业级认证,为企业客户和合作伙伴提供迈向云端的专业服务。目前已为多家跨国公司及本土公司、合作伙伴提供上云迁移、应用优化、架构设计等咨询设计和实施服务。在加入AWS之前有近10年的云计算和大数据开源技术研究和开发经验,拥有多项美国和中国专利及专利申请,涉及云计算及服务,分布式系统,软件定义数据中心和自动化运维等领域,合作编著图书《大数据–战略·技术·实践》。

 

通过AWS目录服务管理AWS资源

背景

前段时间在拜访客户时,客户提了一个问题:如何结合企业内部既有的身份管理/鉴权体系,更加灵活、经济的实现对AWS 资源实现分角色管理的问题 ?

该客户目前在AWS多个 Region部署了业务系统,并且计划通过AWS Direct connect建立Region之间的专线连接,通过AWS的全球架构支持公司业务的快速扩展。客户的技术运营团队根据各协作团队的分工建立了不同权限的IAM用户,通过制定相应的IAM策略,各个协作团队可以管理对应的云端资源 。在实际工作中由于人员在项目之间频繁调整,及各种原因的人员流动等因素,导致 AWS IAM用户需要频繁调整。

就该客户情况而言,如果人员角色的任何变化只需在AD账户体系就能完成管理并自动映射到AWS 权限体系中, 客户就能平滑遵循企业内部的既有合规体系只需要管理AD帐号统一管理云端与本地的资源, 。

为解决这类的问题,通常可以部署ADFS实现IAM与本地活动目录间的联合身份认证,具体可参考这篇博客内容:https://aws.amazon.com/cn/blogs/china/adfs-bjs/

今天介绍另外一种实现方式,通过AD Connector与本地活动目录整合,使用本地活动目录中的用户登录AWS Console 页面。以下是基于 AWS Global 环境中的测试部署过程:

一.AD 连接器( AD Connector)是什么

AD连接器 AWS托管目录服务中的一种目录服务类型,用于将本地Microsoft Active Directory连接到AWS云端,无需进行复杂的目录同步设置或部署托管联合基础架构的组件。

AD连接器将登录请求转发到本地Active Directory域控制器进行身份验证,并使应用程序能够查询目录中的数据。用户可以使用其现有的企业凭据登录AWS应用程序,如Amazon WorkSpaces,Amazon WorkDocs或Amazon WorkMail。授予适当的IAM权限,还可以访问AWS管理控制台并管理AWS资源,如Amazon EC2实例或Amazon S3存储桶。

如上图,AD Connector与企业本地数据中心可以通过AWS Direct Connect 服务或IPSEC VPN进行数据交互。

二.活动目录服务器准备

1. 网络环境

在测试环境的vpc中规划以下子网:

  • 子网“lab-DC”将运行一个测试的活动目录服务器(域控)
  • 其他两个子网为位于不同az的私有子网,AD Connector 将部署在这两个子网中

在生产环境中,可以考虑在 AWS vpc部署多个与本地域控建立复制关系的只读域控服务器用于和 AD connector进行连接。

2. 域控服务器安装

在子网lab-DC新建一个windows server服务器,过程略。按照以下步骤进行域控服务器的部署,测试过程中假定域名为:ymlab.local

  • Import-Module ServerManager
  • Install-windowsfeature -name AD-Domain-Services –IncludeManagementTools
  • Install-addsforest –domainname “ymlab.local”

关于活动目录配置的更多信息可以参考:https://technet.microsoft.com/en-us/library/hh974719(v=wps.630).aspx

3. 测试用户配置

在新建的活动目录环境中建立两个AD用户和一个AD用户组:

  • user01:用来模拟某一AD用户,该用户在AWS云端仅具ec2 readonly的权限;
  • adconnector:ad connector的服务用户,分配最低权限即可
  • aws-ec2-readonly:AD组,user01将加入该组。

顺便留意一下aws-ec2-readonly组的sid,在后续的步骤中一旦AD connector配置完成,将能检索到对应object的sid,以便验证配置是否正确。

4. 域控服务器端口配置

配置测试环境中域控制器所对应安全组。在测试环境中,配置安全组允许来自vpc范围内与域控服务器之间的相关数据流。实际生产环境中,可以根据以下端口配置防火墙规则以实现AD connector 与本地数据中心的域控服务器相互通信。

与活动目录相关的更多端口信息可以参考:https://technet.microsoft.com/en-us/library/dd772723(v=ws.10).aspx

三.AD Connector配置

1. 在aws控制台中找到目录服务,选择创建 AD  Connector:

2. 在向导页面中提供活动目录的相关信息:

  • 输入活动目录对应的域名信息
  • 连接账户信息(该测试环境中输入在活动目录中创建的服务用户:adconnector)
  • DNS服务器信息(出于服务冗余考虑,可以输入多个dns服务器,比如提供AD环境中的额外DNS服务器IP)

3. VPC配置

在配置过程中,提供在不同az中建立的两个子网信息,如下图:

AD connector创建之后,可以明确核对AD connector是部署在多个az中:

4. 开启管理控制台访问

按照规划设置访问url, 通过该url用户可以在internet访问不同的应用服务。可以在下图中查看并配置需要开启的应用服务,比如workspace,workmail,console控制台等等。在测试过程中,选择启动”AWS Management Console”:

建立对应的IAM role, 后续配置过程中AD用户或组将映射到该role,实现AWS 资源的授权:

测试过程中选择新建一个角色:

选择所需的角色:

可以查看到对应角色的策略设置:

也可以按照实际的需求,自定义相关策略:

5. IAM role与AD 用户/组的关联

在配置页面中,输入AD用户/组对象的信息,如以下截图所示,在AD connector正常连接AD后,可以自动检索出 AD 对象:

进一步从group sid信息核对此信息与域控服务器检索的信息一致:

以上,完成了AD connector与域控服务器的所有配置,接下来验证是否能按照预期工作。

四.验证

输入配置过程中生成的服务url, 比如:https://ymlab.awsapps.com/console  , 在出现的登录页面中输入测试用户信息(user01):

登录成功后,可以看到登录用户所对应的role,如下图:

在 EC2管理页面,尝试‘停止’一台EC2,可以看到如下报错:

尝试开启Beanstalk,提示没有权限:

小结:

AWS Directory Service提供了多种将Microsoft Active Directory与其他AWS服务结合使用的方法。AD Connector 是在AWS 和本地活动目录环境建立连接的很好选择,还可以配置本地RADIUS服务器实现MFA身份验证。 除 AD connector以外,AWS 目录服务还有更多的服务类型对应不同的应用场景,具体信息请参考:http://docs.aws.amazon.com/zh_cn/directoryservice/latest/admin-guide/what_is.html

 

作者介绍:

李艺明

AWS解决方案架构师,负责基于AWS的云计算方案架构咨询和设计,在国内推广AWS云平台技术和各种解决方案。拥有超过10年的IT从业经验,为各种规模的企业客户提供IT项目实施和顾问服务。在加入AWS之前,服务于微软担任解决方案工程师,负责Windows Azure方案和架构设计,在此之前负责企业私有云和企业协同应用系统的架构规划和设计。