A few thoughts:
Real Time Updates
- Runtime changes in era of OpenShift become less and less important
as configuration should be immutable. Runtime changes should be
addressed on OpenShift level. At least in past some of my "runtime
changes" issues were denied with this argument.
This is certainly something to consider when considering any new management functionality.
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.
- If this will be decided to accomplish I think it is enough when
updates take in action on explicit administrator command.
Support for Expressions
- Really question here is if vault wasn't misused as external
configuration storage for standalone.xml holding environment
properties on one place. Which could be more convenient as specifying
bunch of system properties. If so we should address this feature
separately - way to specify configuration property file for server
standalone.xml.
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.
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. ;)
- If purpose is to really treat different arguments as security
sensitive then proposed encryption/decryption way seems promising to
me.
On Wed, Sep 26, 2018 at 3:22 PM Darran Lofthouse
<darran.lofthouse@jboss.com> wrote:
>
> 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.
>
> 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.
>
> I have put together a blog post describing some of the general issues we want to look into: -
>
> http://darranl.blogspot.com/2018/09/wildfly-elytron-credential-store-next.html
>
> Some of these changes will have an impact on any subsystem currently referencing the credential store.
>
> 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.
>
> I am also going to share this link in the community forums to try and obtain some additional feedback from end users.
>
> Regards,
> Darran Lofthouse.
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
_______________________________________________
wildfly-dev mailing list
wildfly-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/wildfly-dev