I have an IoT app that provides a server backend and browser UI client for interfacing with proprietary control systems. Some deployments of this application will require that the server is not publicly accessible on the internet; instead, the hardware will often be part of a network managed by the end-user. To complicate matters further, some end-users will not have any external internet access provided to the server, whilst others will allow some token-based access on an ad-hoc basis for debugging and maintenance.
The app requires interfacing with public 3rd party APIs, e.g., sending emails (this functionality will not work for the users who will not provide an internet connection to the server). I have already containerised the application with Docker (using
docker-compose, and the API keys are not committed to any version control system.
I understand that securing these keys is difficult, if not impossible, as physical ownership of the server is with the end-user. In light of this, I’d like to know what options and strategies are at my disposal to mitigate the inherently risky deployment solution. I have presented some of my thoughts below.
Option 1: Separate API keys per end-user
One option is to generate a fresh set of secrets for every deployment. E.g. no two end-users use duplicate email API keys. This would allow more fine-grained control of an end-user’s interaction with the 3rd party APIs and respect API provider rate limiting.
The obvious disadvantage to this is it does not scale well. Haven’t to maintain
m keys for every
n end-users seems though it could grow out of control quickly.
Option 2: Commissioning the physical server in-house
We can deploy the application ourselves on the end-user’s hardware before physically shipping it to the deployment location. In some cases, this is unavoidable as we cannot always remotely access the server to deploy the app.
I’d like to know of any other options this opens up for addressing my issue.
Option 3: All 3rd party interactions are routed through a public middleman service
A publicly hosted service could be used to handle all of the external API connections. For example, the deployed application doesn’t ever interact with the emailing API directly. Instead, it fires a message to this middleman service to send the email, and receives a message if and when the email is sent. Does anything like this already exist, or is this a case of rolling your own? I would prefer avoiding having to add extra infrastructure if possible.