Is there any documentation or examples on how to use the environment variables GATEWAY_ENCODING_KEY and GATEWAY_ENCODING_KEY_FILE? We are using Ignition 8.1.38 and are hoping to be able to use these environmental variables to pass database credentials in a JDBC connection.
1 Like
The "encoding key" is a by default hardcoded key in the software that is used to obfuscate credentials stored inside the internal database, a SQLite file.
Since approximately forever, you've been able to specific a different encoding key via a JVM arg, i.e. in your ignition.conf file. But that's not very friendly for containerized applications, which is why new support for environment variables was added in 8.1.38.
This is all a bit moot, though; proper credential management using external secret stores is planned for Ignition 8.3.
Also, if it's not clear, this encryption key doesn't directly relate to any particular use such as a DB connection in Ignition - it's a single secret that is used to hash every credential stored in the internal DB.
Regarding this change. If we replace the encoding key, with an existing gateway, the system hashes the code with the new key, or will required to reenter the passwords?
I don't think modifying this key for an existing Ignition Gateway is supported - it must be set before any development begins.
2 Likes
IA have plan to have a migration process? If I need to replace the key, without needing to setup a new gateway?
No, this whole mechanism will be deprecated in 8.3 and a proper secrets management solution will be introduced.
2 Likes
Is this JVM arg documented somewhere? (Need it for an older gateway version)
I only see it documented as Docker env variable. What do you need to know?
I am injecting some stuff into the IDB of a gateway in a container pre-8.1.38 and need to set a custom encoding key for it
I might be misunderstanding this, but I seem to read this as its possible with whatever this JVM arg would be
You can set -DencodingKey=whatever in the ignition.conf additional args.
But that encoding key already would have been set in that container, so I'm not sure what you're really doing here... the encoding key cannot be set retroactively or all existing encoded secrets will stop working.
1 Like
It's actually for a new container, not an old one, it just happens to be in the older version. So it shouldn't be set yet when my container starts up
1 Like