Hi, Great effort on lowering the bar for folks to get started on security.
I guess I'm following Jason's thinking, that we should be careful how we choose to make SSL cert tools available to users, not promising too much, we could call them templates, examples etc rather than supported prod recommendations. With SSL in particular, the user WILL need to own the entire issuing, signing, rotation, revocation process. So everything aound cert generation shuold be labeled NON-PRODUCTION. But what we CAN do is offer some tooling around it. Like our Solr-operator offers convenience ways to provision certificates, but delegate to external tooling to generate the certs. 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]
