Wildfly Elytron Credential Store integration with AWS Secret Manager

[Gabriel Padilha]

Hello Wildfly folks,

I just want to share a personal project that I have started in order to integrate AWS Secret Manager in the Wildfly Elytron subsystem via credential store.

If you are interested in using or if you would like to contribute, feel free.

Here is the link to the project if interested: https://github.com/gabrielpadilh4/elytron-aws-secrets-store

[Iason Filippou]

Hi Gabriel, this is quite interesting. Right now in our application we have encoded all the secrets in our various standalone.xml files using the Elytron subsystem. If we want to add a new secret, we have to run the jboss-cli.sh and type something like /subsystem=elytron/expression=encryption:create-expression(resolver=main-resolver, clear-text=MyPassword). This has proven to be a bit error-prone with things such as spaces, quotes, double-quotes, etc. Additionally, Elytron does not offer a way to unencrypt the expression through the jboss cli, and the only way for us to view the cleartext secrets for any kind of debugging, we have to run our application locally and have it print out the values of some properties through source code.

With this approach, am I correct in assuming that there is no need to ever use the Wildfly Elytron subsystem to encrypt our passwords? Can we just store our cleartext secrets in AWS secrets manager and, if one wants to find those cleartext passwords, they just have to log in through the UI of secrets manager (which is of course password and MFA-protected) and view them that way, instead of editing source code with print-outs and running the application locally?

--
You received this message because you are subscribed to the Google Groups "WildFly" group.
To unsubscribe from this group and stop receiving emails from it, send an email to wildfly+u...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/wildfly/641ed33d-e88a-4847-8296-920d6805372fn%40googlegroups.com.

[Fred Welland]

In my case, not really a management problem, more of a security policy to centralize keys/passwords/secrets in some sort of centralized 'vault'  as well as support password rotations (i.e. changes) in ways that apps require little or no maintenance or experience little or no impacts when credentials change.    At present AWS SecretManager is our 'vault' device. 

This module seems to at least cover the first part:  centralized vault.   I am testing this out right now; after looking at the source, I feel it probably will cover that portion of my needs.    Rotating passwords adds some other interesting dimensions to the problem (and a much deeper problem than just reading passwords from AWS SM).   

All that said -- and this is nothing for or against this module  -- simply just sharing some things I have learned:    AWS has a passthru JDBC driver that delegates JDBC connection authorization to a SM record.      You can find out more about it here:    https://github.com/aws/aws-secretsmanager-jdbc  .   

I have deployed as a module  and configured datasources to use this driver and pretty much does what it says:   gets credentials from a SM, but otherwise delegates to a JDBC driver.    It doesn't do anything magical about credentials rotations (that I can tell).   

I am thinking this module and the AWS SM/JDBC driver are about the same in this regard.   

HTH...

FWIW

Transparent handling of credentials rotations is a bit more involved. That said, I have a mostly working solution for Quarkus.  However, I tried to tap into CDI things mostly while building it, so that elements of the Quarkus solution can work in Wildfly too.    In other words:   have my Wildfly & Quarkus apps, just run, always get their DB credentials from SM and allow the credentials to be updated in SM and the apps just continue to work with no impact or need to restart or reconfigure and such..    

To view this discussion visit https://groups.google.com/d/msgid/wildfly/CAAzY8DQxbRV0u%2BWqVH4fFMuM-9rBEq37jJA2a_TpLP4oEgPW9Q%40mail.gmail.com.

[Fred Welland]

Oh and sorry to answer your question(s).   

If you put your credentials in SM.  They are encrypted at rest in AWS.    When you fetch them,  you get back the clear text  (not the cipher text).    This Elytron module just uses the AWS SDK to fetch that SM record (so there is no local copy of credentials (clear or encrypted)  on the Wildfly host/properties file/xml config file/etc) , which come back in the clear; the running code/app just needs permissions/iam policies to use SM (and/or specific SM keys).  

HTH

[Darran Lofthouse]

Gabriel,

This sounds very interesting, how would you feel about contributing a blog post about it?

https://wildfly-security.github.io/wildfly-elytron/blog/

https://github.com/wildfly-security/wildfly-elytron/tree/develop

--

[Gabriel Padilha]

Hello, thank you for your feedback.

@Iason: The idea here is not to replace the Elytron functionality l, but extend it with AWS Secret Manager within a minor effort.

@Fred: When I found out about the Secret Manager JDBC, for me it seems it has a limitation that you can just use it for a datadource. As I'm extending the Elytron capabilities, my goal is to allow Secret Manager secrets to be used with the other resources that has a credentials reference. Not only datasources, but also keystore passwords, mail subsystem and more.

@Darran: I will love to write something about it, will submit a PR with the post in the next days.

Thank you!

[Fred Welland]

Terrific point about broader applicability of this SM Elytron module (vs that AWS SM/JDBC driver).     Some of my WF apps, use remote AMQClassic brokers and have the same forthcoming credential handling needs.

FWIW:   I stuffed this module in a WF 38 experiment; and it worked as advertised.     (Using the bootable WF variant or technique, BTW). 

TX! 

To view this discussion visit https://groups.google.com/d/msgid/wildfly/2b62e945-c695-4b9a-9013-e03fe2e6f26dn%40googlegroups.com.

[Gabriel Padilha]

Thanks @Fred, amazing!

[Gabriel Padilha]

Hello @Darran, here is the blog pull request: https://github.com/wildfly-security/wildfly-elytron/pull/2370