Red Hat Lightspeed is a Software-as-a-Service offering that enables users to obtain actionable intelligence regarding their Red Hat Enterprise Linux environments, helping to identify and address operational and vulnerability risks before an issue occurs. Red Hat Lightspeed requires a client tool to run on the system to collect data and perform necessary analytics to proactively detect misconfiguration and alert system administrators. This article explores how one can leverage the client’s existing functionality to run its own automation using a simple shell script.

In its default configuration, insights client runs daily on each registered Red Hat Enterprise Linux (RHEL) system. For RHEL 7.5 and above, the execution is triggered by a scheduled systemd daemon. The insights-client configuration also comes with a systemd path unit that monitors a file for the completion of insights-client. If the upload to Red Hat Lightspeed is successful, the file is modified and causes the path unit to trigger.

In this article, we use this event to execute our own systemd service that runs a shell script to call Red Hat Lightspeed APIs with the curl command. We provide an example to assign the system to an inventory group as part of this automation. A similar approach can be configured to perform any type of post insights-client automation.

What are inventory groups?

Inventory groups offer the ability to group systems together and organize them in combination with role-based access control (RBAC) management. With inventory groups in place, administrators can restrict system access to specific groups of users, allowing them to get a filtered view and management capabilities for their accessible inventory.

The use of inventory groups is not mandatory and all systems within an organization are initially ungrouped and accessible to all users. Further, systems can only be assigned a single inventory group. This process can be done from the Red Hat Lightspeed web interface manually, or via its APIs automatically. More information on automating the process of assigning systems to groups using the Red Hat Lightspeed API is documented in this knowledge base article on Red Hat Customer Portal.

An alternative to using inventory groups is utilizing systems tags. Tagging is often offered by platform management tools to organize, search, and filter inventories in a consistent manner. Red Hat Lightspeed provides system tags and we covered its functionality in a recent article in which we explore how to synchronize tags from Amazon Web Services and Microsoft Azure into Red Hat Lightspeed. Both tags and inventory groups are available in Red Hat Lightspeed and let users search and filter their inventory and applications. Tags can also be set at the top level (also called global filter) to automatically filter all applications within Red Hat Lightspeed. The main difference between system tags and inventory groups is that tags do not allow for restricting user access to systems using RBAC.

To this end, we want to explore in this article how to link those two capabilities by using system tags as a source to automatically assign systems to groups. Although this may be a valid use case, the main goal of this exercise is to provide an approach and a simple example to extend insights client with custom automation.

Extending insights client configuration to execute custom automation

The product documentation for Red Hat Lightspeed contains a dedicated chapter on its insights-client tool. You can learn about its different options for configuration such as authentication, client data obfuscation, and data redaction. In this article we are particularly interested in its section about the insights-client scheduling and how it performs its data collection daily.

For RHEL 7.5 and above (the focus of this article), insights client configures and enables a systemd timer that is scheduled to run every 24 hours. Every time insights-client runs and uploads a payload to Hybrid Cloud Console, it keeps and updates a file on the system itself (/etc/insights-client/.lastupload). This file is in turn monitored by a systemd path unit. We can use this trigger and associate an additional systemd service (insights-client-automation.service) to run our own automation once insights-client execution is complete.

First, we create a new insights-client-automation.service service that will serve to run our shell script (/usr/bin/assign-group.sh). Its content should look like the following:

$ sudo cat /usr/lib/systemd/system/insights-client-automation.service
[Unit]
Description=insights Client Automation when /etc/insights-client/.lastupload has changed
[Service]
Type=simple
ExecStart=/usr/bin/assign-group.sh
[Install]
WantedBy=insights-client.timer

Note that we do not need this service to start at boot as it will execute on demand when our unit path triggers. Permissions should be the same as other insights-client services.

$ ls -lal /usr/lib/systemd/system/insights-client-automation.service
-rw-r--r--. 1 root root 196 Apr 22 10:20 /usr/lib/systemd/system/insights-client-automation.service

Next, we modify the existing insights-client-results.path by adding an override.conf file with our changes. We simply want to execute our new service when the trigger occurs. For that, we need to create the directory and override.conf file and populate its content:

