Managing your Customer Devices as a Service Provider in Azure

Imagine your company, Zava Robotics, deploys robots to your customers factories
and retail stores. You would like to

• collect robot telemetry data and diagnostics logs for monitoring, troubleshooting,
  and maintenance.
• deploy updates to the robots and the edge system that the robots connect to.
• manage all your customers' systems centrally, remotely, and securely.

Your customers, on the other hand, would like to

• keep their data in their tenant.
• have control over their Azure cloud resources.
• not having to take the burden to manage robots, so they are ok to have
  have Zava manage their robots, and send selective datasets to Zava.

This repo helps demonstrate one approach to achieve these requirements:

1. Use Azure Lighthouse to enable Zava to access a resource group in the
   customer's Azure subscription upon the customer's consent.
2. Provision a Kubernetes cluster on the edge, Arc enable it, and deploy
   Azure IoT Operations (AIO) to the cluster.
3. Send telemetry data from the robots to the AIO MQTT broker,
   and use AIO Data Flow to send the data to the cloud.
4. Use GitOps to deploy apps from Azure to the edge.

All resources and data remain in the respective customer's Azure subscription, unless explicitly configured to send to Zava.
Zava has a centralized view of all their customer deployments without having
to switch to each customer's tenant to perform tasks.

The rest of this README focuses on the first three capabilities.
The last bullet about deployment is out of scope, but you can find
GitOps for Arc enabled Kubernetes docs.

Azure Lighthouse to enable a Service Provider to access resources in a customer's tenant

Azure Lighthouse
is a technology that projects a customer's Azure resources
to the Service Provider's tenant. In a nutshell, this is how it works:

• The Service Provider specifies the following in a template
  and parameters:

  • the resources they need access to,
  • the Entra ID principals who need to access the resources,
  • the roles or level of access they need.

• The Customer reviews the above request, and if agrees, deploys this
  template to their Azure subscription.

  Note: This deployment must be done by a non-guest account in the customer's tenant who has a role with
  the following permissions: Microsoft.Authorization/roleAssignments/write Microsoft.Authorization/roleAssignments/delete Microsoft.Authorization/roleAssignments/read

  az deployment sub create \
    --name <deploymentName> \
    --location <AzureRegion> \
    --template-file <path/to/templateFile> \
    --parameters <path/to/parameterFile>

• The customer can now see their Service Providers in the Azure Portal,
  along with what the service provider is authorized to do.
  

• The service provider can see their Customers in their Azure portal,
  along with the resources they are granted access to, without switching tenant.
  

Azure Arc and Azure IoT Operations to manage edge devices

Now that Zava has access to the customer's resource group, they can
provision and Arc enable the customer's edge cluster and install AIO,
all using Infrastructure as Code in this Edge-AI Accelerator.

Send data from the edge to the cloud

Not only can Zava access the customer's Azure portal, once AIO is installed,
Zava can also access the IoT operations experience portal from https://iotoperations.azure.com.
While configuring devices, assets, and data flows can be done programmatically,
both Zava and the customer can use the operations portal to manage these resources
in a low-code no-code way.

AIO Dataflow comes with many out-of-the-box connectors as shown below.

You can easily transfer data from edge to the cloud, or optionally filter,
transform the data on the edge before sending to the cloud.

To simulate the robots, this repo provides two mock services:

• mockhttp provides a REST GET endpoint so you can configure an AIO Device with a HTTP/REST connector.
• mockmqtt directly sends data to AIO MQTT broker.

Note: You can send data to the customer's Fabric tenant or the service
provider's Fabric. However, the service provider cannot access the customer's
Fabric tenant without explicitly being granted additional permissions.
If the customer decides to disable Lighthouse, they also need to disable
the dataflow that sends data to the service provider's tenant if any,
and revoke Fabric access to the service provider.

Troubleshooting tips and known issues

• If you use AIO Asset as the data source in a data flow, make sure your source data is in the topic azure-iot-operations/data/<asset-name>.
  Otherwise, explicitly specify the topic of your data source.
• At the time of this writing, a service provider cannot access a customer's
  Microsoft Fabric portal or AIO Grafana dashboard with just Lighthouse.