<div dir="ltr"><div class="gmail_default" style="font-family:trebuchet ms,sans-serif"><br></div><br><div class="gmail_quote"><div dir="ltr">On Tue, Dec 4, 2018 at 12:31 PM Martin Choma <<a href="mailto:mchoma@redhat.com">mchoma@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">A few thoughts:<br>
<br>
Real Time Updates<br>
- Runtime changes in era of OpenShift become less and less important<br>
as configuration should be immutable. Runtime changes should be<br>
addressed on OpenShift level. At least in past some of my "runtime<br>
changes" issues were denied with this argument.<br></blockquote><div><br></div><div class="gmail_default" style="font-family:"trebuchet ms",sans-serif">This is certainly something to consider when considering any new management functionality.</div><div class="gmail_default" style="font-family:"trebuchet ms",sans-serif"><br></div><div class="gmail_default" style="font-family:"trebuchet ms",sans-serif">Another thing to consider is what services are going to utilize any real-time update? Are there many resources that respond to a credential attribute value change (e.g. write-attribute) without triggering reload-required? If they do trigger reload-required it seems likely that's because making a new value take effect was considered to be too difficult compared to the gain. In an immutable world the gain is likely even less.</div><div class="gmail_default" style="font-family:"trebuchet ms",sans-serif"></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
- If this will be decided to accomplish I think it is enough when<br>
updates take in action on explicit administrator command.<br>
<br>
Support for Expressions<br>
- Really question here is if vault wasn't misused as external<br>
configuration storage for standalone.xml holding environment<br>
properties on one place. Which could be more convenient as specifying<br>
bunch of system properties. If so we should address this feature<br>
separately - way to specify configuration property file for server<br>
standalone.xml.<br></blockquote><div><br></div><div class="gmail_default" style="font-family:"trebuchet ms",sans-serif">I hope people aren't using a vault just for that. If you want to group together properties you can use bin/standalone.sh -P. On OpenShift you can mount a ConfigMap as a source of env var values, and env vars are used in expression resolution.</div><div class="gmail_default" style="font-family:"trebuchet ms",sans-serif"><br></div><div class="gmail_default" style="font-family:"trebuchet ms",sans-serif">I could imagine people sticking a username in a vault just because they put the password in the vault and administratively it was simpler to manage the two related values together. No idea if that's really done; I just can imagine it. ;)</div><div class="gmail_default" style="font-family:"trebuchet ms",sans-serif"><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
- If purpose is to really treat different arguments as security<br>
sensitive then proposed encryption/decryption way seems promising to<br>
me.<br>
<br>
On Wed, Sep 26, 2018 at 3:22 PM Darran Lofthouse<br>
<<a href="mailto:darran.lofthouse@jboss.com" target="_blank">darran.lofthouse@jboss.com</a>> wrote:<br>
><br>
> During WildFly 15 and WildFly 16 I am looking at the next stages for credential store development based on a few feature requests we have not handled yet.<br>
><br>
> We are at the stage where this development is likely to affect multiple areas of the application server, additionally we need to consider these requests as a set so we don't take a decision for one that prevents us working on the remainder.<br>
><br>
> I have put together a blog post describing some of the general issues we want to look into: -<br>
><br>
> <a href="http://darranl.blogspot.com/2018/09/wildfly-elytron-credential-store-next.html" rel="noreferrer" target="_blank">http://darranl.blogspot.com/2018/09/wildfly-elytron-credential-store-next.html</a><br>
><br>
> Some of these changes will have an impact on any subsystem currently referencing the credential store.<br>
><br>
> Other changes we will need to decide if the solution lies within WildFly Elytron, the management tier of the server, or the admin tools - or possibly a combination of all three.<br>
><br>
> I am also going to share this link in the community forums to try and obtain some additional feedback from end users.<br>
><br>
> Regards,<br>
> Darran Lofthouse.<br>
> _______________________________________________<br>
> wildfly-dev mailing list<br>
> <a href="mailto:wildfly-dev@lists.jboss.org" target="_blank">wildfly-dev@lists.jboss.org</a><br>
> <a href="https://lists.jboss.org/mailman/listinfo/wildfly-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/wildfly-dev</a><br>
_______________________________________________<br>
wildfly-dev mailing list<br>
<a href="mailto:wildfly-dev@lists.jboss.org" target="_blank">wildfly-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/wildfly-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/wildfly-dev</a><br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr">Brian Stansberry<div>Manager, Senior Principal Software Engineer</div><div>Red Hat</div></div></div></div>