LAA Connections
**LAA Components and Ethernet Connections** The LAA is pre-registered at the factory prior to shipment leaving no configuration options requiring setup unless your network doesn't support DHCP. If DHCP is unsuccessful, you must follow [these instructions](https://docs.lavacloud.io/guides/connectivity.html#without-dhcp) found in the Guides → LAA Connectivity section to set up a static IP address. The Linaro cloud infrastructure includes services to manage LAAs and the corresponding LAVA cloud instance that coordinates the execution of tests on the DUT. The ONELab infrastructure is accessible over port 443 (the default port for HTTPS, encrypted for secure communication) for example. Once the LAA connects to the LMS cloud instance, it activates a local "worker container" that establishes outbound HTTPS connections to Linaro servers. These connections request test jobs for the DUT attached to the LAA. Specifically, the LAA periodically sends outbound requests to LAVA and the fleet management service on port 443 to check for tasks. These tasks may come from the ONELab Managed LAVA Server, which assigns tests, or from ONELab Managed Services, which handle updates and operational requests. Once the LAA connects, customers can request test jobs through a Linaro Remote Labs front end such as the ONELab UI. This interface is not hosted on the LAA itself but can be accessed from any location, provided the user has the necessary login credentials. Test results are available through the authenticated, user-accessible remote UI within the infrastructure. By default, results are restricted to the user's account unless the authorized user explicitly grants permission to make them public. ## S/W running on the LAA and DUT The LAA SIB OS is a Yocto-based Linux distribution maintained by Linaro. The DUT will run the software provided by the user in customer defined tests. ## Network Protocol Usage The LAA communicates with the cloud-based Linaro test infrastructure exclusively over HTTPS. During operation, it sends HTTPS requests to both the Test Server (LAVA) and LMS every 20s via https for remote configuration and scheduling jobs.to check for queued test or administrative tasks. The LAA downloads test workloads based on [LAVA job definitions](https://docs.lavasoftware.org/lava/first-job.html#first-job-definition), which specify where to fetch test suites and images for execution. Since all test workloads are externally hosted, the LAA does not connect to any local resources within the lab where it is installed. During operation, the LAA can be expected to connect to well-known external sites defined in the LAVA job definitions and to the ONELab managed services such as: - https://(\*.)[lavacloud.io](http://lavacloud.io) (ostree/firmwares/\...) - The ONELab LAVA server [https://iotil.validation.linaro.org/](https://iotil.validation.linaro.org/) - Debian official APT repositories - Docker hub - External repositories where workloads exist and are needed for test (a Commercial Linux ISO for example) ### Network Topology Summary - LMS Cloud-based Server network - Inside an access-controlled cloud network with firewalling - https server is in a public network - Other services are in a private network - LAA network - Inside a customer lab network - No access from the public internet to the LAA - LAA initiates the connection to the cloud server or external sites as defined above - No need to open any port on the firewall/proxy - HTTPS only (443) - Can also be located in a less restrictive network such as home office or customer lab. - DUT network access - LAA and DUT share a private network - Only 2 devices in this network: LAA and DUT - DUT cannot access any urls outside the private network ## LMS service status LMS plans to provide service uptime and service availability status page. This has yet to be implemented in the initial release. ## How S/W updates are supported The LAA itself supports automated updates. When an LAA software update is available, the update proceeds without user intervention as directed by LMS. ## LMS System Architecture The previous content focused on the LAA itself, but it is also important to consider its role in ONELab's infrastructure from a security perspective. ONELab is a cloud-based embedded test environment designed as a Private Cloud solution. While its components are distributed across multiple facilities, access to ONELab assets is strictly limited to authorized users. The only exception is the Public Dashboard, which displays test results explicitly designated for public viewing. Figure 1 provides a high-level overview of the solution. The primary security vulnerability is the Authenticated User Interface, a risk Linaro has addressed by integrating the latest Authentication Providers to minimize the attack surface. Access to the LAA is restricted to authenticated users, who can only view their test results and managed platforms, without broader access to the overall infrastructure. **Upcoming Feature:** ONELab is planning to introduce remote access to the LAA for developers who are not physically co-located with the platform. This feature will serve two key purposes: 1\. **Support Access** -- When a system requires assistance, authorized Linaro Support personnel can securely access the LAA for troubleshooting. Remote support is a common practice for such systems. 2\. **Developer Console Access** -- Developers will be able to remotely access their platforms (DUTs) for debugging. This will be facilitated through an HTTPS tunnel, granting console access to the LAA, followed by UART/USB access to the DUT. In both cases, remote access will be restricted to authenticated users based on role-based permissions. Additionally, all inbound traffic to the LAA will be initiated through outbound HTTPS requests from the LAA itself, ensuring a controlled and secure connection. {width="6.3in" height="4.5in"}LAA Security Boundary