Thank you Daniel. This provides me with some capability, but I can’t seem to consume the result in the configuration, I just get lots of errors. The issue seems to be that the value of the define, passed via -A doesn’t seem to be processed in anyway. I’ve had a quick look in the cfg.lex and cfg.y files, but that’s the first time delving into Flex etc. so I’m not sure I’m following it correctly. I’ve tried every combination of encapsulation of the parameters in single and double quotes I can think of i.e. -A DBURL=“…”, -A “DBURL=…”, all with the same result. I also tried #!subst "/DB_URL/DBURL/g” but that doesn’t seem to expand out the DBURL define. In short, I’m stumped… Any further thoughts would be truly appreciated. I’ve put a few error details in the mail below. I’m feeling that I may need to resort to changing the behaviour of the subst directive to meet my needs (more likely, add substvar, substfromfile or some such). Any further thoughts would be truly welcome, otherwise I think I’m going to have to dig out my dusty K&R book and roll my sleeves up… Sincere thanks in advance for any ideas. Cheers - Robert... ------------------------------------------------------------------------------------------------------------------------- In the configuration file, I have failures for example on: modparam("htable", "db_url", DBURL) when launched with the -A results in: 0(7) DEBUG: <core> [core/cfg.lex:1838]: pp_define_get(): ### returning define ID [DBURL] value [oracle://username:password@/DB <oracle://username:password@/DB>] 0(7) CRITICAL: <core> [core/cfg.y:3431]: yyerror_at(): parse error in config file /usr/local/etc/kamailio/kamailio.cfg, line 97, column 30-35: syntax error 0(7) CRITICAL: <core> [core/cfg.y:3431]: yyerror_at(): parse error in config file /usr/local/etc/kamailio/kamailio.cfg, line 97, column 30-35: Invalid arguments 0(7) CRITICAL: <core> [core/cfg.y:3434]: yyerror_at(): parse error in config file /usr/local/etc/kamailio/kamailio.cfg, line 97, column 36: ERROR: bad config file (3 errors) I’ve tried with #!subst but it seems that pre-processor directive doesn’t expand out defines, so: #!subst "/DB_URL/DBURL/g” modparam("htable", "db_url", DB_URL) just results in: 0(7) INFO: <core> [core/ppcfg.c:82]: pp_subst_add(): ### added subst expression: /DB_URL/DBURL/g 0(7) DEBUG: <core> [core/re.c:436]: subst_run(): running. r=1 0(7) DEBUG: <core> [core/re.c:504]: subst_str(): no match 0(7) DEBUG: <core> [core/re.c:436]: subst_run(): running. r=1 0(7) DEBUG: <core> [core/re.c:504]: subst_str(): no match 0(7) DEBUG: <core> [core/re.c:436]: subst_run(): running. r=1 0(7) DEBUG: <core> [core/re.c:504]: subst_str(): no match 0(7) DEBUG: <core> [core/re.c:436]: subst_run(): running. r=1 0(7) DEBUG: <core> [core/re.c:504]: subst_str(): no match 0(7) DEBUG: <core> [core/re.c:436]: subst_run(): running. r=1 0(7) DEBUG: <core> [core/re.c:504]: subst_str(): no match 0(7) DEBUG: <core> [core/re.c:436]: subst_run(): running. r=1 0(7) DEBUG: <core> [core/re.c:504]: subst_str(): no match 0(7) CRITICAL: <core> [core/cfg.y:3431]: yyerror_at(): parse error in config file /usr/local/etc/kamailio/kamailio.cfg, line 97, column 30-35: syntax error 0(7) CRITICAL: <core> [core/cfg.y:3431]: yyerror_at(): parse error in config file /usr/local/etc/kamailio/kamailio.cfg, line 97, column 30-35: Invalid arguments 0(7) CRITICAL: <core> [core/cfg.y:3434]: yyerror_at(): parse error in config file /usr/local/etc/kamailio/kamailio.cfg, line 97, column 36: ERROR: bad config file (3 errors)

On Wed, Nov 15, 2017 at 08:46:58AM +0100, Daniel-Constantin Mierla wrote: ... My guess is the next problem will be the password being visible to all users querying the processlist :) Is including a file (import_file) with passwords an option? Generate the file just before startup, remove it (ofcourse in a secure way (shred the file and overwrite all freespace with a multiple patters a few dozen times (ask the auditors for the exact specifications that make them happy))) after kamailio is running.

Hello Jurijs, Thank you for the link, Docker secrets is definitely something that would be an option, and yes, holding anything in a variable or somewhere it can be easily queried isn’t going to work. We’ll see what happens. Cheers - Robert...

isn't using a group in the db URL an option? Generate some .cnf in /etc/mysql/conf.d (or where MySQL searches its configuration in a Docker container) from the secret and use the group in your db URL in kamailio.cfg. http://www.kamailio.org/docs/modules/5.0.x/modules/db_mysql.html#idp419 97212 On Thu, 2017-11-16 at 20:22 +0000, Robert wrote:

Hi Robert, I'm not security expert and I'm quite new in docker, but I think password in Docker container which will be in clear text saved somewhere should not be a problem, as far as you do not save this password to image or git and etc... I think best way for you is to use docker secret and generate then config file for Kamailio using this docker secrets and then start Kamailio and for all of this you need to write some kind of Entrypoint script. Here is example how something similar do Homer Sipcapture, they set environment variables in docker-compose and then generate config file based on this, but you can use probably docker secrets instead of environment variables: https://github.com/sipcapture/homer-docker/tree/master/kamailio I found one more interesting link regarding docker secrets: https://blog.mikesir87.io/2017/05/using-docker-secrets-during-development/ With kind regards, Jurijs On Thu, Nov 16, 2017 at 11:58 PM, Robert &lt;robert(a)vooey.co.uk&gt; wrote:

Hello Daniel, Sincere apologies for the tardy reply! There are lots of challenges I’ll face, but fortunately I only need to secure the application, it is for others to worry about preventing platform access etc. (but on the hardened OS, I’d be amazed if gdb was available ;). The -f - solution may be what is the best approach. Thank you. Robert.

On 16.11.17 10:34, Daniel Tryba wrote: Indeed, this is a valid concern in this context. Right, a better option with the included file that can be removed. With the default kamailio.cfg, one can generate kamailio-local.cfg in the same folder with kamailio.cfg and inside kamailio-local.cfg can have: #!define DBURL "...." One kamailio is started, the file can be removed. On the other hand, if the file is accessible only by root user and nobody can see it, removing won't add much protection, maybe just for long term when server is dismissed and it's good not to have a file with such content. Because someone with root access can deploy gdb and then attach to a running kamailio processes and read values from its memory... Cheers, Daniel -- Daniel-Constantin Mierla www.twitter.com/miconda -- www.linkedin.com/in/miconda Kamailio Advanced Training - www.asipto.com Kamailio World Conference - May 14-16, 2018 - www.kamailioworld.com