Security recommendations

These are security hardening recommendations for Posit Connect deployments based on the most common requirements from enterprise security reviews. Use them alongside the detailed configuration guidance linked from each section. This guide targets administrators and security teams responsible for Connect infrastructure.

A secure Connect deployment depends on the environment around it, including your identity provider, network, host operating system, and the package sources your content uses. Many of the controls on this page depend on decisions only your organization can make. For example, you choose which identity provider to use, which certificates to trust, and which package sources to approve. Apply these recommendations as part of preparing any enterprise deployment for production.

This guide groups recommendations by security topic. Review each section for the controls that apply to your deployment.

Package management

• Use Posit Package Manager with curated CRAN and Python Package Index (PyPI) repositories to control which packages are available to content running on Connect. See Package security for the security considerations.
• If your Package Manager instance requires authentication, configure the integration for authenticated repositories.

Authentication and authorization

• Integrate with your organization’s identity provider (LDAP, SAML, or OpenID Connect) rather than relying on the Connect built-in password authentication.
• If you use built-in password authentication, keep self-registration disabled unless users need to create their own accounts.
• Enable Authorization.ViewersCanOnlySeeThemselves when Viewers should not see other users and groups. This setting is incompatible with current user execution through the Connect nameservice.
• Enable Server.HideEmailAddresses when non-administrators should not see other users’ email addresses.
• If your identity provider supports System for Cross-domain Identity Management (SCIM), enable it to automate user and group provisioning in Connect.
• Apply the principle of least privilege when assigning user roles (Viewer, Publisher, Administrator). Limit who has the Publisher and Administrator roles and review role assignments periodically.
• Consider requiring git-backed publishing for all content by revoking the bundles:upload permission from the Publisher role, as described in Customizing user roles. This ensures all deployed content has a source-controlled audit trail.
• Review session lifetime settings. The defaults (24-hour maximum lifetime and 8-hour inactivity timeout) are reasonable starting points. Adjust Authentication.Lifetime and Authentication.Inactivity to match your organization’s policy. See Limit session lifetime.

Encryption and TLS

• Always serve Connect over HTTPS in production. Never use plain HTTP.
• Terminate TLS either at Connect itself or at the reverse proxy. If terminating at the proxy, see Terminate TLS at a proxy for the required configuration.
• Use certificates from a trusted certificate authority. See Configuring SSL certificates for setup instructions.
• Enforce TLS 1.2 as the minimum version using the HTTPS.MinimumTLS setting. See Set the minimum TLS version for details.
• Enable HTTP Strict Transport Security (HSTS) by setting HTTPS.Permanent to true. This adds a Strict-Transport-Security header and enforces the Secure flag on cookies. See Require HTTPS permanently.

Network

• Restrict inbound traffic to only necessary ports, typically 443 for HTTPS and 22 for Secure Shell (SSH) management.
• Use a firewall or security group to block direct access to the Connect default port (3939) from outside the trusted network.
• Place a reverse proxy (such as NGINX or Apache) in front of Connect rather than exposing Connect directly.
• Run Connect on a dedicated server, not shared with unrelated services.

Secrets management

• Ensure the encryption key file has 0600 permissions. Back up this file securely.
• Ensure the Connect license file has restricted permissions (0600), readable only by the Connect service account.
• Encourage publishers to store credentials as environment variables set through the Connect dashboard or API, rather than hardcoding them in content source code.
• Encourage publishers to use service account, viewer, or Workload Identity integrations for connecting to protected resources such as databases and external APIs. Administrators must configure these integrations before publishers can use them.
• Restrict filesystem permissions so the Connect service account only has access to directories it needs (Server.DataDir, Database.Dir, Server.TempDir, /etc/rstudio-connect/, any others needed by the RunAs user, etc).

Operating system security

• Keep the host operating system (OS) patched and updated on a regular schedule.
• Consider using a Center for Internet Security (CIS) hardened image as a starting point for the Connect host. Some hardened OS policies might need adjustment for Connect to operate correctly. Test Connect functionality after applying a hardened image.
• If enabling SELinux (enforcing mode) or AppArmor on the Connect host, verify that Connect processes can run correctly under the enforced policy and adjust rules as needed.

Observability

• Ship the audit log to your Security Information and Event Management (SIEM) or centralized log management system. Connect records audit events to its database by default, but exporting them enables centralized monitoring. See Auditing for configuration options.
• Configure structured JSON output using Logging.AuditLogFormat for easier ingestion by log aggregation tools.
• Enable the Prometheus metrics endpoint for external monitoring by setting Metrics.PrometheusListen to a port (for example, :3232). See Prometheus metrics for details.
• Use the Connect audit log API to automate periodic reviews of login patterns, content access, and administrative actions.

Maintenance

• Keep Connect up to date. Posit releases security patches regularly. Review the release notes for details.
• Establish a regular schedule for OS patching, Connect upgrades, content dependency updates, R version updates, Python version updates, Quarto version updates, and driver and system dependency updates.

User isolation (optional)

For deployments that require stricter process and user controls, Connect supports current user execution so that content processes run as the authenticated Linux account rather than a shared service account. The content process will then only have access to files on the server that their provisioned Linux account has access to. Connect will create and manage authenticated Linux accounts based on your authentication provider information.

• Configure Connect to run content processes as a restricted RunAs user, not root and not the Connect service account. See RunAs.
• Consider enabling the Connect Nameservice (early access) for current user execution with OAuth2, SAML, or LDAP authentication providers. The nameservice associates Linux users with Connect users through your identity provider. See Current user execution.

Public-facing servers

Connect servers that serve content on the open internet require additional configuration beyond the other recommendations in this checklist.

Public access requirements

• Ensure Connect has outbound access to the URL validation server at https://verify.pct.posit.co/url-validator on port 443.
• Verify that no proxy edits or removes the X-Content-Signature and Date HTTP headers, as the URL validation server requires them.
• Set Server.Address to the server’s publicly accessible URL.
• Confirm that content set to public access is reachable from the public internet.

Additional hardening

• Enable Completely Automated Public Turing test to tell Computers and Humans Apart (CAPTCHA) for login forms with Authentication.ChallengeResponseEnabled to mitigate brute-force and dictionary attacks. See Protect sign-in from brute-force and dictionary attacks.
• Configure Server.ServerName to replace the Server HTTP header, which identifies the server as Posit Connect by default. See Server header.