[GH-ISSUE #518] TacticalRMM console storage for Environmental Variables available to scripts and agents. #326

Closed
opened 2026-03-02 02:15:28 +03:00 by kerem · 3 comments
Owner

Originally created by @wiicode on GitHub (May 18, 2021).
Original GitHub issue: https://github.com/amidaware/tacticalrmm/issues/518

Is your feature request related to a problem? Please describe.
When doing script work I occasionally need system unique variables, or even secrets, passed to a machine. This may be something like a special value unique to the system (local) or something like a generic URL to a resource (global).

Describe the solution you'd like
I would like each config on the webUIX side to have an Environment Variables section, much like AWS does for Elastic Beanstalk, where I could store parameters and even secrets. I would like that storage to obfuscate and hash the variables, and then decrypt them locally for usage when needed. They would respond just like all other environment variables. Actually, it would be great if it had a set of globals, org-level globals, and local (per agent) tiers to really help functionality.

Describe alternatives you've considered
So far I've had to rely on encrypted key files, local system environment variables, or bad practices. It's a pain in either case and often extremely risky.

Additional context

Originally created by @wiicode on GitHub (May 18, 2021). Original GitHub issue: https://github.com/amidaware/tacticalrmm/issues/518 **Is your feature request related to a problem? Please describe.** When doing script work I occasionally need system unique variables, or even secrets, passed to a machine. This may be something like a special value unique to the system (local) or something like a generic URL to a resource (global). **Describe the solution you'd like** I would like each config on the webUIX side to have an Environment Variables section, much like AWS does for Elastic Beanstalk, where I could store parameters and even secrets. I would like that storage to obfuscate and hash the variables, and then decrypt them locally for usage when needed. They would respond just like all other environment variables. Actually, it would be great if it had a set of globals, org-level globals, and local (per agent) tiers to really help functionality. **Describe alternatives you've considered** So far I've had to rely on encrypted key files, local system environment variables, or bad practices. It's a pain in either case and often extremely risky. **Additional context**
kerem closed this issue 2026-03-02 02:15:28 +03:00
Author
Owner

@bradhawkins85 commented on GitHub (May 18, 2021):

Global Keystore: https://wh1te909.github.io/tacticalrmm/functions/keystore/
or Custom Fields https://wh1te909.github.io/tacticalrmm/functions/custom_fields/
Might be what you are looking for.
Not sure if it obfuscate and hash the variables but it would probably be a start.

<!-- gh-comment-id:843014441 --> @bradhawkins85 commented on GitHub (May 18, 2021): Global Keystore: https://wh1te909.github.io/tacticalrmm/functions/keystore/ or Custom Fields https://wh1te909.github.io/tacticalrmm/functions/custom_fields/ Might be what you are looking for. Not sure if it obfuscate and hash the variables but it would probably be a start.
Author
Owner

@wiicode commented on GitHub (May 18, 2021):

thanks @bradhawkins85 , I may be caught up in the semantics, but custom fields I see as only useful to TacticalRMM whereas environment variables are useful to the instance. Say I had a software that needed to retrieve a license key, it could do it from an env variable independently of the agent/rmm.

<!-- gh-comment-id:843105302 --> @wiicode commented on GitHub (May 18, 2021): thanks @bradhawkins85 , I may be caught up in the semantics, but custom fields I see as only useful to TacticalRMM whereas environment variables are useful to the instance. Say I had a software that needed to retrieve a license key, it could do it from an env variable independently of the agent/rmm.
Author
Owner

@sadnub commented on GitHub (May 20, 2021):

You can save data into custom fields and inject that data into scripts as arguments. You can even use collector tasks to save data from agents to a custom field.

So the script args would be like -API_KEY {{global.API_KEY}} and the value in the database will be replaced.

Since we are using args the script itself can be used on any platform.

Let me know if that covers your use case.

<!-- gh-comment-id:844620693 --> @sadnub commented on GitHub (May 20, 2021): You can save data into custom fields and inject that data into scripts as arguments. You can even use collector tasks to save data from agents to a custom field. So the script args would be like -API_KEY {{global.API_KEY}} and the value in the database will be replaced. Since we are using args the script itself can be used on any platform. Let me know if that covers your use case.
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
starred/tacticalrmm#326
No description provided.