Sourcegraph DocsSourcegraph Docs
  • Code Intelligence

    • Cody
    • Code Search
  • Code Management

    • Batch Changes
    • Code Monitoring
    • Code Ownership
    • Code Insights
    • Notebooks
  • Platform

    • Sourcegraph Admin
    • Sourcegraph Cloud
    • Integrations
  • CLI & API

    • Sourcegraph & Cody CLI
    • Sourcegraph GraphQL API
    • Sourcegraph Stream API
  • Help & Support

    • SLAs & Premium Support
    • How to videos
    • Tutorials
    • Sourcegraph Accounts
    • Changelog
    • Technical changelog
    • Releases
  1. Docs
  2. admin
  3. config
  4. private-network

Private network configuration

A private network refers to a secure network environment segregated from the public internet, designed to facilitate internal communications and operations within an organization. This network setup restricts external access, enhancing security and control over data flow by limiting exposure to external threats and unauthorized access.

When deploying self-hosted Sourcegraph instances in private networks with specific compliance and policy requirements, additional configuration may be required to ensure all networking features function correctly. The reasons for applying the following configuration options depend on the specific functionality of the Sourcegraph service and the unique network and infrastructure requirements of the organization.

The following is a list of Sourcegraph services and how and when each initiates outbound connections to external services:

  • frontend: The frontend service communicates externally when connecting to external auth providers, sending telemetry data, testing code host connections, and connecting to externally hosted Sourcegraph services
  • gitserver: Executes git commands against externally hosted code hosts
  • repo-updater: Communicates with code hosts APIs to coordinate repository synchronization
  • migrator: Connects to Postgres instances (which may be externally hosted) to process database migrations
  • executor: Sourcegraph Executor batch change or precise indexing jobs may need to connect to services hosted within an organization's private network

HTTP proxy configuration

All Sourcegraph services respect the conventional HTTP_PROXY, HTTPS_PROXY, and NO_PROXY environment variables for routing Sourcegraph client application HTTP traffic through a proxy server. The steps for configuring proxy environment variables will depend on your Sourcegraph deployment method.

Kubernetes Helm

Add the proxy environment variables to your Sourcegraph Helm chart override file:

YAML
frontend|gitserver|repo-updater: env: - name: HTTP_PROXY value: http://proxy.example.com:8080 - name: HTTPS_PROXY value: http://proxy.example.com:8080 - name: NO_PROXY value: "*.cluster.local,blobstore,codeinsights-db,codeintel-db,sourcegraph-frontend-internal,sourcegraph-frontend,github-proxy,gitserver,grafana,indexed-search-indexer,indexed-search,jaeger-query,pgsql,precise-code-intel-worker,prometheus,redis-cache,redis-store,repo-updater,searcher,symbols,syntect-server,worker-executors,worker"
Failure to configure NO_PROXY correctly can cause the proxy configuration to interfere with local networking between internal Sourcegraph services.

Using private CA root certificates

Some organizations maintain a private Certificate Authority (CA) for issuing certificates within their private network. When Sourcegraph connects to TLS encrypted service using a self-signed certificate that it does not trust, you will observe an x509: certificate signed by unknown authority error message in logs.

In order for Sourcegraph to respect an organization's self-signed certificates, the private CA root certificate(s) will need to be appended to Sourcegraph's trusted CA root certificate list in /etc/ssl/certs/ca-certificates.crt.

Configuring sourcegraph-frontend to recognize private CA root certificates

The following details the process for setting up the sourcegraph-frontend to acknowledge and trust a private CA root certificate for Sourcegraph instances deployed using Helm. For any other Sourcegraph service that needs to trust an organization's private CA root certificate (including gitserver, repo-updater, or migrator), similar steps will need to be followed.

  1. Copy out the existing ca-certificates.crt file from the sourcegraph-frontend container:
SH
kubectl cp $(kubectl get pod -l app=sourcegraph-frontend -o jsonpath='{.items[0].metadata.name}'):/etc/ssl/certs/ca-certificates.crt sourcegraph-frontend-ca-certificates.crt
  1. Concatenate the private CA root certificate to the sourcegraph-frontend-ca-certificates.crt file:
SH
cat sourcegraph-frontend-ca-certificates.crt {private-ca-certificate.crt file} > ca-certificates.crt
  1. Create a new Kubernetes ConfigMap containing the concatenated ca-certificates.crt file:
SH
kubectl create configmap sourcegraph-frontend-ca-certificates --from-file=ca-certificates.crt
  1. Mount the sourcegraph-frontend-ca-certificates ConfigMap to the sourcegraph-frontend Deployment:
YAML
frontend: extraVolumes: - name: ca-certificates configMap: name: sourcegraph-frontend-ca-certificates extraVolumeMounts: - name: ca-certificates mountPath: /etc/ssl/certs/

Once deployed, you should see the private CA root certificate in the sourcegraph-frontend container's /etc/ssl/certs/ca-certificates.crt file.

SH
kubectl exec -it $(kubectl get pod -l app=sourcegraph-frontend -o jsonpath='{.items[0].metadata.name}') -- tail /etc/ssl/certs/ca-certificates.crt

You can verify that the self-signed certificate is trusted using curl:

SH
kubectl exec -it $(kubectl get pod -l app=sourcegraph-frontend -o jsonpath='{.items[0].metadata.name}') -- curl -v {https://internal.service.example.com} > /dev/null
It is recommended to repeat these steps on a regular cadence to ensure that Sourcegraph's CA root certificate list stays up to date.

On this page

  1. Private network configuration

    1. HTTP proxy configuration
    1. Using private CA root certificates

Edit this page on GitHub
Questions? Give us feedback