I do a lot of API integrations, and right now I’ve got API authentication information in plain text in my scripts - however this is not a best practice. I’m wondering if there is a way to put secrets into a vault or key store in Ignition that I can reference in my scripts to tighten up my security.
+1 for environment variables.
Trolling me? Environment variables are terrible places to put secrets.
I’m the person who made that post. You see @pturmel and @PGriffith go back and forth on this. I had originally done it with environment variables at first since it was the first suggestion, but if I had to do it again, it would be a .json file no question. Much easier to manage, create, edit, other people I work with who aren’t as into OS’s would understand what I mean if I gave them a filepath, and it is not polluted with all your other environment variables that have nothing to do with ignition.
Having said that I’m still with the initial environment variable set up and it works fine. Not broke, not fixing it.
There is a ticket in our backlog to allow for Ignition-based storage of secrets, which I guess would be retrieved with some scripting function…but that’s only one step removed from putting them plaintext, because nothing stops you from
I have a toy example of what that might look like here:
Hi Paul, thanks for the response and example. I think there there may be ways to redact secrets to prevent them from being printed or logged in plain text, but I’ll have to investigate that myself.
I have recently started to incorporate more API keys into my ignition integration. Along the lines of leveraging environment variable but obscuring, them has anyone tried leveraging environment variables but making them reference AWS secrets in secrets manager? Using Secrets Manager - Amazon Elastic Container Service
Then the actual secret can only be referenced by a host that has the proper roles to access the aws secret?