$ sudo mkdir /etc/systemd/system/insights-client-results.path.d
$ sudo touch /etc/systemd/system/insights-client-results.path.d/override.conf
$ sudo cat /etc/systemd/system/insights-client-results.path.d/override.con
[Path]
Unit=insights-client-automation.service

The unit path is now extended to execute our automation service and its associated script whenever it triggers due to modifications on the /etc/insights-client/.lastupload file.

Configuring a service account for token-based authentication to Hybrid Cloud Console

Using a service account with role-based access control (RBAC) is the preferred way to authenticate with Hybrid Cloud Console (HCC). This method is more secure than basic authentication (being deprecated). More information on transitioning from basic authentication to token-based authentication via service accounts can be found on this knowledge base article on the Red Hat Customer Portal.

Our automation requires the creation and configuration of a service account to integrate with Red Hat Lightspeed APIs. We create a dedicated service account for our example from the Service Accounts page in the Identify Management’s settings section of HCC. The process consists of going through a simple wizard and getting a Client Id and Client Secret. These credentials are used in our script to generate an access token using Red Hat’s single sign-on (SSO) technology.

Next, we must grant the required RBAC permissions to perform the requests to read and write on hosts and groups in the Red Hat Lightspeed inventory. The required permissions for our service account are inventory:hosts:read * (can be inherited from Inventory Hosts Viewer role) and inventory:groups:write * (can be inherited from Inventory Groups Administrator role).

We can create a new user group with the Inventory Hosts Viewer and Inventory Groups Administrator roles and assign the service account from the Groups page under User Access.

Now that the service account is created with the required permissions, we can use it from the script to generate an access token and call Red Hat Lightspeed APIs. We store our service account credentials retrieved earlier in a separate /etc/insights-client/creds file. The file should contain the client_id and client_secret value pairs separated by an & character. We restrict access permission to the file with chmod 600.

$ sudo touch /etc/insights-client/creds
$ sudo chmod 600 /etc/insights-client/creds
$ ls -lal /etc/insights-client/creds
-rw-------. 1 root root 94 Apr 22 11:23 /etc/insights-client/creds
$ sudo cat /etc/insights-client/creds
client_id=<client_id>&client_secret=<client_secret>

With the credential file in place, we can now create our main automation script.

Calling Red Hat Lightspeed API to assign systems to inventory groups

Our /usr/bin/assign-group.sh automation script looks for system tags on the /etc/insights-client/tags.yaml configuration file. We search for a tag name containing “group” and use it for the inventory group assignment. This script can be adapted to the organization needs by modifying the GROUP_NAME assignment command.

The script removes the existing group assigned to the system, looks up the targeted group ID by name, and finally assigns the system to the targeted group by ID.

#!/bin/sh
# Assuming TAG_FILE contains a value for the group key
# Alternative would be to simply define the group using GROUP_NAME="My group"
TAG_FILE=/etc/insights-client/tags.yaml
CREDS_FILE=/etc/insights-client/creds
MACHINE_ID=`cat /etc/insights-client/machine-id`
GROUP_NAME=`sed -n -e 's/^group: //p' $TAG_FILE | tail -n 1 | jq -Rr '@uri'`
# Generate token for sandbox.redhat.com
TOKEN=`curl -s -d @"$CREDS_FILE" -d "grant_type=client_credentials" "https://sso.redhat.com/auth/realms/redhat-external/protocol/openid-connect/token" -d "scope=api.console" | jq -r '.access_token'`
# Get system id from machine id
SYSTEM_ID=`curl -s -X 'GET' "https://console.redhat.com/api/inventory/v1/hosts?insights_id=$MACHINE_ID" -H 'accept: application/json' -H "Authorization: Bearer $TOKEN" | jq -r '.results[] | .id'`
# Remove system from existing group
curl -s -X 'DELETE' "https://console.redhat.com/api/inventory/v1/groups/hosts/$SYSTEM_ID" -H 'accept: */*' -H "Authorization: Bearer $TOKEN"
# Get group id from group name
GROUP_ID=`curl -s -X 'GET' "https://console.redhat.com/api/inventory/v1/groups?name=$GROUP_NAME" -H 'accept: application/json' -H "Authorization: Bearer $TOKEN" | jq -r '.results[] | .id'`
# Associate system to group
curl -s -X 'POST' "https://console.redhat.com/api/inventory/v1/groups/$GROUP_ID/hosts" -H 'accept: application/json' -H 'Content-Type: application/json' -H "Authorization: Bearer ${TOKEN}" -d "[ \"$SYSTEM_ID\" ]"

