A single company often operates a number of sensors distributed between installations. These installations can be independent both in development and deployment, requiring some consideration for how access rights are managed.
Where different installations are separated by project, one method may be to simply manage the access rights from within the project itself. By creating Service Accounts within projects as required, with different roles, only the required access needs to be granted.
This would allow all projects to be independent of each other in regard to access rights. For a Service Account to access an installation, the credentials for that specific project would have to be obtained. This allows for much more granular control at the expense of some management.
Similar behavior to Project-Isolated Access could also be achieved by instead having a single project dedicated to Service Account management. Here, multiple Service Accounts would be created in a single project and given a role in different projects depending on the task they’re going to perform.
In terms of granularity of control, the result is much the same as having Service Accounts in the related projects. However, depending on how the task of managing the access rights falls within the organization, this method may prove to be simpler in terms of generating an overview of who can access what.
In cases where Company A provides a service to Company B, an exchange of access rights may be necessary. Service Accounts can be used to accomplish this in a safe manner.
We have here created a mock situation where Company A would like to provide a monitoring and alerting service to Company B and Company C.
Company A creates a project with an accompanying Service Account for each of their clients, Company B and C.
The credentials for these Service Accounts are copied to the monitoring system which will use the Service Accounts to fetch data through the REST API.
Company A provides Company B and C with the respective Service Accounts email addresses and requests that they create a member with sufficient access. Company B gives project-level access rights as only a few projects are to be monitored. Company C gives organization-level access, allowing Company A to fetch data from all projects.
Afterward, Company A’s monitoring system will be able to log in using the Service Accounts and list both the projects and the sensors within them, then fetch data as they see fit. For Company C which gave organization-level access, Company A is also allowed to create and delete projects, move devices between all the projects, and invite new members to the organization.
This approach would allow both the service provider, Company A, and its customers to be in control. Company B and C can at any time revoke access to Company A in their respective projects by removing the Service Account members. Likewise, Company A is in a position where it can invoke security routines such as rotating key-ids at will.
Company A could also use a single Service Accounts residing in its inventory project. This would simplify management as the same Service Account Email would be handed out to all clients. While simpler, this could make the probability of mixing clients higher, though it does not come at the expense of security as it is the member created by the clients themselves that are used to fetch data in the monitoring service, keeping them isolated.