[wildfly-dev] WildFly Elytron - Credential Store - Next Stages

[Brian Stansberry]

On Tue, Dec 4, 2018 at 12:31 PM Martin Choma <mchoma at redhat.com> wrote:

> 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 at 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 at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/wildfly-dev
> _______________________________________________
> wildfly-dev mailing list
> wildfly-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>


-- 
Brian Stansberry
Manager, Senior Principal Software Engineer
Red Hat
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20181206/9d67579a/attachment.html