AWS Systems Manager(SSM)

Hello大家好，我们今天的课时讨论AWS Systems Manager ，SSM。

SSM是AWS比较强大的一个服务，在AWS的DevOps以及SysOps认证考试中考点非常多，在SAP认证考试同样也会涉及一些SSM的考点，我们通过这个课时争取把这些考点都搞定。

AWS Systems Manager 概述

• 可以使用 SSM 来组织、监控 AWS 资源并对其自动执行管理任务，SSM可以帮助我们管理大规模的EC2实例以及本地的服务器。

• 它提供了管理基础架构的运营洞察力，将需要管理的资源进行标记后，可以在SSM中查看整合的信息，能够帮助我们很容易的提前发现问题所在。

• 如果您需要为很多EC2实例打系统补丁，就可以使用SSM来做，这部分的内容在SAP认证考试中会出现，我们在后面也会详细的讨论，您需要记住所有相关的步骤。

• SSM支持WINDOWS和LINUX操作系统，并与多个AWS服务集成，如CloudWatch指标和仪表盘，以及AWS config，通过它跟踪EC2实例的配置，等等。

• SSM的大部分功能是免费的，部分功能需要付费。

AWS Systems Manager 功能

好，下面我们就深入了解下SSM提供的功能，包括运营管理、应用程序管理、执行和变更以及实例和节点四大部分，每个部分都提供了多个服务。

运营管理，提供了一系列的服务帮助管理AWS资源，包括：

• Explorer ，可以跨AWS区域显示您的AWS资源相关数据的聚合视图(OpsData和OpsItems)。

• OpsCenter，可以聚合多个AWS服务中的事件集中查看和管理，降低解决问题的平均时间。

• CloudWatch仪表盘以及PHD仪表盘。

应用程序管理，包括：

• 资源组，提供了查找和分组AWS资源的功能，可以查看整组资源的分析报告以及可对资源组的资源运行复杂的任务。

• Appconfig，提供了应用程序配置管理和部署。

• 参数仓库，Parameter Store，用于集中管理密钥和配置数据等，将敏感数据与代码和配置分离。

执行和变更，包括：

• 自动化，可以简化常规的任务，将常见的IT任务定义成SSM文档的一系列步骤，并对资源大规模执行这些步骤。如自动关闭EC2实例或自动创建AMI等。

• 变更日历，可以通过制定一个时间范围，允许或者阻止在指定时间范围内对AWS资源执行变更。

• 可以通过创建维护窗口，为大批量实例安排并实施常规任务。如给实例打补丁、执行自动化任务，或在指定期间执行其他可能中断性任务。

然后，实例和节点，包括：

• 合规性，配置并监控管理的EC2实例的的补丁安装和状态管理器配置合规性数据，集中管理合规性，修复合规性问题。

• 清单，Inventory，提供了收集管理实例的元数据，如已安装应用程序，网络配置，更新包等

• 托管实例及混合激活，提供混合云和跨云的管理，将这些资源安装和激活SSM相关的功能等

• 会话管理器，只需要一次点击就可以安全登陆实例，不需要开启SSH服务，且无需配置入站策略和管理堡垒机。

• 运行命令，Run Command，可以安全、批量的在您管理的EC2实例上运行命令而不需要ssh通道。

• 状态管理器，定义和维护操作系统或应用程序的配置，集中对配置进行管理。

• 补丁管理，Patch Manager自动化安装、修补系统补丁。

• 最后，Distributor用于打包自己的软件或查找AWS提供的软件并安装部署。

可以看到SSM提供了很多很多的功能，我们后面主要针对认证考试重点对Patch Manager，Parameter Store，Run Command和维护窗口的内容进行讨论，所以我们开始吧。

AWS Systems Manager 是如何工作的？

介绍完SSM的功能，那么首先我们要了解Systems Manager是如何工作的？

AWS提供了Systems Manager 服务，然后您还需要在您想要管理/控制的实例或服务器上安装SSM agent，SSM可以管理本地数据中心的服务器以及EC2实例。

在一些AMI中默认安装了SSM agent，如Amazon linux AMI 、Amazon linux 2 AMI 以及 一些Ubuntu的AMI。如果您的系统没有默认安装，就需要自行安装SSM agent。在本地的服务器或者EC2实例上安装了SSM agent后，SSM agent就会和SSM service进行通信并向SSM service进行注册。

那如果有某台实例无法通过SSM service进行管理，那么非常有可能是SSM agent的问题：要么是SSM agent的配置问题，要么就是在其管理的EC2实例上没有配置正确的允许SSM操作的IAM角色。

我们看一下这个图示，在需要管理的EC2实例或者本地的服务器上需要安装SSM agent，SSM agent需要和SSM service进行通信，所以我们还要给EC2实例定义并分配一个IAM角色，允许SSM agent 与 SSM service进行通信。

