Currently, there can be only 1 instance of a specific AVEVA Adapter on each server if Docker is not used. However, within that instance, multiple components and data sources can be configured. This is convenient, but then the service account for the AVEVA Adapter needs permissions to all of the data sources, which gives that account quite a lot of access. PI Connectors (both generations) suffer from the same issue, but since those are no longer actively being developed, I will not focus on them.
In contrast, each instance of a PI Interface was its own service, and the service account for each service could be different, allowing for finer control over permissions. Please allow multiple instances of a specific AVEVA Adapter to exist on the same server. Then we will have the option to configure each instance with just a single component, and each instance can have a different service account, which can in turn have different permissions.
Below are some of the current solutions to this problem and the problems with those solutions:
Some AVEVA Adapters, such as the AVEVA Adapter For RDBMS, allow you to specify the account that should be used to connect to the data source. However, this requires storing the account's password and sending it to the data source each time a connection needs to be made. Even though the password is encrypted, this is not as secure as using Kerberos authentication with the AVEVA Adapter's service account, which does not involve storing or transmitting passwords at all. Also, this method is unfriendly with gMSAs, whose passwords change automatically and frequently. Part of the point of gMSAs is that people do not need to interact with the account's password.
Another solution is to install an AVEVA Adapter on multiple servers, and each instance can have its own service account this way. However, spreading AVEVA Adapters across multiple servers makes them difficult to manage. This solution might also require the addition of new servers, which is resource-intensive and adds more servers to manage. The number of servers doubles if you also want to configure failover for these instances. On the plus side, having only 1 important thing on each server minimizes the disruption if any 1 server goes down.
Docker would allow multiple instances of a specific AVEVA Adapter to exist on the same server because each instance would be isolated in its own container, unaffected by the other containers. However, this solution is supported only on servers that run Debian-based distributions of Linux, and the AVEVA Adapter documentation warns that you should be proficient with Docker to use this approach. If Debian-based distributions of Linux are not already used by a customer, then it might be difficult to get IT to check over the new operating system, approve it for use, and document how to maintain the new server, and actually maintain that server. If the stars align, this is the best and most feasible of the current solutions, but the IT departments of some customers might find the barrier to entry to be too high for this solution to be worth pursuing.
If this suggestion gets implemented, it would provide a solution (though not necessarily the best solution) to the suggestions below:
