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]
