How about this: we make it possible to push the zk security config to a file on all current nodes, Nodes that don't find security in zk consult the filesystem as a fallback. Thus the upgrade scenario can be:
1) Push down security to the nodes 2) remove security definitions from zk 3) perform upgrade 4) supply security to zk again to ensure uniform There could also be an optional "clear local security files" command that cleans the per node security files (if zk has security) out to ensure no confusion on subsequent startup. Folks who prever local files just never supply a security definition to zk in the first place... On Mon, May 4, 2026 at 10:34 AM David Smiley <[email protected]> wrote: > I love the idea of a separate module, although it isn't a necessity. With > such, a future potential CVE could be reported against this module, thus > users choosing not to use the module don't get annoying vulnerability scan > alerts for modules they don't use. Although it's a separate topic, I could > see benefits of modularizing more driven by that motivation (and other > motivations of course). For example, imagine if more SolrCloud aspects of > solr-core were separated to a jar that standalone mode could run without. > It would mean a SolrCloud-specific CVE could be associated to that JAR and > not solr-core. Just a thought. And imagine a stripped-down, embedded Solr > as well (low dependencies). Of course, realizing such fantasies would > require real work, as CoreContainer and other classes assume all public > classes are available to it. > > I definitely want to be able to configure security purely from local > files/environment, excluding ZK. Managing configuration in ZK with > evolving cluster upgrades has been problematic from my past experience. By > contrast, relying on a locally built & tested Docker image leaves less > "state" behind to manage with an upgrade. > > On Sun, May 3, 2026 at 6:34 PM Gus Heck <[email protected]> wrote: > > > I find the idea of out of sync security settings terrifying. If it's not > > managed by zk then you have to deal with any number of corner cases > > involving nodes that lost connectivity, were down, or in K8 world, > settings > > on the persistent volume that is re-attaching... > > > > The last thing I want is more than one notion of what the security > settings > > are. I imagine a json version of the info in shiro.ini in zk. I have a > > personal project where I stored the permissions in a database table and > > mapped it to hibernate. We could even just put an ini in zk too. > > > > I definitely would like to have this be an option not a replacement > > initially I suspect if it goes well the old system will be sunset at some > > point. > > > > Also not yet mentioned - I would *hope* I can make it a module (and move > > the current one to a module too, which might be a separate effort or > > necessary for this. > > > > > > On Sun, May 3, 2026 at 6:06 PM Jan Høydahl <[email protected]> > wrote: > > > > > Great that you want to start this effort. > > > > > > When you say "Add a new plugin based on Apache Shiro", do you then mean > > > trying to fit Shiro into our current security.json plugins or to start > a > > > fully parallel implementation? > > > I think perhaps a fully parallel approach (with shiro.ini or some other > > > local-to-node config format) being used. I'm starting to question if > > having > > > the central security.json in ZK is in itself a security risk compared > to > > > local files on nodes. > > > It is also far easier to bootstrap a solr node with security if based > on > > > local file configuration, than relying on ZK. Perhaps the SIP can > discuss > > > such tradeoffs. > > > > > > Jan > > > > > > > 3. mai 2026 kl. 23:25 skrev Gus Heck <[email protected]>: > > > > > > > > oops, forgot to put the discuss tag on the subject line, please > proceed > > > on > > > > this thread > > > > > > > > On Sun, May 3, 2026 at 5:20 PM Gus Heck <[email protected]> wrote: > > > > > > > >> I spent some time writing up an idea that's been growing in my head > > > >> since I watched Jason's talk on our "not so basic auth" at activate > in > > > 2019 > > > >> > > > >> > > > >> > > > > > > https://cwiki.apache.org/confluence/display/SOLR/SIP-26%3A+Role+Based+Authentication+using+Apache+Shiro > > > >> > > > >> LMK what you think. I'm hoping to begin spending some time on this > > soon. > > > >> > > > >> -Gus > > > >> > > > >> -- > > > >> http://www.needhamsoftware.com (work) > > > >> https://a.co/d/b2sZLD9 (my fantasy fiction book) > > > >> > > > > > > > > > > > > -- > > > > http://www.needhamsoftware.com (work) > > > > https://a.co/d/b2sZLD9 (my fantasy fiction book) > > > > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: [email protected] > > > For additional commands, e-mail: [email protected] > > > > > > > > > > -- > > http://www.needhamsoftware.com (work) > > https://a.co/d/b2sZLD9 (my fantasy fiction book) > > > -- http://www.needhamsoftware.com (work) https://a.co/d/b2sZLD9 (my fantasy fiction book)