Note that we look up the uuid (or system_id) of the system by calling the inventory/v1/hosts?insights_id=$MACHINE_ID request on the Inventory Hosts API. The uuid is then used in subsequent assignment requests. More details on the Inventory Hosts and Groups API can be found in the product API documentation under Managed Inventory.

We are now ready to validate our process end-to-end.

Putting it all together

Now that all services and scripts are in place, we still need to reload the systemd manager configuration to take into effect the modifications to insights-client-results.path.

$ sudo systemctl daemon-reload

At this stage, we can manually start insights-client.service to validate that our process works end-to-end:

$ sudo systemctl start insights-client.service

Once completed successfully, the /etc/insights-client/.lastupload file is modified and triggers the insights-client-results.path. This executes our new insights-client-automation.service that runs our /usr/bin/assign-group.sh shell script.

We can inspect all log entries stored by systemd in the journal. This should include both insights-client and insights-client-automation execution details. If all is successful, you should see log entries similar to the following:

$ journalctl -f -u insights-client -u insights-client-automation
Apr 22 15:27:41 rhel8desktop systemd[1]: Starting insights Client...
Apr 22 15:27:41 rhel8desktop systemd[1]: Started insights Client.
Apr 22 15:28:04 rhel8desktop insights-client[58558]: Starting to collect Red Hat Lightspeed data for rhel8desktop
Apr 22 15:30:16 rhel8desktop insights-client[58558]: Writing RHSM facts to /etc/rhsm/facts/insights-client.facts ...
Apr 22 15:30:17 rhel8desktop insights-client[58558]: Uploading Red Hat Lightspeed data.
Apr 22 15:30:18 rhel8desktop systemd[1]: Started insights Client Automation when /etc/insights-client/.lastupload has changed.
Apr 22 15:30:18 rhel8desktop sudo[60566]:     root : TTY=unknown ; PWD=/ ; USER=root ; COMMAND=/bin/insights-client --diagnosis
Apr 22 15:30:18 rhel8desktop sudo[60566]: pam_unix(sudo:session): session opened for user root by (uid=0)
Apr 22 15:30:18 rhel8desktop insights-client[58558]: Successfully uploaded report from rhel8desktop to account 5685364.
Apr 22 15:30:18 rhel8desktop insights-client[58558]: View details about this system on sandbox.redhat.com:
Apr 22 15:30:18 rhel8desktop insights-client[58558]: https://console.redhat.com/insights/inventory/6c0bf593-f16b-4bb2-a405-bb6f23b1d198
Apr 22 15:30:19 rhel8desktop systemd[1]: insights-client.service: Succeeded.
Apr 22 15:30:22 rhel8desktop assign-group.sh[60674]: {"id":"00e87dbf-738a-4089-8e74-ed84da7e8149","org_id":"7931872","account":null,"name":"My group","host_count":2,"created":"2024-02-27T12:09:03.992353+00:00","updated":"2024-04-22T13:30:22.524731+00:00"}
Apr 22 15:30:22 rhel8desktop systemd[1]: insights-client-automation.service: Succeeded.

Note that if you run the sudo insights-client command manually, only insights-client-automation service will log entries for the run.

Conclusion

This article described how to extend Red Hat Lightspeed client to run custom automation scripts after insights-client completes. We provided an example of auto-assigning the system to an inventory group by looking up its tags and calling Red Hat Lightspeed APIs. The files in this example are available on a GitHub repository for easy download. With this process in place, one can extend Red Hat Lightspeed client and add custom automation steps required by their company’s operational process.

We are very interested to get your thoughts and feedback on ways to improve and grow our product. Please share your experience with us by using the Feedback form located on the right side of the Hybrid Cloud Console.