Remotely managing a large number of disparate systems and applications can be a challenging task for edge device administrators. Amazon IoT Greengrass helps these system administrators manage their edge device application stacks. However, the system software on these devices must be updated and maintained individually through operational policies that align with those of their larger IT organizations. Additionally, customers must build or integrate custom tools to ensure edge devices can be managed with a consistent set of policies alongside Amazon Elastic Compute Cloud (Amazon EC2) and on-premises instances.
| The Amazon cloud technology developer community provides developers with global development technology resources. There are technical documents, development cases, technical columns, training videos, activities and competitions, etc. Help Chinese developers connect with the world's most cutting-edge technologies, ideas, and projects, and recommend outstanding Chinese developers or technologies to the global cloud community. If you haven't paid attention/favorite yet, please don't rush over when you see this, click here to make it your technical treasure house! |
We announced at re:Invent 2021 the integration between Amazon Systems Manager and Amazon IOT Greengrass . This release simplifies the management and maintenance of system software for edge devices. When combined with Amazon IoT Greengrass client software, Amazon Systems Manager enables edge device administrators to remotely access and securely manage the many devices they own – from operating system patching to deploying applications. Administrators can take advantage of nearly all operational and node management capabilities of the Systems Manager service .
This blog post describes how to set up to integrate an Amazon IoT Greengrass device with Systems Manager. In it, we'll demonstrate how to use Session Manager to turn on telnet to edge devices, patch them with Patch Manager, and run automation scripts with Run Command.
Install the Amazon IoT Greengrass Core software
First, we must install the Greengrass Core software on the edge device. Several options are available for installing Amazon IoT software, including:
- automatic preset
- manual preset
- Instance Set Presets
- custom preset
See the Amazon IoT Greengrass documentation for the differences between these provisioning methods.
In this blog post, we use the automated provisioning method to install the Greengrass Core software on edge devices. In this method, the installer provisions the required peripherals, such as registering an Amazon IoT thing and creating an Amazon IoT thing group, an Amazon Identity and Access Management (IAM) role, and an Amazon IoT role alias. This allows for faster setup. Automatic provisioning is available for both Linux and Windows devices. In the following steps, we are using an Ubuntu Linux box. Device requirements for running the Amazon IoT Greengrass Core software can be found in the Amazon IoT Greengrass documentation .
After successfully installing the Greengrass Core software, you should see a Core device with a status of Healthy in the Amazon IoT Greengrass console . If the installation fails or the device is not in a Healthy state, please refer to the Troubleshooting Guide
Figure 1: Edge devices in the Healthy state are visible under Greengrass Core devices in the Amazon IoT Greengrass console.
Deploy the Systems Manager agent
Now that the edge device is communicating with Amazon IoT Greengrass, we can deploy software components to the device. You can also use Amazon IoT Greengrass to deploy components to a fleet of devices. Deployment defines the components of the existing software and its configuration to be applied to the device, and deployment is continuous. When a deployment is created, Amazon IoT Greengrass pushes the deployment out to online target devices. If the target device is not online, it will receive the deployment the next time it connects to Amazon IoT Greengrass.
The Systems Manager Agent (SSM Agent) will be deployed through Greengrass as a component, enabling the Systems Manager service to update, manage, and configure Greengrass Core devices. The agent processes and runs requests from the Systems Manager service in the Amazon Cloud. The agent then sends status and runtime information back to the Systems Manager service.
Follow the steps in the Installing the Systems Manager Agent documentation to complete the Systems Manager setup steps and deploy the Systems Manager Agent components. This process consists of four phases, which are summarized below:
- Complete the general Systems Manager setup steps.
- Create an IAM service role for Systems Manager.
- Add permissions to the token exchange role.
- Deploy the Systems Manager agent components.
The deployment process may take several minutes to complete.
After deploying the Systems Manager components, navigate to the Amazon IoT Greengrass console , choose Core Devices, and then choose your device. On the details page for the Core device, find the Systems Manager Instance Properties link to the SSM console.
Figure 2: The edge device is now a managed node, which appears under the instance set manager in the Systems Manager console.
Edge devices registered with Systems Manager through Greengrass will have a node ID starting with " mi- ". To use Systems Manager and its features to manage devices, the SSM Agent ping status for a given node must be Online . You can verify the SSM Agent ping status of a node by selecting the Node ID .
Figure 3: The Node overview page showing managed node details .
Systems Manager treats edge devices as managed nodes. You can now access managed nodes, perform patching and collect monitoring data, and perform other tasks.
1. Open a terminal on the edge device
On the Node overview page, select the **Node actions** drop-down menu, then select Start terminal session . This action starts a terminal session on the edge device through Systems Manager Session Manager.
Note: Session Manager requires a premium instance plan to interactively access edge devices as they are registered with Systems Manager as hybrid instances. Additionally, it has additional pricing, which can be viewed at Systems Manager Pricing . Follow the steps in the Systems Manager documentation to enable the Premium Instance Plan from the console.
Figure 4: An interactive session window opened in a browser for a hosted node.
Sessions stream the input and output of commands using a secure two-way communication channel between the client (you) and the remote hosted node. Traffic between clients and managed nodes is encrypted using TLS 1.2, and connection creation requests are signed using Sigv4. This two-way communication allows interactive bash and PowerShell access to managed nodes.
Additionally, data is deeply encrypted using Amazon Key Management Service (Amazon KMS) over the default TLS encryption. Additionally, through integration with numerous Amazon services such as Amazon Simple Storage Service (Amazon S3) , Amazon CloudTrail , and Amazon CloudWatch Logs , we provide options for logging and auditing session history in Amazon accounts. One option is to configure preferences within the session , which are customizable, allowing to define shell preferences, environment variables, working directory, multiple commands to run, etc. when the session starts.
2. Patching edge devices
Patch Manager is a feature of Systems Manager that provides pre-defined patch baselines for each supported operating system that typically approve security-related patches. Use these baselines from your current configuration (we cannot customize them) or create custom patch baselines. Leverage custom patch baselines to gain greater control over which patches are approved or rejected for your environment. In this blog post, we will use a predefined patch baseline. For more information, see the Predefined and Custom Patch Baselines documentation .
To patch an edge device:
- Open the Node overview page for the managed node .
- From the Node actions drop-down menu, select Patch node . We will see the Amazon Systems Manager Patch Manager page for patching edge devices . Read through the options provided on the page that shows the basic configuration for patching. By default, the patch action is Scan , which only scans for missing patches and does not install them.
- Keep all default settings, scroll to the bottom of the page, and select Patch now .
Figure 5: The Patch now window with default options selected.
- On the next page, we'll see a patch executive summary. After selecting the Execution ID hyperlink followed by Output on the page , view the details and results of the scan operation.
The output page consists of three steps. In Step name, choose the step that corresponds to the operating system running on the edge device. For example, if it's running Linux, expand the output and errors of the step PatchLinux. Note that edge devices must have access to their respective repositories in order to pull patches.
Figure 6: The Association Execution Summary window showing details of patch operations in scan mode.
Figure 7: The output of the scan operation shows a summary of available patches for managed nodes.
For more information, visit the How Patch Manager Works documentation .
Due to intermittent connectivity and limited technical specifications of these edge devices, the time to complete the installation may vary. Patch Manager uses Run Command (another Systems Manager feature we'll cover in the next section) to perform patching operations on managed nodes.
3. Remotely send commands to edge devices
Use Run Command, a Systems Manager feature, to configure managed nodes at scale without logging into them. We collect processes running on edge devices through Run Command in this blog post. Back on the Node overview page, select Execute run command from the Node actions drop-down menu . Using this method, the user can enter the Systems Manager Run Command page. You'll see a list of available preconfigured command documentation. Search for Amazon-RunShellScript , and select that document. Our edge device is running on Ubuntu, so we'll send the ps aux command to run the process. Under Command parameters , in the Commands text box, type ps aux.
Figure 8: The Run a Command window with the Amazon-RunShellScript document selected and the Shell command provided.
Scroll down to Goals. We should see our node selected. Under Output options , uncheck Enable an S3 bucket . For production use, it is recommended that all command output be written to an Amazon S3 bucket for auditing purposes. In this blog post, we are only testing to see if the Run command was successful. We also recommend "Enabling Cloudwatch Logs" in production use for additional auditing.
Choose Run . This will take you to a page showing the results of the Run command. Select the radio button next to Instance ID, then choose View output to view the command's output on the target IoT device. This action will take us to another page. The selected output will show us the result of the "ps aux" command sent to the edge device.
Figure 9: Output of a shell command run via Run Command.
Another way to collect running processes on managed nodes is to use the Systems Manager Instance Set Manager . Announced at re:Invent 2021 is a new feature that provides customers with an easy console-based experience to view and manage processes on their instances. Customers can view in-depth details such as process name, process details, and utilization metrics for each active process. They can query processes by name and quickly sort columns based on any process parameter. Also, you can kill unwanted processes or start new ones in the console.
The instance set manager utilizes the session manager functionality to manage processes on managed nodes. Additionally, it requires Amazon KMS encryption to be enabled in the session manager preferences. For steps on updating your session preferences , visit this documentation. Take note of the Amazon KMS key we selected in the previous step, and open this key in the Amazon KMS console .
In the previous sections of this blog post, you created and deployed the SSM Agent component that was supposed to create the IAM service role. It is assumed that the SSM agent has been deployed following the Amazon IoT Greengrass documentation. In this case, the name of the IAM service role should be SSMServiceRole. You need to update the encryption key by following the steps in the Amazon KMS documentation to add the SSMServiceRole as one of the key users.
As mentioned in section 2 above, open up our managed node in the Systems Manager console to see how it works. Under Node overview in the left column , select Processes .
Figure 10: Node details page showing process and resource usage information for managed nodes.
Because IoT Greengrass Core software and Systems Manager agents can control thousands of remote devices, it is critical to follow Amazon Well-Architected 's best practices of least privilege security. Least privilege is the principle of granting only the permissions needed to complete a task. An Amazon-managed policy set with automatic provisioning is a good starting point for looking at actions typically associated with a particular service or job function. However, they may not meet company compliance standards or specific use cases.
For help writing a least privilege IAM policy, see this blog post .
to clean up
If you no longer want to use Systems Manager to manage your edge device, unregister the device and uninstall the Systems Manager agent from it. Follow the steps in the Uninstalling the Systems Manager Agent documentation. Likewise, you can uninstall the Greengrass Core software to remove it from the edge device. Find instructions for stopping, disabling, and deleting Greengrass services in the Uninstalling the Amazon IoT Greengrass Core Software documentation .
in conclusion
This post demonstrates how to install the Systems Manager agent on an edge device as an Amazon IoT Greengrass component, and how to leverage various Systems Manager capabilities to centrally manage edge devices as well as Amazon EC2 and on-premises nodes. First, we explained how to install the Amazon IoT Greengrass Core software on an edge device and how to deploy the SSM agent component, then walked through three device management use cases.
These use cases include:
- Gain interactive shell access to edge devices while improving security and audit posture, centralizing access controls, and restricting inbound access. Start a session using the Amazon Management Console, the Amazon Command Line Interface (Amazon CLI) , or one of the supported Amazon SDKs . For more information, see Console, CLI, and SDK Access to Session Manager Features .
- Patching the OS of patchable edge devices with granular control. Automated patching can be performed across sets of appliance instances using well-defined maintenance windows during which outages to operations are acceptable. For more information, visit Using Maintenance Window Patching Schedule .
- Execute remote scripts on edge devices in a controlled manner, enabling security management at scale. Use Run Command to install or boot applications, track inventory, apply software updates, or modify system settings. Additionally, thousands of edge devices can be targeted in a single Run Command using tags on managed nodes. For more information on Run Command, see the Amazon Systems Manager Run Command documentation .
author:
Pal Patel
Pal Patel is a cloud infrastructure architect with 5+ years of experience working with and supporting Amazon customers. She is an SSM enthusiast with a passion for SSM automation. In her spare time, she likes to learn how to sketch human faces, likes to read (her current favorite is "The Codebreaker"), and is also an avid listener of KPOP music (ARMY).
Bryan Henderson
Bryan Henderson is a Senior Solutions Architect at Amazon in Chicago, IL. He is passionate about helping customers build solutions on Amazon to solve their problems. Outside of work, he enjoys running, playing at Wrigley Field, and spending time with his wife and two daughters.
Article source: https://dev.amazoncloud.cn/column/article/630a3da48a1013112795045e?sc_medium=regulartraffic&sc_campaign=crossplatform&sc_channel=CSDN