Add network bind section, explain how to bind to a specific interface

qdrant-landing/content/documentation/guides/security.md

@@ -420,6 +420,44 @@ This is also applicable to using api keys instead of tokens. In that case, `api_
 | telemetry | ✅ | ✅ | ❌ | ❌ |
 | metrics | ✅ | ✅ | ❌ | ❌ |
 
+## Network bind
+
+By default, a custom Qdrant deployment binds to all network interfaces. Your
+instance may be open to everybody on the internet. On a local development
+machine you likely have a firewall in place to prevent public access, but that
+may not be the case on a public VPS or dedicated server.
+
+It is highly recommended to bind to a specific interface or IP address to
+prevent unwanted access:
+
+- when developing locally, bind to `127.0.0.1` so no external access is possible
+- or, when deploying to production, bind to a private network interface or IP
+
+When using Docker, you may use the publish flag to bind to a specific interface.
+For example:
+
+```bash
+docker run -p 127.0.0.1:6333:6333 qdrant/qdrant
+```
+
+If using another type of deployment you may configure the bind address in Qdrant
+itself. Either set `service.host: 127.0.0.1` in the configuration, or use an
+environment variable like this:
+
+```bash
+QDRANT__SERVICE__HOST=127.0.0.1 ./qdrant
+```
+
+Managed Qdrant Cloud deployments are always secure by default. They are publicly
+accessible and bound to the endpoint that is assigned to the cluster. You may
+configure authentication with [API keys](/documentation/cloud/authentication/),
+and restrict access to specific IP addresses through [Client IP
+Restrictions](/documentation/cloud/configure-cluster/#client-ip-restrictions).
+[Hybrid Cloud](/documentation/hybrid-cloud/networking-logging-monitoring/) and
+[Private
+Cloud](/documentation/private-cloud/qdrant-cluster-management/#exposing-a-cluster)
+deployments have their own kind of configuration.
+
 ## TLS
 
 *Available as of v1.2.0*