一旦我们所有的EC2实例和本地的服务器都正确的安装并配置了SSM agent，并可以正常和SSM服务进行通信后，就可以利用SSM服务提供的多个功能来对实例进行管理。

AWS Systems Manager – 运行命令

那么接下来我们就对前面提到的SSM的4个功能进行讨论。

首先，我们来讨论下运行命令（Run Command）。

Run Command可以安全、批量的在您管理的实例上运行命令而不需要配置ssh通道。

它可以在管理的实例运行document，一个脚本或者一个单独的命令。

可以将多个EC2实例分配为一个资源组，然后可以在一个资源组的多个实例上运行命令。

然后可以通过配置rate controls ，进行执行命令的并发配置以及错误控制。来控制运行命令的并发数量以及当执行命令的错误数量达到配置值时停止执行。

SSM与多个AWS服务进行了集成，比如IAM和CloudTrail，可以通过IAM控制使用SSM的用户权限，以及通过CloudTrail进行分析和审计，为SSM提供了审计以及安全的控制和保障。

Run Command是不需要实例开放SSH的，他不是通过SSH，而是通过安装在实例上的SSM Agent来执行命令。可以通过SSM服务的会话管理登陆实例，而不通过SSH。这样的话完全可以不依赖SSH服务，在某种程度上也提高了一些安全性。执行的结果的摘要也会显示在控制台中。

我们来看一下，有一台EC2实例，我们没有在实例上配置SSH服务，并已经将SSM Agent安装到了这台实例上，假定进行了正确的配置。然后SSM Agent将会和SSM服务保持通信。当我们在SSM上执行Run Command时，命令会被发送到SSM Agent，SSM Agent直接在EC2实例上执行相应的命令，在这个流程中并不需要实例配置SSH，并可以通过CloudTrail对SSM的所有API调用进行分析和审计。

SSM Patch Manager – patch baselines

好的，接下来的内容我们讨论下SSM的Patch Manager，它的用途是为管理的EC2实例批量、自动化的进行打补丁操作。

那么首先，您需要了解的是您需要定义一个补丁基准，也就是patch baselines。

patch baselines定义新补丁发布几天后自动批准补丁，以及批准安装和拒绝安装补丁的列表。

下面我们来看下由AWS预定义的patch baselines，这些patch baselines的命名需要大家记住。

先看LINUX系统：

AWS-AmazonLinux2DefaultPatchBaseline，这个是Amazon Linux 2 预定义的PatchBaseline。

以及其他的一些常见的Linux预定义的PatchBaseline，如：

AWS-CentOSDefaultPatchBaseline，AWS-RedHatDefaultPatchBaseline，AWS-UbuntuDefaultPatchBaseline，以及AWS-SuseDefaultPatchBaseline。

可以看到AWS预定义的patch baselines的命名有一定的规律，都是AWS-系统名称在加上DefaultPatchBaseline。

对于WINDOWS操作系统有一些不同，补丁会在释放7天后自动被批准。所以一旦windows补丁发布7天之后，将会自动被批准并将通过PatchBaseline进行打补丁。

对于WINDOWS操作系统，最重要的一个预定义的PatchBaseline是AWS-DefaultPatchBaseline ， 这个PatchBaseline的内容是将安装所有WINDOWS的关键更新和安全更新。

还有一个命名为AWS-WindowsPredefinedPatchBaseline-OS的PatchBaseline，它的内容和上面这个是一样的，都是安装WINDOWS的关键更新和安全更新。

然后，AWS-WindowsPredefinedPatchBaseline-OS-Applications，这个PatchBaseline除了会更新关键更新和安全更新，还会更新您的EC2实例上的windows应用程序。

要参加认证考试，要记住上面这些由AWS预定义的PatchBaseline的名称，尤其是这个AWS预定义的windows 的AWS-DefaultPatchBaseline。

另外，除了使用AWS预定义的，也可以自定义PatchBaseline，定义要自动批准的补丁，如定义自动批准补丁的操作系统的名称，定义更新的类别，如关键更新，还是安全更新等，以及严重程度如关键、重要等等。

总之，一旦确定了PatchBaseline，接下来的步骤就是要定义如何将这些补丁应用到windows或linux系统。

SSM Patch Manager – 步骤

对于参加认证考试，需要记住SSM Patch Manager的所有步骤，我们一起来看一下

1. 第一步是定义PatchBaseline，这个前面我们讨论了。如果您有多个环境如多个不同版本的Linux或者同时使用Windows和Linux，那么您可以定义多个PatchBaseline。

2. 第二步是要定义修补补丁组， patch group。patch group就是使用标签将实例进行分组管理，比如按照环境来区分的话，有开发环境、测试环境、生产环境，我们可以定义不同的 patch group来对不同的环境的实例进行管理。

