mirror of
https://github.com/gravitational/teleport.git
synced 2026-10-12 02:15:01 +00:00
rosstimothy
5dd08bd2e2
Caching has become an integral part in functionality provided by teleport. Allowing users to disable the cache was never something that was a recomended configuration - it was predominately used as a stopgap to address an outage. However, over time the cache has become more stable and the need to bypass it should never arise. Additionally, this toggle causes several architectural difficulties that increase complexity and maintainability of teleport. By always enforcing that the cache is on, we can eventually separate the gRPC, backend, and caching layers - a frequent developer experience nightmare. Moving to a world where the cache is always guaranteed to be present and available we will be able to remove layers of abstraction and increase performance. We do still honor `teleport.cache.max_backoff`. While it was tempting to remove all teleport.cache knobs, it seemed that still allowing users to control the backoff interval could alleviate any caching related issues that lead to or are contributing to an outage. This seemed rather important to still offer now that the ability to disable caching no longer exists.
185 lines
8.1 KiB
YAML
185 lines
8.1 KiB
YAML
# By default, this file should be stored in /etc/teleport.yaml
|
|
|
|
# Configuration file version. The current version is "v3".
|
|
version: v3
|
|
|
|
# This section of the configuration file applies to all teleport
|
|
# services.
|
|
teleport:
|
|
# nodename allows one to assign an alternative name this node can be
|
|
# reached by. By default it's equal to hostname.
|
|
#
|
|
# For Teleport-protected SSH servers, nodename must begin with an alphanumeric
|
|
# character, contain only alphanumeric characters, dots, and hyphens, and be
|
|
# no more than 256 characters in length.
|
|
#
|
|
# If a Teleport-protected server has an invalid nodename, Teleport replaces
|
|
# the nodename with the resource ID.
|
|
nodename: graviton
|
|
|
|
# Data directory where Teleport daemon keeps its data.
|
|
data_dir: /var/lib/teleport
|
|
|
|
# PID file for Teleport process
|
|
#pid_file: /var/run/teleport.pid
|
|
|
|
# The invitation token or an absolute path to a file containing the token used
|
|
# to join a cluster. It is not used on subsequent starts.
|
|
# If using a file, it only needs to exist when teleport is first ran.
|
|
#
|
|
# File path example:
|
|
# auth_token: /var/lib/teleport/tokenjoin
|
|
#
|
|
# This is the same as setting join_params.method to "token", and join_params.token_name
|
|
# to the value of auth_token.
|
|
# You should only use either auth_token or join_params.
|
|
auth_token: xxxx-token-xxxx
|
|
|
|
# join_params are parameters to set when joining a cluster via
|
|
# EC2, IAM or a token.
|
|
join_params:
|
|
# When `method` is set to "token", it is the equivalent to using `auth_token` above.
|
|
# You should only use either auth_token or join_params.
|
|
method: "token"|"ec2"|"iam"|"github"|"circleci"|"kubernetes"|"bound_keypair"
|
|
|
|
# If method is not "token", token_name will be will be the name of
|
|
# the joining token resource, e.g., "ec2-token" or "iam-token" as created
|
|
# in the Joining Nodes via EC2 or IAM guides.
|
|
|
|
# If method is "token", token_name will be the invitation token
|
|
# or an absolute path to a file containing the token used to join a cluster.
|
|
# It is not used on subsequent starts.
|
|
# If using a file, it only needs to exist when teleport is first ran.
|
|
#
|
|
# File path example:
|
|
# token_name: /var/lib/teleport/tokenjoin
|
|
token_name: "token-name"
|
|
|
|
# bound_keypair specifies parameters specific to the `bound_keypair` join
|
|
# method and should not be configured if any other join method is configured
|
|
# in the `method` field above.
|
|
bound_keypair:
|
|
# Configures the bound keypair registration secret, used to authenticate
|
|
# the initial agent join.
|
|
registration_secret_value: "1234567890"
|
|
|
|
# Sets the path to a file containing the registration secret. This is
|
|
# useful if you don't want to specify it in this file directly. If this is
|
|
# set, `registration_secret_value` cannot be specified.
|
|
registration_secret_path: /path/to/secret
|
|
|
|
# If using bound keypair static keys, this contains the path to the
|
|
# generated static key. When set, neither of the above
|
|
# `registration_secret_` fields should be set.
|
|
static_key_path: /path/to/key
|
|
|
|
# generic_oidc specifies parameters specific to the `generic_oidc` join
|
|
# method and should be omitted if any other join method is configured in the
|
|
# `method` field above.
|
|
generic_oidc:
|
|
# A command used to fetch a JWT. This can call a platform tool, a custom
|
|
# helper you write, or a tool like `curl` to fetch a JWT from an internal
|
|
# issuer. The first parameter is the executable to run, followed by any
|
|
# arguments. Commands have a default timeout of 1m, which can be
|
|
# overridden. Cannot be used with `env`.
|
|
command: ["example-command", "issue-jwt", "--audience=example.teleport.sh/token"]
|
|
|
|
# Overrides the default command timeout of 1m.
|
|
# timeout: 1m
|
|
|
|
# env is the name of an environment variable containing a JWT. This can be
|
|
# used instead of `command` if the JWT you wish to authenticate with
|
|
# exists in an environment variable already. Cannot be used with
|
|
# `command`, and `timeout` is ignored if set.
|
|
# env: ENV_VAR_NAME
|
|
|
|
# Optional CA pin of the Auth Service. Specifying a CA pin enables new
|
|
# agents to trust a Teleport cluster when joining via the Auth Service
|
|
# directly. You can assign the ca_pin field to the literal value of the CA
|
|
# pin or an absolute path to a file. If you specify a file, the file should
|
|
# only contain the CA pin.
|
|
#
|
|
# You can also specify the value of the ca_pin key as a YAML list of CA pins
|
|
# or file paths, e.g.:
|
|
#
|
|
# ca_pin:
|
|
# - /var/lib/teleport/pin1
|
|
# - /var/lib/teleport/pin2
|
|
ca_pin:
|
|
"sha256:7e12c17c20d9cb504bbcb3f0236be3f446861f1396dcbb44425fe28ec1c108f1"
|
|
|
|
# When running in multi-homed or NATed environments Teleport Nodes need
|
|
# to know which IP it will be reachable at by other Nodes.
|
|
#
|
|
# This value can be specified as FQDN e.g. host.example.com
|
|
advertise_ip: 10.1.0.5
|
|
|
|
# Teleport provides HTTP endpoints for monitoring purposes. They are
|
|
# disabled by default but you can enable them using the diagnosis address.
|
|
diag_addr: "127.0.0.1:3000"
|
|
|
|
# Only use one of auth_server or proxy_server.
|
|
#
|
|
# When you have either the application service or database service enabled,
|
|
# only tunneling through the proxy is supported, so you should specify proxy_server.
|
|
# All other services support both tunneling through the proxy and directly connecting
|
|
# to the auth server, so you can specify either auth_server or proxy_server.
|
|
|
|
# Auth Server address and port to connect to. If you enable the Teleport
|
|
# Auth Server to run in High Availability configuration, the address should
|
|
# point to a Load Balancer.
|
|
# If adding a node located behind NAT, use the Proxy URL (e.g. teleport-proxy.example.com:443)
|
|
# and set `proxy_server` instead.
|
|
auth_server: 10.1.0.5:3025
|
|
|
|
# Proxy Server address and port to connect to. If you enable the Teleport
|
|
# Proxy Server to run in High Availability configuration, the address should
|
|
# point to a Load Balancer.
|
|
proxy_server: teleport-proxy.example.com:443
|
|
|
|
# Relay tunnel address and port to connect to, if set. Used by some services
|
|
# to open additional tunnels to a Relay group if Teleport is configured to
|
|
# connect to a Proxy Server. If a Relay group consists of more than one
|
|
# Relay Service instance, the address should point to a Load Balancer.
|
|
# Used in Teleport v18.3.0 and later for the SSH service.
|
|
relay_server: teleport-relay.example.com:3042
|
|
|
|
# The duration (in string form) of the delay between receiving a termination
|
|
# signal and the beginning of the shutdown procedures. It can be used to
|
|
# give time to load balancers to stop routing connections to the Teleport
|
|
# instance while the instance is still capable of handling them. If unset or
|
|
# negative, no delay is applied.
|
|
#shutdown_delay: "0s"
|
|
|
|
# Teleport can limit the number of connections coming from each client
|
|
# IP address to avoid abuse. These limits are enforced separately for
|
|
# each service (Auth, Proxy, SSH, Kubernetes, Database, Windows
|
|
# Desktop, and Application).
|
|
connection_limits:
|
|
max_connections: 1000
|
|
|
|
# Auth Service connection configuration.
|
|
# These settings can be tweaked to control how aggressively the Proxy or Agent instances will retry to connect. In addition
|
|
# each instance will apply jitter.
|
|
# auth_connection_config:
|
|
# upper_limit_between_retries: "90s" # Cannot be lower than 10s
|
|
# initial_connection_delay: "9s" # When unset upper_limit_between_retries / 10
|
|
# backoff_step_duration: "18s" # When unset upper_limit_between_retries / 5
|
|
|
|
# Logging configuration. Possible output values to disk via
|
|
# '/var/lib/teleport/teleport.log',
|
|
# 'stdout', 'stderr' and 'syslog'. Possible severity values are DEBUG, INFO (default), WARN,
|
|
# and ERROR.
|
|
log:
|
|
output: /var/lib/teleport/teleport.log
|
|
severity: INFO
|
|
|
|
# Log format configuration
|
|
# Possible output values are 'json' and 'text' (default).
|
|
# Possible extra_fields values include: timestamp, component, caller,
|
|
# and level.
|
|
# All extra fields are included by default.
|
|
format:
|
|
output: text
|
|
extra_fields: [level, timestamp, component, caller]
|