One way I handled this in the past (though I'm not overly fond of the solution since it relied on AWS, but it would be interesting if there was a generic way to achieve it), was to use AWS KMS and role based authentication. This way the instance could decrypt it's password from the ec2 instance it was located on without having to store a master password. As I mentioned, it relied on AWS which I prefer to avoid as much as possible. I wrote a configuration listener that would detect properties that had an encryption tag surrounding it and it would then use KMS to decrypt them on the fly as needed. Not sure if this is useful at all, but just in case I figured I'd mention it. :)
Ryan On Mon, Feb 19, 2018 at 9:28 AM Alex Weirig <alex.wei...@technolink.lu> wrote: > OK then it might make sense to add the decrypt support. > > > > Schéin Gréiss, > Mit freundlichen Grüßen, > Meilleures salutations, > Kind regards, > > Alex WeirigResponsable Technique > > Ville de Luxembourg - Centre Technolink2, rue Charles de Tornaco > <https://maps.google.com/?q=2,+rue+Charles+de+Tornaco&entry=gmail&source=g> > L - 2623 luxembourgalex.wei...@technolink.lu > > > Tel: +352 4796 - 6127 <+352%2047%2096%2061%2027> > > > Fax: +352 42 88 81 <+352%2042%2088%2081>www.technolink.lu > > On 19/02/2018 15:20, Jean-Baptiste Onofré wrote: > > As most of Karaf committers are also Pax * projects contributors, I think > it's a > fair request. > > However, Pax JDBC already provides such feature: it's part of pax-jdbc-config > already (in the DataSourceConfigManager). It uses an embedded encryption > service > (not the one provided by Karaf), but it's basically what you need. > > My point was more for your application or finding a generic way. > > Regards > JB > > On 02/19/2018 03:05 PM, Alex Weirig wrote: > > Before we go ahead and add the decrypt feature, would the maintainers of e.g. > PAX JDBC etc be interested in adding support for this in their services? > > > Schéin Gréiss, Mit freundlichen Grüßen, Meilleures salutations, Kind regards, > > Alex Weirig > Responsable Technique > > Ville de Luxembourg - Centre Technolink 2, rue Charles de Tornaco > <https://maps.google.com/?q=2,+rue+Charles+de+Tornaco&entry=gmail&source=g> L > - 2623 > LUXEMBOURG alex.wei...@technolink.lu <mailto:alex.wei...@technolink.lu> > <alex.wei...@technolink.lu> Tel:+352 4796 - 6127 <+352%2047%2096%2061%2027> > Fax: +352 42 88 81 <+352%2042%2088%2081> www.technolink.lu > <http://www.technolink.lu> <http://www.technolink.lu> > > On 19/02/2018 14:03, Jean-Baptiste Onofré wrote: > > Yes, that would work but it requires: > > 1. either a change at ConfigAdmin layer (difficult and not accurate IMHO) > 2. a Karaf service that application (like Pax JDBC) can leverage when a > {CRYPT}hash{CRYPT} property value pattern is detected. > > Karaf JAAS already has EncryptionService providing encryption only. We have > two > implementation of this service: > - Basic (BasicEncryptionService) > - Jasypt (JasyptEncryptionService) > > I can extend the EncryptionService to also provide decrypt and check. > > Regards > JB > > On 02/19/2018 01:56 PM, Alex Weirig wrote: > > That's correct and that's what I'm trying to solve (or work around). > > E.g. > > I need to store my mysql password in the config file. The password is 1234pwd. > > Imagine we have a karaf command that's config:encrypt. > > I use config:encrypt 1234pwd and it returns a hash, this hash would computed > using a master password that would be different for each karaf instance based > on > it's "environment". > > Now when ConfigAdmin reads the configuration file it will know how to compute > the master password and decrypt the password and use the decrypted password > (1234pwd) with the datasource or JDBC connection. > > Since there would be no "API" to do this decryption "by hand" nobody would > "easily" be able to get access to the decrypted password. > > I'm currently looking if each karaf instance has some kind of a GUID or if > there > is some kind of GUID available from the system or something else that could be > used to compute the instance related master password. > > So basically the idea is to make the decryption "configuration" a system > feature? > > Schéin Gréiss, Mit freundlichen Grüßen, Meilleures salutations, Kind regards, > > Alex Weirig > Responsable Technique > > Ville de Luxembourg - Centre Technolink 2, rue Charles de Tornaco > <https://maps.google.com/?q=2,+rue+Charles+de+Tornaco&entry=gmail&source=g> L > - 2623 > LUXEMBOURG alex.wei...@technolink.lu <mailto:alex.wei...@technolink.lu> > <alex.wei...@technolink.lu> Tel:+352 4796 - 6127 <+352%2047%2096%2061%2027> > Fax: +352 42 88 81 <+352%2042%2088%2081> www.technolink.lu > <http://www.technolink.lu> <http://www.technolink.lu> > > On 19/02/2018 13:44, Jean-Baptiste Onofré wrote: > > Hi Alex, > > The problem is the "direction". > > Let me take an example: the encryption service we have to crypt passwords in > etc/users.properties. > Here's the direction is pretty simple: the user provides the password, we > encrypt the password using the configuration defined in > etc/org.apache.karaf.jaas.cfg and we compare the hashes: if the hash is the > same > as the one contained in the etc/users.properties, then, it's OK. > > But the user provides his password. > > In any cfg configurations, it's the opposite: the application (let's say > pax-jdbc or your own application) expects the property value in clear text > whereas it's stored encrypted. So, it means that somehow we have to start from > the encrypted property value to provide the clear text one. > For instance, you are using pax-jdbc for datasources. You want to store the > database password encrypted in the cfg file. However, to actually establish > the > connection, we have to use the password in clear text. So, we have to decrypt. > > So a generic solution at ConfigAdmin layer would require decrypt->clear > direction which obviously require the decryption "configuration". > > Regards > JB > > On 02/19/2018 01:31 PM, Alex Weirig wrote: > > Hi Jean-Baptiste, > > that sounds like an interesting idea but you are pointing at an obvious > drawback > with these solutions... > > If we're using a "master password" (like jasypt) we need to provide this > master > password in order to allow decryption of the password. That master password > has > to be available in clear text but then, at the end of day you're only > protecting > your environment against "hackers" that are able to "hack" you systems but > "too > stupid" to decrypt the password using the master password. > > Possibly storing the password in a file with limited ownership access rights > might help a little bit but if the hacker has (root) access he will get around > that too. > > I was thinking if it would be possible to create a "karaf password encryption > feature" where each karaf instance would have it's own computable (since we > can't store it) "master password" (maybe based on a machine identifier) and > would allow you to encrypt the password but there would be no "API or utility" > to allow the user to decrypt the password. > > Now the "hacker" would need more knowledge to get access to the passwords ... > > Schéin Gréiss, Mit freundlichen Grüßen, Meilleures salutations, Kind regards, > > Alex Weirig > Responsable Technique > > Ville de Luxembourg - Centre Technolink 2, rue Charles de Tornaco > <https://maps.google.com/?q=2,+rue+Charles+de+Tornaco&entry=gmail&source=g> L > - 2623 > LUXEMBOURG alex.wei...@technolink.lu <mailto:alex.wei...@technolink.lu> > <alex.wei...@technolink.lu> Tel:+352 4796 - 6127 <+352%2047%2096%2061%2027> > Fax: +352 42 88 81 <+352%2042%2088%2081> www.technolink.lu > <http://www.technolink.lu> <http://www.technolink.lu> > > On 19/02/2018 08:03, Jean-Baptiste Onofré wrote: > > Hi Alex, > > We can imagine to add a feature that detect property values with a pattern > (for instance {CRYPT}hash{CRYPT}) and decrypt the value (so it has to be a > symetric encryption to allow to decrypt). > > I already thought about a Karaf ConfigAdmin "interceptor" to do that. But it > has to be at ConfigAdmin level to be reliable. > > Jasypt works that way assuming you are in blueprint (it provides a blueprint > specific namespace that decrypt the property values at blueprint:cm level). > > Regards > JB > > On 19/02/2018 07:52, Alex Weirig wrote: > > Thank you very much to everybody who responded to my question. > > I will have a look at your recommended approaches. > > Schéin Gréiss, Mit freundlichen Grüßen, Meilleures salutations, Kind regards, > > Alex Weirig > Responsable Technique > > Ville de Luxembourg - Centre Technolink 2, rue Charles de Tornaco > <https://maps.google.com/?q=2,+rue+Charles+de+Tornaco&entry=gmail&source=g> L > - 2623 > LUXEMBOURG alex.wei...@technolink.lu <mailto:alex.wei...@technolink.lu> > <alex.wei...@technolink.lu> Tel:+352 4796 - 6127 <+352%2047%2096%2061%2027> > Fax: +352 42 88 81 <+352%2042%2088%2081> www.technolink.lu > <http://www.technolink.lu> <http://www.technolink.lu> > > On 10/02/2018 21:06, Jean-Baptiste Onofré wrote: > > True, but jasypt namespace is blueprint specific. > > Outside of blueprint (directly in ConfigAdmin), you have to use your own > wrapper. > > Regards > JB > > On 02/10/2018 05:32 PM, Ryan Moquin wrote: > > You can still put the placeholders in a config file without using > blueprint, but > you need them injected into something that will resolve those > placeholders. In > this case, the only thing I can suggest offhand (and it's not hard), would > be to > use a Configuration listener (I think that's the name of the interface, > it's for > listening to when. PID is available in configuration admin), then when your > config becomes available, you check for the encrypted properties and decrypt > them. You'd have to retrieve the encryption service via your listener. > That is > probably how Blueprint does it. > > Ryan > > > On Sat, Feb 10, 2018, 9:22 AM Weirig, Alex > <alex.wei...@technolink.lu<mailto:alex.wei...@technolink.lu> > <alex.wei...@technolink.lu>> wrote: > > Hello, > > I wonder if there is a way to use the jasypt feature in Karaf 4.1.4 to > encrypt passwords in configuration files without having to define the > placeholders using Blueprint but rather using a cfg file in /etc/? > > All the examples I've found so far are rather "old" and still rely on > Blueprint ... I'm not using Blueprint at all in my applications and I > would > appreciate if I didn't have to use it just for this configuration. > > If it was possible to define these placeholders in a cfg file in /etc/ it > would make things easier ... or is there even an easier way to support > encrypted properties with the current Karaf releases? > > Thank you very much for your support > > --- > > Schéin Gréiss, > Mit freundlichen Grüßen, > Meilleures salutations, > Kind regards, > > Alex Weirig > Responsable Technique > > Ville de Luxembourg - Centre Technolink > 2, rue Charles de Tornaco > <https://maps.google.com/?q=2,+rue+Charles+de+Tornaco&entry=gmail&source=g> > > <https://maps.google.com/?q=2,+rue+Charles+de+Tornaco&entry=gmail&source=g> > <https://maps.google.com/?q=2,+rue+Charles+de+Tornaco&entry=gmail&source=g> > L - 2623 LUXEMBOURG > alex.wei...@technolink.lu <mailto:alex.wei...@technolink.lu> > <alex.wei...@technolink.lu> > > Tel: +352 4796 - 6127 <+352%2047%2096%2061%2027> > Fax: +352 42 88 81 <+352%2042%2088%2081> > www.technolink.lu <http://www.technolink.lu> <http://www.technolink.lu> > > >
