# Secrets management **URL:** \ **Category:** Ignition\ **Created:** [January 13, 2021, 2:53pm UTC](https://forum.inductiveautomation.com/t/secrets-management/42205 "2021-01-13T14:53:14Z")\ **Posts on this page:** 10\ **Page:** 1
**Author:** ![shakeel.rajwani](https://avatars.discourse-cdn.com/v4/letter/s/e480ec/32.png) [@shakeel.rajwani](https://forum.inductiveautomation.com/u/shakeel.rajwani)\ **Post date:** [January 13, 2021, 2:53pm UTC](https://forum.inductiveautomation.com/t/secrets-management/42205/1 "2021-01-13T14:53:14Z")
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. ---
**Author:** ![zacht](https://avatars.discourse-cdn.com/v4/letter/z/ea5d25/32.png) [@zacht](https://forum.inductiveautomation.com/u/zacht)\ **Post date:** [January 13, 2021, 4:44pm UTC](https://forum.inductiveautomation.com/t/secrets-management/42205/2 "2021-01-13T16:44:14Z")
Potentially relevant. > [@Good way to make sure my gateway scripts only run on the server?](http://forum.inductiveautomation.com/t/good-way-to-make-sure-my-gateway-scripts-only-run-on-the-server/33777): > > More of a design question than anything. I have gateway scripts, some of which involve emailing our companies clients. On occasion, I’ve had coworkers unknowingly backup the gateway to a development machine with an old database copy, and then all of a sudden our clients are getting emails with outdated information that they already received. Not great. Currently I’ve been telling people to not export/import gateway scripts, but there are other scripts that don’t involve emails that are essen… ---
**Author:** ![wking](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/wking/32/21823_2.png) [@wking](https://forum.inductiveautomation.com/u/wking)\ **Post date:** [January 13, 2021, 4:52pm UTC](https://forum.inductiveautomation.com/t/secrets-management/42205/3 "2021-01-13T16:52:30Z")
+1 for environment variables. ---
**Author:** ![pturmel](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pturmel/32/3295_2.png) [@pturmel](https://forum.inductiveautomation.com/u/pturmel)\ **Post date:** [January 13, 2021, 4:55pm UTC](https://forum.inductiveautomation.com/t/secrets-management/42205/4 "2021-01-13T16:55:41Z")
> [@wking](#): > > +1 for environment Trolling me? Environment variables are terrible places to put secrets. ---
**Author:** ![bkarabinchak.psi](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/bkarabinchak.psi/32/83567_2.png) [@bkarabinchak.psi](https://forum.inductiveautomation.com/u/bkarabinchak.psi)\ **Post date:** [January 13, 2021, 4:58pm UTC](https://forum.inductiveautomation.com/t/secrets-management/42205/5 "2021-01-13T16:58:17Z")
I’m the person who made that post. You see @pturmel and @paul-griffith 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. ---
**Author:** ![paul-griffith](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/paul-griffith/32/37249_2.png) [@paul-griffith](https://forum.inductiveautomation.com/u/paul-griffith)\ **Post date:** [January 13, 2021, 5:00pm UTC](https://forum.inductiveautomation.com/t/secrets-management/42205/6 "2021-01-13T17:00:16Z")
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 `print`ing or logging the secret values - by definition, if they’re exposed to a scripting function they’re exposed to anyone with a designer. I have a toy example of what that might look like here: > **[paul-griffith/secret-keeper](https://github.com/paul-griffith/secret-keeper)** > > Toy, incomplete Ignition proof-of-concept module to store secrets in the IDB - paul-griffith/secret-keeper ---
**Author:** ![shakeel.rajwani](https://avatars.discourse-cdn.com/v4/letter/s/e480ec/32.png) [@shakeel.rajwani](https://forum.inductiveautomation.com/u/shakeel.rajwani)\ **Post date:** [January 13, 2021, 5:51pm UTC](https://forum.inductiveautomation.com/t/secrets-management/42205/7 "2021-01-13T17:51:44Z")
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. ---
**Author:** ![ron.sherrod](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/ron.sherrod/32/27007_2.png) [@ron.sherrod](https://forum.inductiveautomation.com/u/ron.sherrod)\ **Post date:** [October 10, 2023, 2:30am UTC](https://forum.inductiveautomation.com/t/secrets-management/42205/8 "2023-10-10T02:30:52Z")
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](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/secrets-envvar-secrets-manager.html#secrets-examples) Then the actual secret can only be referenced by a host that has the proper roles to access the aws secret? ---
**Author:** ![Mehdi\_MECHEDAL](https://avatars.discourse-cdn.com/v4/letter/m/58956e/32.png) [@Mehdi\_MECHEDAL](https://forum.inductiveautomation.com/u/Mehdi_MECHEDAL)\ **Post date:** [September 4, 2025, 9:51am UTC](https://forum.inductiveautomation.com/t/secrets-management/42205/9 "2025-09-04T09:51:03Z")
Could you please share the built module, I think there is some dependency issues in your repository. ---
**Author:** ![paul-griffith](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/paul-griffith/32/37249_2.png) [@paul-griffith](https://forum.inductiveautomation.com/u/paul-griffith)\ **Post date:** [September 4, 2025, 3:27pm UTC](https://forum.inductiveautomation.com/t/secrets-management/42205/10 "2025-09-04T15:27:55Z")
No. The module was never intended for use in actual deployments, and in a future update to our new version, Ignition 8.3, we're adding first party scripting functions to interact with secret management, including third party providers. The underlying primitives there will be significantly more secure by nature than the incomplete module I created in an afternoon years ago. The code is open source - you are welcome to figure out how to build it yourself. I would discourage you from doing so - that's why I 'archived' the repository.