How do you secure a SolrCloud cluster in production?

A default SolrCloud install has no authentication and exposes a powerful admin API, so production hardening covers several independent layers rather than one setting.

1. Authentication. Enable a security plugin such as BasicAuthPlugin for simple username/password control, or KerberosPlugin in enterprises already using Kerberos, configured via security.json stored in ZooKeeper so it applies cluster-wide.
2. Authorization. Pair authentication with RuleBasedAuthorizationPlugin to restrict which roles can hit sensitive endpoints - most users need read/query access, far fewer need collection admin or config-set write access.
3. Transport encryption. Enable SSL/TLS for both client-to-Solr and inter-node traffic, since shard-to-shard distributed queries and replication otherwise travel in plaintext.
4. Secure ZooKeeper itself. Restrict ZooKeeper ACLs so only authorized Solr nodes can read/write cluster state and config sets; an unsecured ZooKeeper is a backdoor around any Solr-level security.
5. Network-level restriction. Keep the admin UI, Collections API, and ZooKeeper ports off the public internet, reachable only from application servers and operational tooling via firewall rules or a private network/VPC.

These layers are complementary, not substitutes for each other: authentication without network restriction still exposes an attack surface for credential attacks, while network restriction alone doesn't stop a compromised internal service from reading data it shouldn't - production deployments generally need all five to be considered adequately secured.