Wildfly (bootable or standalone) and environment variables and @DataSourceDefinition?

[Fred Welland]

My test bed is WF 36.0.1.Final.   

I do have this:   

   /subsystem=ee:write-attribute(name=annotation-property-replacement,value=true)

in my standalone or my BWF cli  (also verified via spelunking in generated BWF artifact).   

I tried multiple variations of (in a ApplicationScoped .java file) :  

@DataSourceDefinition(
name = "java:/SillyDS",
className = "blah.blah",
url = "hard coded for testing",
user = "${env.DB_USER}",
password = "hardcoded for testing"
)

Also tried this:  

user = "${DB_USER}",

Also I have a startup observer that prints out  System.getenv("DB_USER")    -- value is there and set to the expected thing.   

It doesn't seem like @DataSourceDefinition can do this type of ENV var expansion in BWF (hollowed) or standalone WF.  Or perhaps I am doing something wrong?   

NOTE:  

I don't think it is related, but I also set it to 'true'  the following:   'jboss-descriptor-property-replacement' and 'spec-descriptory-property-replacement'  .   

AND, the syntax: 

"${env.DB_USER}"

works as expected using WF CLI constructs.   Or better said, defining an instance level datasource will grab/expand env vars.   

[Eduardo Martins]

Hi Fred, ATM that is not supported, we need to use a property replacer when retrieving those values from the annotation.

Actually it's simple to change, e.g.

directDataSourceInjectionSource.setUser(propertyReplacer.replaceProperties(AnnotationElement.asOptionalString(annotationInstance, DataSourceDefinitionInjectionSource.USER_PROP)));

Wanna contribute this? 

—E

PS: the changes should be discussed first with Tomasz the component lead, in cc

--
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/CAGO%3D3NYfbm%2By072RTpFU8PFGHdKbRjkUbpVv-fJe6d75nSVHaQ%40mail.gmail.com.

[Fred Welland]

Wow,  thanks for the quick response.   And I may try to see where I can help.   

That said,  this @DataSourceDefinition 'adventure' was a bit of a detour away from my real goals:  

1. stop having credentials stored in file artifacts (in clear, or hashed/encrypted) on some compute device or vm
2. 'teach' applications to be resilient to credentials rotations w/o restarts or redeploys

The first item isn't too hard to resolve, there are a couple patterns that can help.  Actually, the clear text pwds are a bigger problem; just using a credential store will go a long way and is a easy pivot. 

The 2nd item is a bit more challenging.   I've got some foggy ideas on solutions for that.   And solving this item will probably eliminate the 1st.  Any input on this is welcome.  

The whole detour into the annotation was in response to some in my engineering ranks mumbling about CLI configurations being 'complicated' and was trying to give them some options. 

[Eduardo Martins]

I don’t know a good solution with those 2 requirements, point 2 kind of goes against point 1, but it’s definetely an interesting topic :-)

—E

[Fred Welland]

Thanks again for your input. 

For the first, I will probably just do something simple like some shell scripting to fetch creds from our credentials store (it is just AWS SecretsManager) and then inject the creds into the environment at WF/BWF startup.   

The latter, I am still pondering.     My group uses Quarkus a fair amount too.   The DB Credential provider idiom from Quarkus covers much of what I am looking for;  if I can find a solution a bit like that, but for WF/BWF I'd be happy.  

-Fred 

[Fred Welland]

I thought I would share a small update related to this thread. 

There is (it's been around for a bit) a JDBC proxy driver from AWS that grabs some credentials from SecretsManager, prior to submitting to a down-stream JDBC driver. 

Learn about it here:   https://github.com/aws/aws-secretsmanager-jdbc

So I was able to POC this:  

1. hand crafted a WF module with this driver (and transitives) and my real, oracle, driver
2. slip-streamed that module into my bootable image via  <extra-server-content-dirs/>  (is there a better way to do this???)
3. used cli to make a JDBC driver using this module and its proxied SM/JDBC driver
4. used cli to make a data-source using this driver
5. made a ridiculously simple JSF app, with a single JDBC action to issue a query and display some data. 

This works for the happy day case.    So this, at least, lets the POC grab creds from AWS SM;  fwiw.      

Takeaways from this: 

• Still fundamentally using all the pooling and connection management provided by WildFly  NOTE: the proxy driver can use its own pooling device (via Cp3o) -- maybe relevant in some use cases; however I desired for WildFly to be in charge of pooled connections so didn't activate any of that. 
• No pwd/creds in ENV or sys properties.   
• I have no idea what happens if the SM record changes (i.e. password rotate) and if this 'thing' will adapt to that.  I just haven't tested that yet.   (Does it 'cache' SM data; fetch every time; what???) 
• Paints into corner a bit; besides just being for AWS SM; doesn't look like there is any sort of 'override' or 'disable' for development and/or  uses w/o AWS SM  (w/o alternate DS and/or driver) 
• Haven't tested under stress  (yeah, AWS SM has throttling and other limits -- what is the interaction of these things and subjects that might choose to use this) 
• The AWS SM/JDBC driver uses parts of the AWS JAVA SDK.  So that needs to be included as part of the module.   The 'full' AWS SDK  (v2) can be quite large.  This proxied driver probably doesn't need the full SDK v2 -- but I didn't take time to slim it down.   

YMMV -- I am not advocating for or against this thing.   Just sharing my experiment.     I don't even know if my organization will use this or not.   

Have fun!