[
https://issues.apache.org/jira/browse/SOLR-7207?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14354499#comment-14354499
]
Noble Paul commented on SOLR-7207:
----------------------------------
bq.Yes you'd probably want to combine with HTTPS, which is not a bad idea
anyway when allowing traffic from outside your DC
Setting up Solr in HTTPS is a pain and not efficient because all our
communication happens over that port. The fact that we will only need security
bq.Typically ApiKeys are also combined with IP checking to further reduce
attack surface
IPs can be faked , right?
bq.How would you make sure that an unencrypted, PKI signed payload with e.g.
<delete><query>:</query></delete> cannot be sniffed and replayed by an
attacker? The payload signature hash will be the same every time for the same
payload, will it not?
Yes, I'm thinking of adding a timestamp attributes to all write operations .
Any operation that is older than a few seconds (configurable) would be
rejected. Most people who use the APIs in the intranet may not worry about
sniffing , but those who use the APIs over the internet can use this.
example:
{noformat}
<delete>
<_ts_>3454354646576</_ts_>
<query>:</query>
</delete>
{noformat}
Our clients will have (SolrJ) will have options to initialize with a private
key and the rest can be taken care of automatically
The reason for this idea was to have a tiered approach to security which you
can opt in/out whenever you wish to an existing cluster without impacting any
other operation. I can just say that loading executable and , config alone
needs to be secure and all you nee to do is upload a couple of public keys to a
specified directory in ZK. We don't need to rely on external services. Relying
on external systems is fine but this leads to a proliferation of recipes. This
is exactly what happened when we had a .war file that could be deployed to any
container and we are now at the mercy of the container
My suggestion is we should have a built in security mechanism that is
reasonably secure and APIs to extend the security to other external tools.
This particular solution can be build on that API, where external solutions can
also rely on
> Securing operations in Solr
> ---------------------------
>
> Key: SOLR-7207
> URL: https://issues.apache.org/jira/browse/SOLR-7207
> Project: Solr
> Issue Type: New Feature
> Reporter: Noble Paul
>
> Historically, Solr has always stayed away from securing any operations and we
> even allow GET operation on an HTTP end point to manipulate almost anything
> inside a Solr cluster
> We can categorize the operations such as
> * Loading executable (runtime jars) SOLR-7126
> * conf files SOLR-6736
> * schema API
> * config API
> * collections API
> * /update/* operation to any collection
> SOLR-7126 has solved this problem using PKI where the public keys can be
> uploaded to {{/keys/exe}} and all jars loaded are verified using one of the
> public keys.
> A similar scheme can be used for other operations as well. We can add keys to
> other directories and use them to verify other operations. The only catch is
> , that we will need to send all the payload via POST
> The advantage of this scheme is that Solr does not need to manage any
> credentials or take care of storing anything secretly. It just needs a few
> public keys to be stored in ZK and security will kick in automatically.
> External solutions can build on top of these and provide authentication etc
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
