Network encryption

Posit Connect administrators can use this page to review network encryption for high availability and off-host execution.

Network security

When Connect runs in High Availability mode or off-host execution mode, administrators must consider several important aspects of network security. Administrators must understand their network topology to decide whether they need additional configuration to meet their organization’s security and compliance standards.

Database connections

If you configure Connect to use a Postgres database to store state, you might need to enable SSL for all database connections. Set the sslmode= parameter to the desired value in the Connect Postgres.URL configuration.

Network filesystems

If Connect uses a network filesystem to share state between nodes, organizational policy and network topology might require you to configure data-in-transit encryption for access from each Connect node. Setup steps vary by filesystem provider, so this page does not cover them.

Content process traffic

Connect communicates with the running content process (the interactive R or Python application) using HTTP/HTTPS. Additionally, some communication occurs over websockets (Shiny apps, for example). Connect also communicates with the content session itself via ping and metrics endpoints.

When Applications.ContentSessionTLS is enabled, Connect encrypts these communication channels using self-signed certificates over HTTPS. Connect proxies content process communications through the session process, which receives TLS certificates via encrypted environment variables from Connect. The content session process establishes TLS communication with Connect and subsequently terminates TLS before proxying traffic to the running content process over localhost.

Connect creates an ephemeral root certificate authority (CA) at startup. The CA signs the TLS certificates that the session process uses to encrypt communications, and Connect keeps the CA in process memory without persisting or exposing it.

Connect does not persist or expose the TLS certificates outside process memory, except through the encrypted environment variables delivered to the session process. They exist only during the lifetime of the content process. Each content process uses a unique certificate.

Disabling this feature by setting Applications.ContentSessionTLS to false means traffic between the Connect and content pods in off-host execution traverses an unencrypted network boundary. In this case, we recommend using a service mesh to secure network communication.

Service mesh

When Connect and its supporting infrastructure run inside a Kubernetes cluster, you can encrypt network traffic transparently by installing a service mesh within the cluster. That supporting infrastructure includes a network file system (NFS) and Postgres. The service mesh encrypts all pod-to-pod Layer 4 (L4) network communication within the Kubernetes cluster. This ensures that the service mesh encrypts database connections, network filesystem access, and content process traffic by default, with no additional configuration.

Cilium and Istio are popular service mesh options that can enable secure end-to-end encryption by default for your Connect installation.