Open vincent-zurczak opened 9 years ago
Applications templates whose configuration relies on properties should put a env.properties file under the descriptor directory. When an application is created from this template, Roboconf will copy this file into Karaf's etc/roboconf directory.
Environment properties follow this convention:
They should be edited manually.
They will be injected as environment variables in plug-ins (on the agent's side). And they will be injected through string replacement in target properties. ${var_name}
is the notation to follow. By convention, such variables should have their name starting with env_
.
There should a new parameter in the DM to customize the location of these parameters.
env.location = ${KARAF_ETC}/roboconf
OK, that's fine for storage. However, we should identify all the cases we want to handle.
These files specify identifiers for cloud infrastructures. They are used by the DM. So, what we want is to replace variables in these files. We do not need real environment variables here. It is text replacement from our properties files.
Let's consider the credentials to access a database. Let's assume they are exported as variables by a Roboconf component.
MySQL {
installer: script;
export: ip, port = 3306, user = a23df, pwd = fd5f!df5z5d9tt;
}
With the previous post, it would look like...
MySQL {
installer: script;
export: ip, port = 3306, user = ${MYSQL_USER}, pwd = ${MYSQL_PASS};
}
... with the following properties (e.g. in global.properties).
MYSQL_USER = a23df
MYSQL_PASS = fd5f!df5z5d9tt
This solution avoids to put credentials in the graph (sources) files. But so that it works on the agent side, the agent needs this information too. The first option would be to update the variable values in the instances when we send them to the agent. Since the agent passes component variables as environment variables, no issue. And agents do not persist their model anywhere. So, these variables will only be persisted in one location.
Since this solution works and is easy to implement, no need to look for another one. :smiling_imp:
There are many articles now to warn about using environment variables to store passwords. Some solution, like Hashicorp Vault or Ansible Vault (for Ansible) may be used. But this does not depend on Roboconf. It depends on the application architecture and developer works (to query sensitive information from these tools). So, these tools are alternative solution to environment variables and should be mentionned on our web site.
The mechanism can be used for both secrets (credentials) and environment settings (e.g. static information such as IP addresses).
I keep on thinking about it... In fact, we should not replace properties in instances when we send the model to agents. Otherwise, everytime agents exchange information, these properties will go through the messaging server. We should limit their traffic.
Environment variables should be sent to agents only once, when their model is sent. And recipe information should be replaced only when they are about to be executed.
Guess what... We will postpone this issue once again. There is no more question, we just have to do it. But we would like to release at the beginning of January.
Properties for applications could also be written in a file, rather than being passed as environment variables. However, it might now be safer than environment variables. In k8s, such files have their content encoded with Base64. It is also possible to set the file permissions.
Some properties, like credentials, must be kept secret. They are also dependent of the environment. Developement, tests, pre-production, production, production site... can be various environments in which a same application can run.
Roboconf must provide a mechanism to handle these cases.