3. 然后第三步是定义一个维护窗口，maintenance window。通过维护窗口，您可以定义一个时间表，以定义何时可以对实例进行可能的潜在破坏性的操作，如为系统打补丁、更新驱动等等。为了最大程度地减少对您的服务可用性的影响，建议配置维护窗口，并将对实例打系统补丁的操作安排在维护窗口进行，以在不中断业务运营的情况下进行打补丁操作。

4. 第四步，我们必须定义在维护窗口需要做什么。首先需要创建一个维护窗口任务，指定一个run command名为 AWS-RunPatchBaseline 的document。它是跨平台的，可以支持windows和linux操作系统；

5. 然后通过配置任务的rate controls ，进行执行命令的并发配置以及错误控制。

6. 最后，我们可以使用SSM inventory定义和监控补丁的合规性。

以上就是完整的步骤，看起来有些复杂，概括起来就是通过以上这几步来通过SSM的Patch Manager批量打补丁。

1. 首先定义或者选择默认的PatchBaseline，定义打补丁的列表。

2. 然后创建patch group，将您需要批量打补丁的实例进行分组。

3. 定义一个维护窗口，在维护窗口指定一个名为AWS-RunPatchBaseline的document，大家需要牢记这个document的名称。

4. 补丁会在维护窗口按照任务配置的rate controls进行应用，也就是进行打补丁操作。

5. 最后，可以使用SSM inventory定义和监控补丁的合规性。

可以看下右侧这个图，这个图就是我们上面介绍的流程，希望能够帮助大家理解。

如果您仍然对这部分有疑问，可以访问图下方的AWS官方的博客，里面的内容应该会有所帮助。

对于SAP认证考试，您需要掌握上面这部分的内容，尤其是前面的这个在维护窗口指定的AWS-RunPatchBaseline的document的这个名称，以及前面讲过的windows操作系统aws预定义的PatchBaseline的具体的名称。

AWS Systems Manager – Parameter Store

好我们继续，接下来是Parameter Store。

Parameter Store为我们的配置数据以及密钥提供了一个安全的、分层的存储。您可以将您的密码，数据库字符串，AMI ID，或者license作为参数值存储到Parameter Store，然后可以通过脚本，命令或者SSM documents引用您存储的值。

这样的好处是您可以通过这种方式将您的代码和密钥等重要数据分离。

它可以使用KMS无缝的进行加密（可选）。

它是无服务器的，可扩展的，高度持久的，简单的SDK。

您可以对存储的配置数据以及密钥进行版本追踪。

所有的存储的参数的管理使用路径的方式，可以使用IAM策略来定义安全访问这些路径。

如果Parameter Store的内容变更可以通过CloudWatch Event收到通知。

它与CloudFormation集成，可以在CloudFormation模板中拉取在Parameter Store存储的密钥。

我们先看下存储/引用明文配置的情况，我们的应用程序要访问Parameter Store中存储的明文配置，在这种情况下Parameter Store将只检查应用程序的IAM权限信息，来确定明文的配置是否允许应用程序访问。

另一种情况是访问加密的配置，在这种情况下，如果IAM权限信息正确，SSM服务首先会访问KMS服务完成解密。

另外，可以使用SSM Parameter Store 的API从Secrets Manager取回密钥，这也是我们接下来要讨论的内容。

AWS Parameter Store – 分层结构

Parameter Store存储参数时支持层次结构，使得大规模的组织和管理参数更加的容易。

支持参数存储的层次结构，可让您根据部署来组织参数。它为组织参数，查询和权限控制提供了强大的支持。

我们通过一个例子来看下什么是层次结构存储。

比如我们可以定义部门为第一层，假设我们叫做my-department 。

然后是应用程序名称，如my-app。

应用程序的下一层我们可以定义开发环境dev，以及生产环境prod。

在环境的下一层我们定义实际存储的参数，比如db-url，用于存储DB的url的明文数据；以及db-password用于存储DB密码，您可能希望通过KMS进行加密的参数，生产环境参数同上所述。

好，然后在my-department下除了这个my-app，可能还会定义其他的应用，other-app，或者定义其他的部门other-department。

以上的例子就是一个常见的分层结构。

最终您可以通过调用这个指定的路径/aws/reference/secretsmanager/secret_ID_in_secrets_manager，从Secrets Manager取回密钥；或者我们也可以通过调用获得由AWS管理的参数，比如通过调用这个路径获得amazon linux的最新的AMI ID。

最后，如果我们部署了lambda函数，我们可以使用GetParameters 或者 GetParametersByPath API 基于我们前面分层结构的环境来获取对应的参数。基于环境，我们可以配置不同的lambda函数只允许访问对应环境的参数。

好的，以上就是SSM所有的内容，在前面尤其是强调过的重要内容需要大家掌握，希望本课时能够给大家带来帮助。

![图片](https://img-blog.csdnimg.cn/img_convert/e1f3a32d47fb8db20ea0d3d3340a6e93.jpeg
希望此系列教程能为您通过 AWS解决方案架构师认证 Professional 认证考试带来帮助，如您有任何疑问，请联系我们：