Today some of the sensitive information like root password, user passwords, cluster token can likely make it to the JVM arguments via arguments like -Darcadedb.server.rootPassword, -Darcadedb.server.defaultDatabases, -Darcadedb.ha.clusterToken.

• The risk with -Darcadedb.server.rootPassword can be mitigated with -Darcadedb.server.rootPasswordPath
• The default database can be provisioned post cluster setup
• But the shared secret for inter node authentication -Darcadedb.ha.clusterToken needs to be supplied at the time of cluster startup.

I know a workaround has been suggested here: https://docs.arcadedb.com/arcadedb/how-to/operations/secrets
But a simpler option for now is to have the cluster token accepted in a file and pass the file location as system argument like -Darcadedb.ha.clusterTokenPath

Or better way forward would to have the server started with a configuration file which has all the system properties that are getting passed today to com.arcadedb.server.ArcadeDBServer. The users of arcadeb can generate the configuration file on the fly during startup and make it live on ephemeral container storage (which is considered safer on the lines of Kubernetes secrets being mounted onto files on ephemeral container storage)