Page History
Security Secrets (Reference) : let you securely store sensitive values such as passwords or keys. These secrets can then be reused in Datasets and Device/TagProvider configurations without exposing plain-text credentials.
Security Secrets provide:
- Centralized storage of credentials
- Integration with Datasets (DB connections)
- Integration with Device/TagProviders (MQTT, OPC UA, etc.)
- Administrative control — only admins can edit SecretValue
On this page:
Table of Contents maxLevel 2 minLevel 2 indent 10px exclude Steps style none
Configuration Properties
Each Secret has the following properties:
PropertyDescriptionRequired
NameUnique identifier for the secretYes
SecretTypeDefines type of secret (e.g., Password)Yes
SecretValueEncrypted credential valueYes
DescriptionOptional notes or purposeNo
Only administrators can edit SecretValue. Standard users can reference existing secrets but not view them.
Example
| Name | SecretType | SecretValue | Description |
|---|---|---|---|
| Secret1 | Password | ****** | Used for Runtime Users DB connection |
Usage in Configuration
- In Datasets, select Secret instead of a raw password to bind connection strings.
- In Device/TagProviders (MQTT, OPC UA, etc.), reference secrets using
/secret-<name>. - Secrets allow safer credential management and support configuration portability.
Example: Assigning Secret1 to RuntimeUsers database login password.
Best Practices
- Create secrets centrally in Security → Secrets.
- Always prefer Secret over plain passwords in datasets and devices.
- Restrict edit permissions — only admins should manage secret values.
- Use descriptive names for clarity (e.g.,
DBRuntimePassinstead ofSecret1). - Document secret usage in the Description field for auditability.
In this section...
| Page Tree | ||||
|---|---|---|---|---|
|
Overview
Content Tools
Tasks