I'm just curios how you guys are hiding you api key in the scripting module, are you hashing it in a database or something similar? Just looking for suggestions.
Thanks!
I recommend placing secrets in a json file outside the Ignition install folder (so it won't be caught in backups or GIT) and loading the whole file into a script module top level variable (outside any function, so it caches). This conveniently also makes it easy to have testing secrets in DEV.
1 Like
We use OS environment variables, but how you set them is OS dependent.
On Ubuntu, we tweaked the Ignition-Gateway systemd service to load extra variables from a file that we keep outside of the Ignition folder (like pturmel suggested).
I know this is popular in the devops world, but prevents hiding secrets from privilege escalation attacks. Linux's SELinux framework (and others) can prevent access to file-based secrets and regular process memory even by the root user, but cannot prevent access to a process' environment exposed in /proc/.
I strongly recommend using file-based secrets storage even if you aren't yet using SELinux, so you can migrate to that level of security when you need to. This is particularly important when delegating secrets storage to a external vault, as you must somehow secure the local credentials you use to authenticate to the vault itself.
It's one of the things that makes me unhappy with common practices in Docker. 
Some background:
2 Likes
I'm so used to the idea that "if they have root they have everything" that the concept of "hardening against a compromised root" felt alien at first. But I see your point.
In our case we're halfway there since the secret variables all in a .env file that systemd imports to the environment. We could just turn off the systemd import and make it a scripted import of the same file inside Ignition.
3 Likes