Running Teleport on GCP
We've created this guide to give customers an overview of how to use Teleport on Google Cloud (GCP). This guide provides a high-level introduction to setting up and running Teleport in production.
We have split this guide into:
Teleport Cloud takes care of this setup for you so you can provide secure access to your infrastructure right away.
Get started with a free trial of Teleport Cloud.
As leader in BeyondCorp, GCP already provides some great tools out of the box such as Cloud Identity-Aware Proxy. This is an excellent tool to quickly get setup securely with GCP but it can become complicated to integrate into existing workflows and complicated if you want to share tool across clouds.
You can use Teleport for all the services that you would SSH into. This guide is focused on Google Compute Engine.
We plan on expanding our guide to eventually include using Teleport with Google Kubernetes Engine (GKE).
This guide will cover how to setup, configure and run Teleport on GCP.
GCP Services required to run Teleport in High Availability:
- Compute Engine: VM Instances with Instance Groups
- Computer Engine: Health Checks
- Storage: Cloud Firestore
- Storage: Google Cloud Storage
- Network Services: Load Balancing
- Network Services: Cloud DNS
Other things needed:
- Management Tools: Cloud Deployment Manager
- Stackdriver Logging
We recommend setting up Teleport in High Availability mode. In High Availability mode Firestore stores the state of the system and Google Cloud Storage stores the audit logs.
To run Teleport in a High Availability configuration we recommend using
n1-standard-2 instances in
Production. It's best practice to separate the proxy and authentication server, using
Instance groups for the proxy and auth server.
GCP relies heavily on Health Checks, this is helpful when adding new instances to an instance group.
To enable health checks in Teleport start with
teleport start --diag-addr=0.0.0.0:3000
see Admin Guide: Troubleshooting for more information.
Cloud Firestore This storage backend uses real-time updates to keep individual auth instances in sync and requires Firestore configured in native mode.
Add this storage configuration in teleport section of the config file (by default it's
teleport: storage: type: firestore collection_name: cluster-data project_id: EXAMPLE_gcp-proj-with-firestore-enabled credentials_path: /var/lib/teleport/firestore_creds.json audit_events_uri: ['firestore://events_table_name?projectID=example_Teleport-Project-Name&credentialsPath=/var/lib/teleport/gcs_creds.json']
When creating the Bucket we would recommend setting it up as
Dual-region and with
Standard storage class. Provide access using a
Uniform access control with a Google-managed
When setting up
gs:// session prefix.
storage: ... audit_sessions_uri: 'gs://teleport-session-storage-2?projectID=EXAMPLE_gcp-proj-with-firestore-enabled&credentialsPath=/var/lib/teleport/gcs_creds.json' ...
Load Balancing is required for Proxy and SSH traffic. Use
TCP Load Balancing as
Teleport requires custom ports for SSH and Web Traffic.
Cloud DNS is used to setup the public URL of the Teleport Proxy. Once setup an
record is sufficient.
The Authentication server will need to read and write to Firestore. For this it'll need the correct permission via Server Accounts. Learn how to enable and create service accounts for instances.
Download JSON Service Key
We recommend starting by creating the resources. We highly recommend creating these an infrastructure automation tool such as Cloud Deployment Manager or Terraform.
Follow install instructions from our installation page.
We recommend configuring Teleport as per the below steps:
# # Sample Teleport configuration teleport.yaml file for Auth Server # teleport: nodename: teleport-auth-server data_dir: /var/lib/teleport pid_file: /run/teleport.pid connection_limits: max_connections: 15000 max_users: 250 log: output: stderr severity: DEBUG storage: type: firestore collection_name: cluster-data # Credentials: Path to google service account file, used for Firestore and Google Storage. credentials_path: /var/lib/teleport/gcs_creds.json project_id: example_Teleport-Project-Name audit_events_uri: 'firestore://events?projectID=example_Teleport-Project-Name&credentialsPath=/var/lib/teleport/gcs_creds.json' audit_sessions_uri: 'gs://teleport-session-storage-2?projectID=example_Teleport-Project-Name&credentialsPath=/var/lib/teleport/gcs_creds.json' auth_service: enabled: true tokens: - "proxy:EXAMPLE-PROXY-JOIN-TOKEN" - "node:EXAMPLE-NODE-JOIN-TOKEN" proxy_service: enabled: false ssh_service: enabled: false
2. Setup Proxy
Save the following configuration file as
/etc/teleport.yaml on the Proxy Server:
# enable multiplexing all traffic on TCP port 443 version: v2 teleport: auth_token: EXAMPLE-PROXY-JOIN-TOKEN # We recommend using a TCP load balancer pointed to the auth servers when # setting up in High Availability mode. auth_servers: [ "auth.example.com:3025" ] # enable proxy service, disable auth and ssh ssh_service: enabled: false auth_service: enabled: false proxy_service: enabled: true web_listen_addr: 0.0.0.0:443 public_addr: teleport.example.com:443 # automatically get an ACME certificate for teleport.example.com (works for a single proxy) acme: enabled: true email: [email protected]
3. Set up Teleport Nodes
Save the following configuration file as
/etc/teleport.yaml on the Node:
teleport: auth_token: EXAMPLE-NODE-JOIN-TOKEN # Nodes and other agents can be joined to the cluster via the proxy's public address. # This will establish a reverse tunnel between the proxy and the node which is used for all traffic. auth_servers: [ "teleport.example.com:443" ] # enable ssh service and disable auth and proxy ssh_service: enabled: true auth_service: enabled: false proxy_service: enabled: false
4. Add Users