On 2026/11/05 14:02:50 Eric Pugh via dev wrote:
>
>
> On 2026/11/03 19:49:22 Jan Høydahl via dev wrote:
> > Many apps out there offer a "secure by default" install that do generate a
> > self-signed cert, and then put a big fat warning that a long-lived
> > self-signed cert
> > is not a security best practice and recommend provisioning of their own
> > certs.
> >
> > Deploying solr is also something users may choose to do in many different
> > ways,
> > some will use TLS as authentication, some will run Solr in k8s and delegate
> > both TLS and auth to a service mesh through sidecar containers etc. Thus we
> > should not assume a one size fits all in our scripts or docs.
> >
> > Jan
> >
> > > 3. nov. 2026 kl. 18:20 skrev Eric Pugh via dev <[email protected]>:
> > >
> > >
> > >
> > > On 2026/11/03 16:56:56 Jason Gerlowski wrote:
> > >>> It seems we want it both ways -- offer a way to secure Solr and yet
> > >>> disclaim any responsibility for the security of the advice we give
> > >>
> > >> I think that's a great question for Eric in terms of what he's
> > >> actually shooting for. Is the goal to give users tools that make it
> > >> easier for them to enable whatever security they decide on? Or is the
> > >> goal for us to be proscriptive in our security advice and provide an
> > >> absolutely rock-solid security configuration that's "production ready"
> > >> ootb?
> > >>
> > >> I've been assuming the "former", but maybe I misunderstood.
> > >>
> > >>> They would rightfully question the example as sound
> > >>> if we won't even stand by it.
> > >>
> > >> I disagree. Folks are familiar with the concept of a demo or a POC
> > >> setup. They expect an "example" to make certain shortcuts (e.g.
> > >> self-signed certs) or assumptions that may not fit every deployment.
> > >> A disclaimer that reminds users, "Hey remember this *is* an example"
> > >> isn't all that beyond-the-pale I don't think.
> > >>
> > >> Jason
> > >>
> > >> On Tue, Nov 3, 2026 at 9:33 AM David Smiley via dev
> > >> <[email protected]> wrote:
> > >>>
> > >>> It seems we want it both ways -- offer a way to secure Solr and yet
> > >>> disclaim any responsibility for the security of the advice we give ;-)
> > >>> I
> > >>> can see doing that if we are unspecific about how to do something (e.g.
> > >>> go
> > >>> set up SSL certs yourself), but if we do it for them ... mmmm....
> > >>> doesn't
> > >>> look good to me.
> > >>>
> > >>> Put yourself in the user's shoes. They see the convenient secure Solr
> > >>> self-signed thing, random password, etc. And then a big fat disclaimer,
> > >>> which kind of discourages them from using this secure mode (bad
> > >>> outcome).
> > >>> What are they to do? They would rightfully question the example as
> > >>> sound
> > >>> if we won't even stand by it.
> > >>>
> > >>> On Tue, Nov 3, 2026 at 3:36 AM Jan Høydahl via dev <[email protected]>
> > >>> wrote:
> > >>>
> > >>>> Could perhaps our installers (linux install script) offer a CLI opt to
> > >>>> install the node
> > >>>> with a self-signed cert pre-installed, basic-auth enabled with a random
> > >>>> password,
> > >>>> and the password printed to the terminal or available in a file. And of
> > >>>> course
> > >>>> with a disclaimer that this is for dev/test lab use, not for
> > >>>> production.
> > >>>>
> > >>>> Jan
> > >>>>
> > >>>>> 3. nov. 2026 kl. 03:57 skrev Jason Gerlowski <[email protected]>:
> > >>>>>
> > >>>>> Some thoughts on the bullet points you mentioned:
> > >>>>>
> > >>>>>> Add bin/solr ssl for setting up SSL configuration files and
> > >>>>>> documetning
> > >>>> that
> > >>>>>> Add bin/solr auth add-zk-user(?)
> > >>>>>> add bin/solr auth add-user/add-role
> > >>>>>
> > >>>>> I think these would be awesome things to have incorporated into a new
> > >>>>> "bin/solr -e" example. (Possibly aided by helper scripts or
> > >>>>> something.). IMO it'd be a huge benefit to have a "bin/solr start -e
> > >>>>> secure" that runs a multi-node SolrCloud deploy with all of the
> > >>>>> security bells and whistles enabled.
> > >>>>>
> > >>>>> But I'm a little leery about exposing these capabilities as "bin/solr"
> > >>>>> tools in their own right. For a few reasons:
> > >>>>> (a) it's additional security-related code that increases our CVE
> > >>>>> surface area, if anyone finds bugs in our defaults, documentation,
> > >>>>> etc. around cert generation
> > >>>>> (b) the cert gen stuff feels like it'd be subject to scope creep as
> > >>>>> bug reports come in for different platforms, openSSL versions, etc.
> > >>>>> (c) we're not really experts in many of these things: OpenSSL cert
> > >>>>> generation, ZK security, etc.
> > >>>>> (d) it seems like your main motivation here is to provide an easy
> > >>>>> first step for folks to get started with security, but it's very hard
> > >>>>> to stop folks from taking things intended as a nice example/PoC and
> > >>>>> running straight to production with it :-p
> > >>>>>
> > >>>>> None of these are show-stoppers, but wanted to point them out so you
> > >>>>> can weigh them against the value you see in "bin/solr" integration.
> > >>>>> Do you see particular benefits to the "bin/solr" integration approach?
> > >>>>>
> > >>>>> Best,
> > >>>>>
> > >>>>> Jason
> > >>>>>
> > >>>>> On Mon, Nov 2, 2026 at 4:56 PM Eric Pugh via dev <[email protected]>
> > >>>> wrote:
> > >>>>>>
> > >>>>>>
> > >>>>>>
> > >>>>>> On 2026/11/01 17:02:25 Eric Pugh via dev wrote:
> > >>>>>>>
> > >>>>>>>
> > >>>>>>> I'm working with a client that is looking at how to use Solr in
> > >>>> FedRAMP environments, specifically around how to secure Solr. As I
> > >>>> got
> > >>>> into it, I realized that our story about a secure Solr is VERY
> > >>>> fragmented.
> > >>>> It's spread across topics like HTTPS, inter node communication,
> > >>>> zookeeper,
> > >>>> and of course our security.json architecture.
> > >>>>>>>
> > >>>>>>> Then I thought back "How many times ahve I ever deployed Solr
> > >>>> securely" and relaized it wasn't that often, and each time I had to
> > >>>> rely
> > >>>> heavily on very smart DevOps folks to help me because I didn't know a
> > >>>> lot
> > >>>> of the concepts. Then I realized, you know, there are plenty of times
> > >>>> i
> > >>>> SHOULD have deplyoed Solr with security and didn't ;-).
> > >>>>>>>
> > >>>>>>> I've been exploring a bit on How Can Solr be Run Securely Easily?
> > >>>> And I found that it's actually not that hard, we just don't have any
> > >>>> good
> > >>>> docs or examples. In this PR
> > >>>> https://github.com/apache/solr/pull/5107 I
> > >>>> experimented with:
> > >>>>>>>
> > >>>>>>> Added a bin/solr -e secure-setup example that spins up a 2 node
> > >>>> cluster (1 embedded zk) that has it's own generated self signed HTTPS
> > >>>> certificate, has ACLs enabled for the embedded ZK, and has a
> > >>>> security.json
> > >>>> that has an admin/index/search roles and locks everything down exept
> > >>>> anonymous metris/health.
> > >>>>>>>
> > >>>>>>> This was really impactful for me as all of a sudden I could quickly
> > >>>> stand up a secure environment and start finding issues!
> > >>>>>>>
> > >>>>>>> So, some observations or comments:
> > >>>>>>>
> > >>>>>>> 1) For example, if you lock down Zookeeper, then our bin/solr zk
> > >>>> commands only work if you have a custom solr.in.sh! So I added a
> > >>>> --zk-credentials helper to our various bin/solr zk commands.
> > >>>>>>>
> > >>>>>>> If we decided that only "bin/solr zk" took in a ZK url, and all the
> > >>>> other tools only take in solr-url's, then we could just have
> > >>>> --credentials
> > >>>> for the bin/solr zk tools, which would be nice.
> > >>>>>>>
> > >>>>>>> 2) I discovered that the Admin UI burps if you log in as someone
> > >>>>>>> wiht
> > >>>> search or index only permissions, becuase we assume you basically have
> > >>>> access to everyapi. Yes, we give an error, and no, it's not great!
> > >>>> We
> > >>>> could do some minor stuff to make that UI nicer, and we should
> > >>>> definitly be
> > >>>> testing out the new Solr UI with different sets of permissioned users.
> > >>>>>>>
> > >>>>>>> 3) The secure-setup example currently requires "openssl" on the
> > >>>> command line for generating the PEM, I'm curious if we could just use
> > >>>> Bouncy Castle? But that might have issues? It's another 11 MB of jars
> > >>>> ;-). Plus we have to decide FIPS or not. It would be nice to be an
> > >>>> all-java solution! Maybe augment the bin/solr ssl tool?
> > >>>>>>>
> > >>>>>>> 4) How opinionated should we be on waht a good well thought out
> > >>>> "security.json" structure should look like?
> > >>>>>>>
> > >>>>>>> 5) Also, ugh, building a custom local security.json is odd. I
> > >>>>>>> wanted
> > >>>> to instead have some sort of "bin/solr start --bootstrap-security-json
> > >>>> ./mycustom/security.json" option. If we did that, then maybe we go a
> > >>>> bit
> > >>>> furthur and that security.json file could also define our Zookeeper
> > >>>> ACLS???
> > >>>>>>>
> > >>>>>>> 6) I'd love some feedback ont he tutorial I wrote.. It leverages
> > >>>>>>> the
> > >>>> bin/solr start -e secure-setup. Should I change the tutorial to not
> > >>>> even
> > >>>> use the secure-setup example? I worry that obfuscates too much waht is
> > >>>> going on..
> > >>>>>>>
> > >>>>>>> 7) Should creating roles and users be enabled in our bin/solr auth
> > >>>> command? Likewise, should for zookeeper there be bin/solr zk auth ?
> > >>>>>>>
> > >>>>>>> Lastly, there might be a bit of overlap with SIP-26
> > >>>> https://cwiki.apache.org/confluence/spaces/SOLR/pages/421957642/SIP-26+Role+Based+Authentication+using+Apache+Shiro
> > >>>> but I think this is more about just surfacing what we already have
> > >>>> better,
> > >>>> versus rethinking our security model!
> > >>>>>>>
> > >>>>>>> ---------------------------------------------------------------------
> > >>>>>>> To unsubscribe, e-mail: [email protected]
> > >>>>>>> For additional commands, e-mail: [email protected]
> > >>>>>>>
> > >>>>>>>
> > >>>>>>
> > >>>>>> I discovered that it's pretty easy to also wrap ZooKeeper connections
> > >>>> in TLS as well!
> > >>>>>>
> > >>>>>> I pushed that up to my exploration branch.
> > >>>>>>
> > >>>>>> At this point, I've started doing some self review and fixing things.
> > >>>>>>
> > >>>>>> I'd love some feedback that this is going in the right direction
> > >>>>>> before
> > >>>> I put too much more time into it, and then I'll start breaking it up
> > >>>> into
> > >>>> it's own PRs.
> > >>>>>>
> > >>>>>> I'm thinking there is:
> > >>>>>>
> > >>>>>> 1) Add bin/solr ssl for setting up SSL configuration files and
> > >>>> documetning that. Decide on BouncyCastle or openssl?
> > >>>>>> 2) Add bin/solr auth add-zk-user(?) that demonstrates how to set up a
> > >>>> secure ZK and add users, plus new params on bin/solr zk commands.
> > >>>>>> 3) add bin/solr auth add-user/add-role that maybe demosntrates how to
> > >>>> interact wiht security apis
> > >>>>>> 4) Maybe, a push to get us to v2 equivalents that work better?
> > >>>> https://github.com/apache/solr/pull/4916
> > >>>>>> 5) Extend the tutorial to show how to have anonymous health and
> > >>>>>> metric
> > >>>> endpoitns?
> > >>>>>> 6) Add bin/solr start -e secure-setup to wrap it all up in an easy to
> > >>>> run process?
> > >>>>>>
> > >>>>>> Each one of these would have a tutorial section that goes with them
> > >>>> that grows as you go through the steps?
> > >>>>>>
> > >>>>>> ---------------------------------------------------------------------
> > >>>>>> To unsubscribe, e-mail: [email protected]
> > >>>>>> For additional commands, e-mail: [email protected]
> > >>>>>>
> > >>>>>
> > >>>>> ---------------------------------------------------------------------
> > >>>>> To unsubscribe, e-mail: [email protected]
> > >>>>> For additional commands, e-mail: [email protected]
> > >>>>>
> > >>>>
> > >>>>
> > >>>> ---------------------------------------------------------------------
> > >>>> To unsubscribe, e-mail: [email protected]
> > >>>> For additional commands, e-mail: [email protected]
> > >>>>
> > >>>>
> > >>
> > >> ---------------------------------------------------------------------
> > >> To unsubscribe, e-mail: [email protected]
> > >> For additional commands, e-mail: [email protected]
> > >>
> > >>
> > >
> > > People are always asking me "How should we configure our Solr?" And
> > > broadly speaking, the answers often are the same, thats why we develop
> > > "Best Practices". I would hope that an example setup like "bin/solr
> > > start -e secure" (which guessing you like better than "secure-setup" ;-)
> > > ), would model those best practices.
> > >
> > > I don't know how you deliver any open source software like Solr without
> > > having at least some level of expertise in security. We literally run a
> > > security team for the CVE's, we document in the Ref Guide how to set up
> > > security, and we've made choices over the years of what types of
> > > authentication options we offer.
> > >
> > > Also, we are a open source project, not commercial shrinkware. We aren't
> > > providing indemnification or a warranty on what we provide. Yes, we
> > > should release software that we have a degree of confidence in. I don't
> > > think anything that I'm envisioning is going to be cutting edge. Just
> > > the basics of what a secure Solr should look like.
> > >
> > > The thought behind the example is to have something executable that is
> > > easier to test and play with. I originally thought about wrtiing a big
> > > bats file that builds on our existing testing of SSL, that would also do
> > > the zookeeper etc, but that seemed like a bit of a shame to lock up all
> > > that knowledge in a bats test that our users will never see. I thought
> > > about jsut documenting all the steps in a tutorial, but them realized so
> > > many manual steps are clunky and very prone to becoming out of date.
> > > That then led to me starting to think about adding a bit of helper
> > > tooling...
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: [email protected]
> > > For additional commands, e-mail: [email protected]
> > >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [email protected]
> > For additional commands, e-mail: [email protected]
> >
> >
>
> I think maybe the first place to start is to add a "bin/solr start -e secure"
> that doesn't expose new tooling and pair that with a very detailed "step by
> step" tutorial. I'll aim to make no changes in the first version to Solr.
> Then, if certain things require changes to Solr, then we can bring those up
> as seperate PRs/discussion points.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
>
>
I've got the PR that adds a -e secure example setup to Solr done. I'd love
some feedback on it at https://github.com/apache/solr/pull/5306.
My next step is a targeted PR that makes it easier to run Embedded ZooKeeper
with TLS mode enabled, that requires some actual changes to Solr itself to make
feasible.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
