Thanks, JB, here it is:

https://issues.apache.org/jira/browse/KARAF-6733 
<https://issues.apache.org/jira/browse/KARAF-6733>

Best regards,
Alex soto




> On May 27, 2020, at 12:16 AM, Jean-Baptiste Onofre <[email protected]> wrote:
> 
> Hi Alex,
> 
> That’s a good idea about file.
> 
> Can you please create a Jira about that ?
> 
> Regards
> JB
> 
>> Le 26 mai 2020 à 19:57, Alex Soto <[email protected] 
>> <mailto:[email protected]>> a écrit :
>> 
>> Thank you Mike,
>> 
>> Still finding this too complex and less secure solution to an arguably 
>> common problem (at least when using Docker).  Currently, I can have the 
>> following in a configuration file:
>> 
>>      org.ops4j.pax.web.ssl.password=${env:MYPASSWORD}
>> 
>> And,  as the documentation states:
>> 
>>> Environment variables can be referenced inside configuration files using 
>>> the syntax ${env:<name>} (e.g. property=${env:FOO} will set "property" to 
>>> the value of the enviroment variable "FOO"). 
>> 
>> Karaf will use the value from the environment variable; however, with this 
>> approach, the secret is replicated/copied in two places, 1) the default 
>> location '/run/secrets/‘ put there by Docker engine, and in the environment 
>> variable. 
>> 
>> I suppose one can think of simpler Karaf mechanism to inject values from 
>> files in config files. For example, 
>> 
>>      org.ops4j.pax.web.ssl.password=${file:/run/secrets/mypassword}
>> 
>> So, when Karaf’s see the prefix $file:  it will get the content of the file 
>> and use it as the value of the configuration key.
>> This way, 1) I don’t have to write a complex script to copy the secret into 
>> the environment variable and 2) the secret is only in one place.
>> 
>> Best regards,
>> Alex soto
>> 
>> 
>> 
>> 
>>> On May 24, 2020, at 7:27 AM, Mike Hummel <[email protected] 
>>> <mailto:[email protected]>> wrote:
>>> 
>>> Hi Alex,
>>> 
>>> I understand that you should not use the '-e' flags for secrets. A common 
>>> way is to define the secret file with an environment flag and load it. And 
>>> in this way you can sopport both. Environment and secrets.
>>> 
>>> A nice sample is 
>>> https://github.com/docker-library/wordpress/blob/master/docker-entrypoint.sh
>>>  
>>> <https://github.com/docker-library/wordpress/blob/master/docker-entrypoint.sh>
>>> 
>>> Regards,
>>> 
>>> Mike
>>> 
>>> 
>>>> On 19. May 2020, at 18:22, Alex Soto <[email protected] 
>>>> <mailto:[email protected]>> wrote:
>>>> 
>>>> Thanks Mike,
>>>> 
>>>> Yes, that would work, but wasn’t the secret mechanism added precisely to 
>>>> avoid the unsafe environment variables?
>>>> 
>>>> 
>>>> Best regards,
>>>> Alex soto
>>>> 
>>>> 
>>>> 
>>>> 
>>>>> On May 18, 2020, at 2:57 PM, Mike Hummel <[email protected] 
>>>>> <mailto:[email protected]>> wrote:
>>>>> 
>>>>> Hi,
>>>>> 
>>>>> store your secrets as bash script with
>>>>> 
>>>>> key=value
>>>>> 
>>>>> and include the secret in your start script 
>>>>> 
>>>>> . /run/secrets/credentials.sh
>>>>> 
>>>>> Now the secrets are available as shell environment.
>>>>> 
>>>>> Regards,
>>>>> 
>>>>> Mike
>>>>> 
>>>>> 
>>>>>> On 5. May 2020, at 22:16, Alex Soto <[email protected] 
>>>>>> <mailto:[email protected]>> wrote:
>>>>>> 
>>>>>> I found using Docker Secrets a convenient a way to protect passwords 
>>>>>> when running Docker containers.  I know I can reference an environment 
>>>>>> variables in Karaf's config files, but that is not very secure, or at 
>>>>>> least less secure than secrets.  For example, to configure a key store 
>>>>>> in the Pax Web config file: org.ops4j.pax.web.cfg one would need to 
>>>>>> provide a value for key org.ops4j.pax.web.ssl.password.  The problem is 
>>>>>> how to reference a secret, which is a file, as the value of this  
>>>>>> property?  In other words, I am looking for something like:
>>>>>> 
>>>>>>  org.ops4j.pax.web.ssl.password=$(cat /run/secrets/keystorepass)
>>>>>> 
>>>>>> Is there anything similar or planned? 
>>>>>> 
>>>>>> (Same would be useful to configure the JAAS users in users.properties, 
>>>>>> etc.)  
>>>>>> 
>>>>>> Best regards,
>>>>>> Alex soto
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>>> 
>> 
> 

Reply via email to