> ## Documentation Index > Fetch the complete documentation index at: https://docs.e6data.com/llms.txt > Use this file to discover all available pages before exploring further. # Networking and security > Separate client access from internal service and worker traffic. Every advertised address must be reachable from the process that uses it. A listener can bind all interfaces while ReferenceApplies to: Unified engine deployments Separate client access from internal service and worker traffic. Every advertised address must be reachable from the process that uses it. A listener can bind all interfaces while advertising a private DNS name. ## Endpoints | Endpoint | Default local address | Configuration | | - | - | - | | Console and HTTP API | `127.0.0.1:15003` | `network.http.listen` | | Spark Connect | `127.0.0.1:15002` | `network.spark_connect.listen` | | Internal service RPC | `127.0.0.1:50060` | `network.services.listen` | | Worker connections | `127.0.0.1:50061` | `network.workers.listen` | | Telemetry history | Normally `127.0.0.1:50063` | `network.telemetry.listen` | The standalone console is at `/`. Pipelines, Workloads and Workbench share `/pipelines`. Use `?tab=workloads` or `?tab=workbench` to open a Unified view. Unified APIs use `/api/v1/unified/`. Existing native Session clients can still use `/api/v1/sessions`. These paths share the HTTP listener. PySpark connects to the separate Spark Connect listener. Keep internal RPC, telemetry, and worker connections on private networks. Publishing the console does not require publishing these internal ports to client networks. By default, the telemetry history listener uses the internal RPC listener's port plus three. Set `network.telemetry.advertise` when that derived address is not reachable from workers or peers. ## Listen and advertised addresses Change these fields in a complete config for a remote-worker deployment: | Field | Example | Meaning | | - | - | - | | `network.services.listen` | `0.0.0.0:50060` | Accept internal calls inside the host or container | | `network.services.advertise` | `http://laminar-control:50060` | Address peers use for this process's service RPC | | `network.workers.listen` | `0.0.0.0:50061` | Accept worker connections | | `network.workers.advertise` | `http://laminar-control:50061` | Address task workers use to connect to Controller | Do not advertise `0.0.0.0`. It is a bind address, not a destination. Do not advertise loopback to another container, Pod, or machine. Each has its own loopback interface. `network.services.advertise` must name an address workers can reach. Storage endpoints and catalog URLs must also work from their networks. A browser reaching the console is not proof of worker connectivity. ## Client identity and TLS The current native configuration uses a configured HTTP owner and a Spark Connect listener owner. A client-supplied Spark user name is not a fine-grained permission system. These guides do not claim a complete multi-user IAM model. Place remote client access behind the deployment's authentication and TLS boundary. Spark Connect needs a boundary that supports its gRPC traffic. Internal listener settings shown here do not configure native mTLS or authenticate every service peer. Plan private routing and access controls accordingly. A reverse proxy login does not by itself add per-table permissions inside Laminar. Catalog and cloud storage permissions remain separate controls. ## Credentials and secrets `credentials` supplies bootstrap credential bindings. `secrets.secret_providers` configures external secret references. The built-in secret store encrypts values using `/secrets/master.key`. Restrict access to that key to the controller identity. Workers can resolve credentials through the configured Secrets and Credentials services. Their environment and cloud identity still need the permissions required for their selected credential and storage paths. See [credentials](https://docs.e6data.com/transformation/learn/credentials.md) and [secrets](https://docs.e6data.com/transformation/learn/secrets.md). Local-process and Docker command adapters clear the inherited environment. Their configured environment map belongs to the spawned process or Docker CLI. Container environment settings and Pod identity need their own deployment configuration. Do not assume a host's cloud login reaches a remote worker. Do not put secrets in image layers or ordinary ConfigMaps. Mount credential files, use a supported secret reference, or configure a workload identity that the chosen provider can use. ## Worker allocation input Local-process, Docker, and Kubernetes workers receive generated configuration and allocation JSON through environment variables. Lambda receives these values in its invocation event. Kubernetes allocation bootstrap does not create a Secret. The allocation includes task identity and bootstrap material. Controller checks worker registration against it. Do not turn that per-allocation material into a long-lived image setting or a public connection URL. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.