Introduction of the optional authentication mechanism for Labgrid (i.e. Oauth2) for securing gRPC communication between coordinator, client, exporter

[JacekBartynowski]

Hello,

I work for ARM Ltd.
We are planning to use the Labgrid for our testing and releases purposes (part of the build and CI/CD pipelines).

Currently, the main obstacle from our perspective (commercial organization) is the lack of an authentication/authorization.
I am aware that the Labgrid is an open-source, publicly available product that can be adapted by many organizations/projects, and the authentication/authorization mechanism may not be the desired thing.

I would like to get your opinions about the potential introduction of the authentication mechanism to secure a communication between the labgird-client(s), labgrid-cooridnator, and labgrid-exporter. The gRPC protocol provides many options to configure and use authentication.

The potential authentication mechanism would probably be OAuth2 with the external authentication provider (like Github, Google, Microsoft, Facebook, etc.), the mechanism would require to:

• Obtain the SSO (single-sign-on) token from the external authentication provider (OAuth2, OpenID based solution)
• Obtain SSL certificates (file system, remote storage solution like vault, etc.)

The scope of changes would probably include:

• adding selector mechanism to apply/use/configure the authentication or skip it
• adding functionality to obtain SSO token (OAuth2, OpenID standard)
• adding functionality to obtain SSL certificate(s)
• changes in labgrid/remote/client.py
• changes in labgrid/remote/coordinator.py
• changes in labgrid/remote/exporter.py

If possible, I would like to learn your opinions and views on:

• Possibility of adding optional (i.e. configurable via command line arguments) authentication mechanism
• Selection of the potential authentication mechanism
• Probable timeline of reviewing/accepting and releasing the modifications related to the authentication
• Maybe you consider any other authentication mechanism in the past?
  ?

[Emantor]

Hi,

I'd like you to know that we have read your questions and need to discuss this internally before posting an answer, thanks for your patience.

[jluebbe]

For now, we've tried to keep the complexity in labgrid low by relying on network- and SSH-level authentication to restrict access to our labgrid instance. I understand that in some scenarios, not all users of a labgrid instance should have access to all places.

At a high level, we have mainly three kinds of connections that might need authentication:

1. client to coordinator via gRPC (for an interactive user or a CI run)
2. exporter to coordinator
3. client to exporter via SSH

For 1., I think token based authentication makes a lot of sense. The token can be passed as headers in gRPC and checked by the coordinator. I don't really have an opinion how the coordinator would check the token and then authorized the client for specific resources, so I'd be open to suggestions. The client could use a system-wide configuration to select some Python backend module which is then used to acquire a token from SSO (or from somewhere else).

For 2., SSO doesn't really seem applicable, as the exporter runs as a service, without any specific (human) user being involved. So, perhaps a fixed token or TLS client certificates would be more appropriate.

In a scenario with authentication, direct TCP connection to PDUs or other resource would likely be block by a firewall, so all actual control of the DUT would happen via SSH. Either by executing commands (fastboot, dd, imx-usb-loader, ...), uploading and running labgrid Python agents or by configuring port forwards. Perhaps this can be solved by assigning short-lived SSH certificates to clients after they have locked a place which allows targeted access to only that related resources on that exporter. There are open questions, though:

• use one or multiple UNIX users on the exporter?
• create UNIX users dynamically and remove them after unlock (perhaps using systemd's homed or something similar)
• restrict access to devices in /dev using ACLs or UNIX groups?

[JacekBartynowski]

thank you for your reply, I will prepare answers and get back to this discussion