Cloud Access Control Policy

Policy Owner: Security Lead Approved by: Security Lead

Introduction

This Access Control Policy defines which Sourcegraph employees have access to each production asset and under which conditions. It is not in scope to define how to enforce these policies. It targets the Cloud product (formerly known as Managed Instances), running single-tenant Sourcegraph instances Docker Compose instances on GCP (later to be substituted by Kubernetes deployments on GKE).

This document is divided in sections:

  • Infrastructure access (GCP, Cloudflare)
  • User access (User and site admin)
  • Change management (Terraform, Buildkite)

Each section has a desired end-state and the current state. The desired end-state targets customers with elevated security standards along with providing us more fine-grained access control options.

The policy also differentiates customer instances from instances used internally by Sourcegraph. Customer instances are all Cloud instances containing customer data (customer.sourcegraph.com) and trial instances. These instances have higher security scrutiny. Sourcegraph instances are:

  • sourcegraph.sourcegraph.com
  • k8s.sgdev.org
  • sourcegraph.com
  • demo.sourcegraph.com
  • devmanaged.sourcegraph.com
  • rctest.sourcegraph.com

Access logs will be collected and audited, increasingly for higher levels of access. Defining the logging and alerting methods is out-of-scope for this policy. We are also not considering sharing logs with customers at this time.

Note: Approval processes for elevated access (referenced throughout this doc) will be documented by Security and Tech Ops. The teams are currently evaluating tooling to improve this process.

Infrastructure access

GCP services (GKE, Cloud SQL, etc) and Cloudflare.

Current State

Customer instances

  • Cloud team has elevated access.
  • Non-Cloud teammates can request access with regular approval flow.

Sourcegraph instances

  • All teammates have elevated access.

Desired end-state

Customer instances

  • No one has access by default.
  • Cloud, Security teams can request read-access with automatic approval.
  • Cloud, Security teams can request elevated access with regular approval flow.
  • Cloud, Security on-call teammates can request elevated access with automatic approval.
  • Cloud, Security on-call teammates can approve elevated access requests for others during incidents.
  • Non-Cloud teammates cannot request access.

Sourcegraph instances

  • No one has access by default.
  • All teammates can request read or elevated access with automatic approval.

Elevated access

In the context of our infrastructure, elevated access encompasses write access to infrastructure. For our current assets, this includes:

  • Shell in pods
  • Write access to db
  • Editor access to the project in GCP, allowing to create/edit resources
  • Administrator/Super Administrator role in Cloudflare

User access

Having access to the instance as a user or site admin.

Current state

Customer instances

  • Cloud team with improved OIDC provider.
  • CE team pairs with customer site admin when needed.

Sourcegraph instances

  • All engineers may request and maintain site admin access.
  • All current site admins can grant site admin access to others.

Desired end-state

Customer instances

  • No teammates have access by default. Service accounts used for management are automatically provisioned with elevated privileges.
  • Cloud, CE teams can request user access with automatic approval.
  • Cloud, CE teams can request site admin access with regular approval flow.
  • Cloud, Security on-call teammates can request site admin access with automatic approval.
  • Cloud, Security on-call teammates can approve elevated access requests for others during incidents.
  • Non-Cloud teammates cannot request access.

Sourcegraph instances

  • All teammates have access by default.
  • All teammates can request elevated access with automatic approval.

Change management

Making changes to the infrastructure via Terraform or deployment (Buildkite, ArgoCD).

Current state

Customer instances

  • Cloud, Security teams can approve changes.
  • Cloud team can apply changes.
  • No other teammates have access by default.

Sourcegraph instances

  • Cloud, Security, DevX can approve changes.
  • All engineers can apply changes through CD.

Desired end-state

Customer instances

  • No one has access by default.
  • Changes are performed by a Terraform Cloud-like solution.
  • Cloud, Security teams can approve changes to instances (updating terraform code).
  • Cloud, Security on-call teammates can request elevated access to apply Terraform changes outside CI with automatic approval.
  • Cloud, Devx, Security teams can approve changes to CI/CD configurations (ArgoCD, Buildkite). Sourcegraph instances
  • Changes are performed by a Terraform Cloud-like solution.
  • Cloud, Devx, Security teams can approve changes.
  • Cloud, Devx on-call teammates can request elevated access to apply Terraform changes outside. CI with automatic approval.

Telemetry and monitoring

Access to monitoring and telemetry data such as Grafana, etc.

Current state

Customer instances

  • Cloud team has access by default to all logs.
  • Non-Cloud teammates can request access to all logs with regular approval flow. Sourcegraph instances
  • All teammates have access.

Desired end-state

Customer instances

  • Docker/k8s logs (contains private repo names): Cloud with automatic approval. Prometheus/Grafana (contains private repo names): Cloud with automatic approval, other teams with approval process.
  • Jaeger (contains private repo names): Cloud with automatic approval, other teams with approval process.
  • Infrastructure metrics: All teammates with automatic approval but need to scrape private repo names.

Sourcegraph instances

  • All teammates with automatic approval.