Handling sensitive secrets, passwords or arbitrary data

[justparking]

Nodel doesn't have any ways to conceal and protect sensitive data e.g. API keys, secrets or passwords. Given that all config is stored in JSON config files, it's trivial for anyone who browses a nodel site or who has direct access to the OS to grab copies of any part of the nodel configuration.

This has never been much of a concern since typically all nodel gets to store are low risk AV equipment log-in credentials.

However, more and more I'm finding I'm using Nodel to access web APIs with API-keys, secret tokens, etc. that need to be protected and handled with care.

This is not a problem unique to nodel and I know of several other environments that have ways of dealing it (e.g. github.com actions) but even so, nodel presents some additional challenges given its highly dynamic environment.

I'd like to share a possible "nodel" approach to the problem:

STORAGE WITHIN NODEL

• A set of name/value pairs is kept and persisted on disk in a secure way (not concerned with implementation yet):

  An example representation of the data might be:

  INFLUX_API_KEY: zxefs9TsH7/YPQ+6Q2cL4qmi77wuxvv1CO6eu0U/ogg=
  PANASONIC_PASSWORD: mypanasonic
  ...
  

  It's just a collection of KEY / VALUE string pairs that only Nodel could read and write to.

• Nodel offers the user a mechanism by which these secrets can be stored in one direction only i.e. when a pair is submitted, the VALUE part cannot be retrieved again.

  This would be built into nodel itself and exposed to the user via a browser page or via a recipe or some other means (I'm not sure yet).

  The nodel core framework would be extended to provide some "secret services", an example use being:

  Nodel.secretsService().store(secret_key, secret_value);
  

USE WITHIN RECIPES

• The only way to make use of the VALUE (secret) part would be through select parts of the nodel Toolkit with _using_secrets methods. Some examples I can imagine:

  A web request:

  resp = get_url_using_secrets("http://a.cloud.service.com/api/method", headers= { "x-apikey": "${{INFLUX_API_KEY}}" }, ...

  That shows the secret being using in the HTTP headers which is very common, but it would also support secrets being used in the query string and body (post) data too.

  A TCP request:

  _tcp.send_using_secrets("LOGIN ${{PANASONIC_PASSWORD}}\n")

  Something similar would be available for UDP too. The .sent call handler would be blocked so as to not make it easy to retrieve the secret used.

  A process interaction:

  def reboot_now():
    p = Process('sudo -S reboot now'.split(' '), 
                 stdout=lambda line: console.info("> %s" % line), 
                 mergeErr=True, 
                 started=lambda: p.send_using_secrets("${{RASPPI_PASSWORD}}"))

  This shows a sudo request being implemented with requires the use of a password.

  (sudo -S is highly discouraged of course but it makes for a good example here.)

  SNMP example:

  _target.setCommunity_using_secrets("${{PDU_WRITECOMMUNITY}}")

  Any of the the _using_secrets functions will not be allowed to be executed via the console, only via the scripts.

Given how dynamic and interactive Nodel is there are of course many potentional exploits possible if someone was really determined. However, I do have many ideas on how further strengthing could be done to affect the scope of use, for example:

• limiting the use of a secret to a specific node (or nodes) only
• limiting the use of a secret to a specific target IP addresses only (affects TCP, UDP)
• limiting the use of a secret to a specific HTTP URL path only and optionally insist on HTTPS usage (affects HTTP web requests)
• limiting the use of a secret to a specific toolkit resource e.g. get_url only, TCP only, UDP only, SNMP only, Process only, etc.

This is just a starting point and demonstrates some concepts I had in mind that I wanted to get on paper. The objective of the first iteration would be just to minimise opportunistic or casual exposure of secrets.