teleport-kube-agent Chart Reference
The teleport-kube-agent
Helm chart is used to configure a Teleport agent that
runs in a remote Kubernetes cluster to provide access to resources in your
infrastructure.
You can browse the source on GitHub.
This reference details available values for the teleport-kube-agent
chart.
Backing up production instances, environments, and/or settings before making permanent modifications is encouraged as a best practice. Doing so allows you to roll back to an existing state if needed.
What the chart deploys
Teleport services
The teleport-kube-agent
chart can run any or all of three Teleport services:
Teleport service | Name for roles and tctl tokens add | Purpose |
---|---|---|
kubernetes_service | kube | Uses Teleport to handle authentication with and proxy access to a Kubernetes cluster |
application_service | app | Uses Teleport to handle authentication with and proxy access to web-based applications |
database_service | db | Uses Teleport to handle authentication with and proxy access to databases |
discovery_service | discovery | Uses Teleport to discover new resources and dynamically add them to the cluster |
Legacy releases
Releases of this chart installed before version 11 are considered legacy
releases, which launch the Teleport pod as a Deployment
if no storage was
configured.
In version 11 and above, the chart launches the Teleport pod as a StatefulSet
even when the chart is configured not to use external storage, and the Teleport pod
reads its state from a Kubernetes Secret
.
While the Teleport pod does not require external storage, you can still use the
storage.enabled
field to configure the way the Teleport pod
reads data from a persistent volume.
To learn how upgrading from a legacy release to version 11 will affect resources launched by this chart, see the resource list.
Kubernetes resources
The teleport-kube-agent
chart deploys the following Kubernetes resources:
Kind | Default Name | Description | When Deployed |
---|---|---|---|
StatefulSet | The release name | Running a user-configured Teleport pod. | Always. |
Secret | joinTokenSecret.name (default: teleport-kube-agent-join-token ) | Used for managing the state of the Teleport pod. | joinTokenSecret.secret is true . |
Deployment | The release name | Runs a user-configured Teleport pod. | storage.enabled is false and the chart is being upgraded. Fresh installs will deploy a StatefulSet instead. |
Role | The roleName option, if given, or the release name. | Used to manage the state of the Teleport pod via Kubernetes secrets. | Always. |
ClusterRole | clusterRoleName , if given, or the release name. | Allows impersonating users, groups, and service accounts, getting pods, and creating SelfSubjectAccessReview s so the Teleport pod can manage access to resources in its Kubernetes cluster. | Always. |
ClusterRoleBinding | clusterRoleBindingName , if provided, or the release name | Enables the Teleport pod to manage access to resources in the Kubernetes cluster. | Always. |
RoleBinding | roleBindingName , if given, or the release name | Enables the Teleport pod to manage access to resources in the Kubernetes cluster. | Always. |
ServiceAccount | serviceAccount.name , if given, or the release name | Enables the Teleport pod to manage access to resources in the Kubernetes cluster. | serviceAccount.create is true |
PodDisruptionBudget | The release name | Ensure high availability for the Teleport pod. | highAvailability.podDisruptionBudget.enabled is true . |
ServiceAccount | The release name, suffixed by -hook | Used to delete legacy Deployment s in order to deploy a StatefulSet instead. Removed once the upgrade is complete. | If the teleport-kube-agent release contains a legacy Deployment resource. |
Role | The release name, suffixed by -hook | Used to delete legacy Deployment s in order to deploy a StatefulSet instead. Removed once the upgrade is complete. | If the teleport-kube-agent release contains a legacy Deployment resource. |
RoleBinding | The release name, suffixed by -hook | Used to delete legacy Deployment s in order to deploy a StatefulSet instead. Removed once the upgrade is complete. | If the teleport-kube-agent release contains a legacy Deployment resource. |
Job | The release name, suffixed by -hook | Used to delete legacy Deployment s in order to deploy a StatefulSet instead. Removed once the upgrade is complete. | If the teleport-kube-agent release contains a legacy Deployment resource. |
ConfigMap | The release name | Contains the configuration for the Teleport pod. | Always. |
PodSecurityPolicy | The release name | Enforces security requirements for pods deployed by teleport-kube-agent . | podSecurityPolicy.enabled is true and the Kubernetes cluster version is < 1.23. |
Role | The release name, suffixed by -psp | Enforces security requirements for pods deployed by teleport-kube-agent . | podSecurityPolicy.enabled is true and the Kubernetes cluster version is < 1.23. |
RoleBinding | The release name, suffixed by -psp | Enforces security requirements for pods deployed by teleport-kube-agent . | podSecurityPolicy.enabled is true and the Kubernetes cluster version is < 1.23. |
roles
Type | Default |
---|---|
string | "kube" |
roles
is a comma-separated list of services which will be enabled
when running the teleport-kube-agent
chart.
Services | Value for roles | Mandatory additional settings for this role |
---|---|---|
Teleport Kubernetes service | kube | kubeClusterName |
Teleport Application service | app | apps or appResources |
Teleport Database service | db | databases or databaseResources |
Teleport Discovery service | discovery | kubeClusterName |
For example:
roles: kube,app,discovery
proxyAddr
Type | Default |
---|---|
string | "" |
proxyAddr
provides the public-facing Teleport Proxy Service endpoint
which should be used to join the cluster. This is the same URL used to access
the web UI of your Teleport cluster. The port used is usually either 3080 or 443.
Here are a few examples:
Deployment method | Example proxy_service.public_addr |
---|---|
On-prem Teleport cluster | teleport.example.com:3080 |
Teleport Cloud cluster | example.teleport.sh:443 |
teleport-cluster Helm chart | teleport.example.com:443 |
enterprise
Type | Default |
---|---|
bool | false |
enterprise
controls if the teleport-kube-agent
chart should deploy
the OSS version or the enterprise version of the container image.
This must be set to true
when connecting to Teleport Cloud or self-hosted
Teleport Enterprise clusters to allow the agent to leverage enterprise features.
authToken
Type | Default |
---|---|
string | "" |
authToken
provides a Teleport join token which will be used to join
the Teleport instance to a Teleport cluster. authToken
only supports the token
join method.
For other methods such as kubernetes
, iam
or gcp
, the value
joinParams
should be used as it supports more methods to
join the Teleport cluster. joinParams
takes precedence if both authToken
and joinParams
are set.
A token must be specified for the agent to join the Teleport cluster, either
via authToken
, joinParams
, or
an existing Kubernetes Secret.
The token used must at least grant the required system roles. For example, if
the chart roles
is kube,app
, the token should allow the system
roles App
and Kube
.
joinParams
joinParams
controls how the Teleport agent joins the Teleport cluster.
These sub-values must be configured for the agent to connect to a cluster.
This value serves the same purpose as authToken
but supports
all join methods. When set, it takes precedence over authToken
.
Its usage should be preferred.
joinParams.method
Type | Default |
---|---|
string | "token" |
joinParams.method
controls which join method will be used by the
instance to join the Teleport cluster.
See the join method reference for the list of possible values, the implications of each join method, and guides to set up each method.
Common join-methods for the teleport-kube-agent
are:
token
: the most basic one, with regular ephemeral secret tokenskubernetes
: either thein-cluster
variant (if the agent runs in the same Kubernetes cluster as theteleport-cluster
chart) or theJWKS
variant (works in every Kubernetes cluster, regardless of the Teleport Auth Service location).
joinParams.tokenName
Type | Default |
---|---|
string | "" |
joinParams.tokenName
controls which token is used by the agent to
join the Teleport cluster.
When joinParams.method
is a delegated join method,
the value is not sensitive.
When joinParams.method
is token
(by default), joinParams.tokenName
contains the secret token itself. In this case, the value is sensitive and
is automatically stored in a Kubernetes Secret instead of being directly
included in the agent's configuration.
If method is token
, joinParams.tokenName
can be empty if the token
is provided through an existing Kubernetes Secret, see
joinTokenSecret
for more details and instructions.
kubeClusterName
Type | Default |
---|---|
string | "" |
kubeClusterName
sets the name used for the Kubernetes cluster proxied by
the Teleport agent. This name will be shown to Teleport users connecting to
the cluster.
This setting is required if the chart roles
contains kube
.
apps
Type | Default |
---|---|
list | [] |
apps
is a static list of applications that should be proxied by
the agent. See the Teleport Application access documentation
for more details.
Proxied applications can be defined statically (through this value) or dynamically
(through the appResources
value).
One of apps
and appResources
is required if the chart roles
contains app
.
You can specify multiple apps by adding elements to the list. For example:
apps:
- name: grafana
uri: http://localhost:3000
labels:
purpose: monitoring
- name: jenkins
uri: http://jenkins:8080
labels:
purpose: ci
You can see a list of all the supported values that can be used in a Teleport Application Service configuration in the Application Service Configuration Reference.
appResources
Type | Default |
---|---|
list | [] |
appResources
is a set of labels the agent will monitor. Any application
matching those labels will be proxied by the agent. See the Teleport
Application access documentation
for more details.
Proxied applications can be defined statically (through apps
) or
dynamically (through this value).
One of apps
and appResources
is required if the chart roles
contains app
.
You can specify multiple selectors by including additional list elements. For example:
appResources:
- labels:
"env": "prod"
- labels:
"env": "test"
Once appResources
is set, you can dynamically register application with
tsh
by following the Dynamic App Registration guide.
clusterDomain
Type | Default |
---|---|
string | "cluster.local" |
clusterDomain
sets the domain name used by the Kubernetes cluster. This value is used to build the
FQDN application URIs. For example, if the cluster domain is anything.local
, the agent will proxy the application
myapp
running in the default
namespace at http://myapp.default.svc.anything.local
. You must manually set this value
to match your cluster domain if it is different from the default value cluster.local
.
awsDatabases
Type | Default |
---|---|
list | [] |
awsDatabases
configures AWS database auto-discovery.
For AWS database auto-discovery to work, your Database Service pods will need to use a role which has appropriate IAM permissions as per the database documentation.
After configuring a role, you can use an eks.amazonaws.com/role-arn
annotation with the annotations.serviceAccount
value to associate it with the service account and grant permissions:
annotations:
serviceAccount:
eks.amazonaws.com/role-arn: arn:aws:iam::1234567890:role/my-rds-autodiscovery-role
You can specify multiple database filters by adding elements to the list.
types
is a list containing the types of AWS databases that should be discovered.regions
is a list of AWS regions which should be scanned for databases.tags
can be used to set AWS tags that must be matched for databases to be discovered.
For example:
roles: db
awsDatabases:
- types: ["rds"]
regions: ["us-east-1", "us-west-2"]
tags:
"environment": "production"
- types: ["rds"]
regions: ["us-east-1"]
tags:
"environment": "dev"
- types: ["rds"]
regions: ["eu-west-1"]
tags:
"*": "*"
annotations:
serviceAccount:
eks.amazonaws.com/role-arn: arn:aws:iam::1234567890:role/my-rds-autodiscovery-role
azureDatabases
Type | Default |
---|---|
list | [] |
azureDatabases
configures Azure database auto-discovery.
For Azure database auto-discovery to work, your Database Service pods will need to have appropriate IAM permissions as per the database documentation.
After configuring a service principal with appropriate IAM permissions, you must pass credentials to the pods. The easiest way is to use an Azure client secret.
First, create in the chart installation namespace a Kubernetes Secret
containing the azure client secret:
$ kubectl create secret generic teleport-azure-client-secret --from-literal=client_secret=<your-azure-client-secret>
secret/teleport-azure-client-secret created
Then, use the extraEnv
value to set the pods environment variables:
extraEnv:
- name: AZURE_CLIENT_SECRET
valueFrom:
secretKeyRef:
name: teleport-azure-client-secret
key: client_secret
optional: false
- name: AZURE_TENANT_ID
value: "11111111-2222-3333-4444-555555555555"
- name: AZURE_CLIENT_ID
value: "11111111-2222-3333-4444-555555555555"
You can specify multiple database filters by adding elements to the list.
Required fields for each filter:
types
is a list containing the types of Azure databases that should be discovered.tags
can be used to set Azure resource tags that must be matched for databases to be discovered.
Optional fields for each filter:
regions
is a list of Azure regions which should be scanned for databases.subscriptions
can be used to discover databases within matching Azure subscriptions.resource_groups
can be used to discover databases within matching Azure resource groups.
The default for each of these optional settings is *
, which will auto-discover in all
subscriptions, regions, or resource groups accessible by the Teleport service
principal in Azure.
For example:
roles: db
azureDatabases:
- types: ["mysql", "postgres"]
tags:
"*": "*"
- types: ["mysql"]
tags:
"env": ["dev", "staging"]
"origin": "alice"
regions: ["eastus", "centralus"]
subscriptions: ["subID1", "subID2"]
resource_groups: ["group1", "group2"]
extraEnv:
- name: AZURE_CLIENT_SECRET
valueFrom:
secretKeyRef:
name: teleport-azure-client-secret
key: client_secret
optional: false
- name: AZURE_TENANT_ID
value: "11111111-2222-3333-4444-555555555555"
- name: AZURE_CLIENT_ID
value: "11111111-2222-3333-4444-555555555555"
databases
Type | Default |
---|---|
list | [] |
databases
is a static list of databases that should be proxied by
the agent. See the Teleport Database access documentation
for more details.
Proxied applications can be defined statically (through this value) or dynamically
(through the databaseResources
value).
You can specify multiple databases by adding additional list elements.
values.yaml
example:
databases:
- name: aurora-postgres
uri: postgres-aurora-instance-1.xxx.us-east-1.rds.amazonaws.com:5432
protocol: postgres
aws:
region: us-east-1
static_labels:
env: staging
- name: mysql
uri: mysql-instance-1.xxx.us-east-1.rds.amazonaws.com:3306
protocol: mysql
aws:
region: us-east-1
static_labels:
env: staging
You can see a list of all the supported values which can be used in a Teleport database service configuration here.
Database CAs can be trusted on a per-database basis. You must create a secret containing the database CA certificate in the same namespace as Teleport using a command like:
$ kubectl create secret generic my-postgres-ca --from-file=ca.pem=/path/to/database-ca.pem
Then, deploy the Helm chart with the following values:
databases:
- name: my-postgres
uri: postgres.example.com:5432
protocol: postgres
tls:
ca_cert_file: "/etc/teleport-tls-db/my-postgres/ca.pem"
extraVolumes:
- name: my-postgres-ca
secret:
secretName: my-postgres-ca
extraVolumeMounts:
- name: my-postgres-ca
mountPath: /etc/teleport-tls-db/my-postgres
readOnly: true
databaseResources
Type | Default |
---|---|
list | [] |
databaseResources
is a set of labels the agent will monitor.
Any database matching those labels will be proxied by the agent. See the Teleport
Database access
documentation
for more details.
Proxied databases can be defined statically (through databases
) or
dynamically (through this value).
You can specify multiple selectors by including additional list elements. For example:
databaseResources:
- labels:
"env": "prod"
"engine": "postgres"
- labels:
"env": "test"
"engine": "mysql"
Once databaseResources
is set, you can dynamically register database with
tsh
by following this guide.
kubernetesDiscovery
Type | Default |
---|---|
list | [{"labels":{"*":"*"},"namespaces":["*"],"types":["app"]}] |
kubernetesDiscovery
controls the Discovery Service configuration
if it's enabled.
The Discovery Service is enabled when the agent roles
contains "discovery".
The Discovery service automatically detects Kubernetes Services and configures
the agent to provide access to them. See the Kubernetes App Discovery
documentation
for more details.
The Discovery mechanism ignores Kubernetes services running in the kube-system
and
kube-public
namespaces.
The default value will try to discover all apps running in Kubernetes. The discovery can be restricted through this value. For example:
kubernetesDiscovery:
- types: ["app"]
namespaces: [ "toronto", "porto" ]
labels:
env: staging
- types: ["app"]
namespaces: [ "seattle", "oakland" ]
labels:
env: testing
teleportVersionOverride
Type | Default |
---|---|
string | "" |
teleportVersionOverride
controls the Teleport Kubernetes Operator
image version deployed by the chart.
Normally, the version of the Teleport Kubernetes Operator matches the version of the chart. If you install chart version 15.0.0, you'll use Teleport version 15.0.0. Upgrading the agent is done by upgrading the chart.
teleportVersionOverride
is intended for development and MUST NOT be
used to control the Teleport version in a typical deployment. This
chart is designed to run a specific Teleport version. You will face
compatibility issues trying to run a different Teleport version with it.
If you want to run Teleport version X.Y.Z
, you should use
helm install --version X.Y.Z
instead.
caPin
Type | Default |
---|---|
list | [] |
caPin
is a list of CA pins the agent must validate when joining
the Teleport cluster to ensure it is connecting to the correct Auth Service.
This is only used when joining the Auth Service directly. When joining through a Proxy Service, authenticity is guaranteed by the x509 certificate used for the TLS connection.
Each list element can be the pin itself (recommended), or a path to a file
containing the pin. For the latter, it is your responsibility to mount
the file, using extraVolumes
.
insecureSkipProxyTLSVerify
Type | Default |
---|---|
bool | false |
insecureSkipProxyTLSVerify
disables TLS verification of the TLS
certificate presented by the Proxy Service.
This can be used for joining a Teleport instance to a Teleport cluster which does not have valid TLS certificates for testing.
Using a self-signed TLS certificate and disabling TLS verification is OK for testing, but is not viable when running a production Teleport cluster as it will drastically reduce security. You must configure valid TLS certificates on your Teleport cluster for production workloads.
One option might be to use Teleport's built-in ACME support or enable cert-manager support.
teleportConfig
Type | Default |
---|---|
object | {} |
teleportConfig
contains YAML teleport configuration to pass to the
Teleport pods. The configuration will be merged with the chart-generated
configuration and will take precedence in case of conflict.
See the Teleport Configuration Reference for the list of supported fields.
teleportConfig:
app_service:
debug_app: true
discovery_service:
enabled: true
azure:
- types: ["aks"]
tags:
"*":"*"
tls
tls
contains settings for mounting your own TLS material in the agent pod.
The agent does not expose a TLS server, so this is only used to trust CAs.
tls.existingCASecretName
Type | Default |
---|---|
string | "" |
tls.existingCASecretName
sets the SSL_CERT_FILE
environment
variable to load a trusted CA or bundle in PEM format into Teleport pods.
The injected CA will be used to validate TLS communications, with the Proxy
Service, with upstream applications or databases.
The recommended way to trust a database CA is to do it per-database instead
of adding the CA to the global Teleport trust store. It allows to trust
multiple CAs while limiting the trust scope to their specific databases.
See the databases
section.
You must create a secret containing the CA certs in the same namespace as Teleport using a command like:
$ kubectl create secret generic my-root-ca --from-file=ca.pem=/path/to/root-ca.pem
The key containing the root CA in the secret must be ca.pem
.
updater
updater
controls whether the Kube Agent Updater should be deployed alongside
the teleport-kube-agent
. The updater fetches the target version, validates the
image signature, and updates the teleport deployment. The enterprise
value should
have been set to true
.
All Kubernetes-specific fields such as tolerations
, affinity
, nodeSelector
,
... default to the agent values. However, they can be overridden from the
updater
object. For example:
# the agent pod requests 1cpu and 2 GiB of memory. It also has a memory limit.
resources:
requests:
cpu: "1"
memory: "2Gi"
limits:
memory: "2Gi"
# the updater pod requests 0.5 cpu and 512MiB of memory. The memory limit has also been unset.
updater:
resources:
requests:
cpu: "0.5"
memory: "512Mi"
limits: ~
Other updater-specific values that can be defined in updater
are described
below.
updater.enabled
Type | Default |
---|---|
bool | false |
updater.enabled
Enables the Kube Agent Updater and deploys it alongside the Teleport Agent.
You can enable this when:
- using Teleport Cloud and your tenant is enrolled into automatic updates.
(You can check this through the web UI, choose
Add Kubernetes
andEnroll New Resource of type Kubernetes
, and check if the value is turned on.) - using self-hosted Teleport and you maintain your own version server.
You must not enable this when:
- you are a Teleport Cloud customer not enrolled in automatic updates.
- you are a self-hosted Teleport user and have not set up your Teleport cluster to support automatic updates.
updater.versionServer
Type | Default |
---|---|
string | "https://{{ .Values.proxyAddr }}/v1/webapi/automaticupgrades/channel" |
updater.versionServer
is the URL of the version server the agent
fetches the target version from. The complete version endpoint is built by
concatenating versionServer
and releaseChannel
.
This field supports gotemplate.
You must set this if the updater is enabled, and you are not a Teleport Cloud user.
You must not change the default values if you are a Teleport Cloud user.
updater.releaseChannel
Type | Default |
---|---|
string | "stable/cloud" |
updater.releaseChannel
is the release channel the updater
subscribes to.
The complete version endpoint is built by concatenating
versionServer
and releaseChannel
.
You must not change the default value if you are a Teleport Cloud user unless
instructed by Teleport support.
You can change this value if the updater is enabled, you are not a Teleport Cloud user, and manage your own version server.
updater.image
Type | Default |
---|---|
string | "public.ecr.aws/gravitational/teleport-kube-agent-updater" |
updater.image
sets the container image used for Teleport updater
pods run when updater.enabled
is true.
You can override this to use your own Teleport Kube Agent Updater image rather than a Teleport-published image.
updater.serviceAccount
updater.serviceAccount.name
Type | Default |
---|---|
string | "" |
updater.serviceAccount.name
is the updater Kubernetes Service
Account name. When unset, it defaults to <kube agent sa name>-updater
updater.pullCredentials
Type | Default |
---|---|
string | "" |
updater.pullCredentials
configures how the updater attempts to
get the image pull credentials used to validate the image signature.
This is not required when pulling images from official public Teleport registries (chart's default).
Supported values are amazon
, google
, docker
and none
.
updater.extraArgs
Type | Default |
---|---|
list | [] |
updater.extraArgs
contains additional arguments to pass to the updater
binary.
updater.extraVolumes
Type | Default |
---|---|
list | [] |
updater.extraVolumes
contains extra volumes to mount into the Updater pods.
See the Kubernetes volume documentation
for more details.
For example:
updater:
extraVolumes:
- name: myvolume
secret:
secretName: testSecret
updater.extraVolumeMounts
Type | Default |
---|---|
list | [] |
updater.extraVolumeMounts
contains extra volumes mounts for the updater.
See the Kubernetes volume documentation
for more details.
For example:
updater:
extraVolumesMounts:
- name: myvolume
mountPath: /path/on/host
existingDataVolume
Type | Default |
---|---|
string | "" |
existingDataVolume
is the name of an existing Kubernetes Persistent
Volume that should be mounted at /var/lib/teleport
.
This is only useful if you had a previous agent running with persistence enabled and want for a new agent to reuse the volume.
podSecurityPolicy
podSecurityPolicy.enabled
Type | Default |
---|---|
bool | true |
podSecurityPolicy.enabled
controls if the chart should deploy a Kubernetes
PodSecurityPolicy.
By default, Teleport charts used to install a podSecurityPolicy
.
PodSecurityPolicy resources (PSP) have been removed in Kubernetes 1.25 and replaced since 1.23 by PodSecurityAdmission (PSA). If you are running on Kubernetes 1.23 or later, it is recommended to disable PSPs and use PSAs. The steps are documented in the PSP removal guide.
This value will be removed in a future chart version.
labels
Type | Default |
---|---|
object | {} |
labels
is the map of key-value pairs that will be applied on the
Teleport resource representing the Kubernetes cluster. These labels can then
be used with Teleport's RBAC policies to define access rules for the cluster.
This is only used when the roles
contains kube
.
These are Teleport-specific RBAC labels, not Kubernetes labels.
For historical/backwards compatibility reasons, these labels will only be applied to the Kubernetes cluster being joined via the Teleport Kubernetes service.
To set labels for applications, add a labels
element to the apps
section.
To set labels for databases, add a static_labels
element to the databases
section.
For more information on how to set static/dynamic labels for Teleport services, see labelling nodes and applications.
For example:
labels:
environment: production
region: us-east
highAvailability
highAvailability
contains settings controlling the availability of the
Teleport agent deployed by the chart.
The availability can be increased by:
- running more replicas with
replicaCount
- requiring that the Pods are not scheduled on the same Kubernetes Node with
requireAntiAffinity
- by asking Kubernetes not to delete all pods at the same time with
podDisruptionBudget
.
Even with highAvailability settings Restarting/rolling-out pods can still cause
disruption for established long-lived sessions, like kubectl exec
or
database shells.
highAvailability.replicaCount
Type | Default |
---|---|
int | 1 |
highAvailability.replicaCount
is the number of agent replicas deployed by the Chart.
Set to a number higher than 1
for a high availability mode where multiple Teleport pods will be deployed.
As a rough guide, we recommend configuring one replica per distinct availability zone where your cluster has worker nodes.
2 replicas/availability zones will be fine for smaller workloads. 3-5 replicas/availability zones will be more appropriate for bigger clusters with more traffic.
When adding new replicas to an existing agent, you must ensure the provided token
(via authToken
, joinParams
, or joinTokenSecret
)
is still valid. Each replica has its own identity and needs to join the Teleport
cluster on its first startup.
highAvailability.requireAntiAffinity
Type | Default |
---|---|
bool | false |
highAvailability.requireAntiAffinity
configures Kubernetes requiredDuringSchedulingIgnoredDuringExecution
to require that multiple Teleport pods must not be scheduled on the same physical host.
This can result in Teleport pods failing to be scheduled in very small clusters or during node downtime, so should be used with caution.
Setting highAvailability.requireAntiAffinity
to false
(the default)
uses preferredDuringSchedulingIgnoredDuringExecution
to make node
anti-affinity a soft requirement.
This setting only has any effect when highAvailability.replicaCount
is greater than 1
.
highAvailability.podDisruptionBudget
highAvailability.podDisruptionBudget
controls how the chart creates and
configures a Kubernetes PodDisruptionBudget to ensure Kubernetes does not
delete all agent replicas at the same time.
highAvailability.podDisruptionBudget.enabled
Type | Default |
---|---|
bool | false |
highAvailability.podDisruptionBudget.enabled
makes the chart create
a Kubernetes PodDisruptionBudget for the agent pods.
highAvailability.podDisruptionBudget.minAvailable
Type | Default |
---|---|
int | 1 |
highAvailability.podDisruptionBudget.minAvailable
is the minimum
available pod specified on the PodDisruptionBudget.
podMonitor
podMonitor
controls the PodMonitor CR (from monitoring.coreos.com/v1)
This CRD is managed by the prometheus-operator and allows workload to
get monitored. To use this value, you need to run a prometheus-operator
in the cluster for this value to take effect.
See https://prometheus-operator.dev/docs/prologue/introduction/
podMonitor.enabled
Type | Default |
---|---|
bool | false |
podMonitor.enabled
controls if the chart deploys a PodMonitor.
This is disabled by default as it requires the PodMonitor CRD to be installed.
podMonitor.additionalLabels
Type | Default |
---|---|
object | {} |
podMonitor.additionalLabels
adds labels on the PodMonitor.
This is used to be selected by a specific prometheus instance.
For example:
podMonitor:
additionalLabels:
prometheus: default
podMonitor.interval
Type | Default |
---|---|
string | "30s" |
podMonitor.interval
is the interval between two metrics scrapes.
storage
storage
controls how the agent stores data in a Kubernetes Persistent Volume.
Since Teleport 12, the agent does not need PV storage to keep its identity across
restarts: it stores it in a Kubernetes Secret. This means the teleport-kubernetes-agent
can use one-time and short-lived join tokens, it will retain its identity and
secrets even after a restart.
The main benefit of enabling storage is to persist not-yet-uploaded session recordings after Pod termination, when the Teleport session recording mode is not synchronous.
storage.enabled
Type | Default |
---|---|
bool | false |
storage.enabled
enables the creation of a Kubernetes persistent
volume to hold Teleport instance state.
storage.storageClassName
Type | Default |
---|---|
string | "" |
storage.storageClassName
controls which Kubernetes StorageClass
the chart uses when creating Persistent Volume Claims. A StorageClass with
the provided name must exist on the Kubernetes cluster.
storage.requests
Type | Default |
---|---|
string | "128Mi" |
storage.requests
is the size of the persistent volume to create.
adminClusterRoleBinding
adminClusterRoleBinding
optionally creates a cluster admin role binding.
This is useful for granting cluster admin permissions to a Kubernetes Group
other than the default system:masters
group.
GKE Autopilot clusters forbid using the system:masters
group for impersonation
and require a custom group to be used instead.
adminClusterRoleBinding.create
Type | Default |
---|---|
bool | false |
adminClusterRoleBinding.create
controls if the chart should create
an additional admin cluster role binding.
adminClusterRoleBinding.name
Type | Default |
---|---|
string | "cluster-admin" |
adminClusterRoleBinding.name
is the name of the created admin
cluster role binding.
image
Type | Default |
---|---|
string | "public.ecr.aws/gravitational/teleport-distroless" |
image
sets the container image used for Teleport OSS agent pods
created by the chart.
You can override this to use your own Teleport image rather than a Teleport-published image.
When using the Teleport Kube Agent Updater, you must ensure the image is available before the updater version target gets updated and Kubernetes tries to pull the image.
For this reason, it is strongly discouraged to set a custom image when using automatic updates. Teleport Cloud uses automatic updates by default.
Since version 13, hardened distroless images are used by default.
You can use the deprecated debian-based images by setting the value to
public.ecr.aws/gravitational/teleport
. Those images will be
removed with teleport 15.
This setting only takes effect when enterprise
is false
.
When running an enterprise version, you must use
enterpriseImage
instead.
enterpriseImage
Type | Default |
---|---|
string | "public.ecr.aws/gravitational/teleport-ent-distroless" |
enterpriseImage
sets the container image used for Teleport Enterprise
agent pods created by the chart.
You can override this to use your own Teleport image rather than a Teleport-published image.
When using the Teleport Kube Agent Updater you must ensure the image is available before the updater version target gets updated and Kubernetes tries to pull the image.
For this reason, it is strongly discouraged to set a custom image when using automatic updates. Teleport Cloud uses automatic updates by default.
Since version 13, hardened distroless images are used by default.
You can use the deprecated debian-based images by setting the value to
public.ecr.aws/gravitational/teleport-ent
. Those images will be
removed with teleport 15.
This setting only takes effect when enterprise
is true
.
When running an enterprise version, you must use image
instead.
imagePullSecrets
Type | Default |
---|---|
list | [] |
imagePullSecrets
is a list of secrets containing authorization tokens
which can be optionally used to access a private Docker registry.
See the Kubernetes reference for more details.
clusterRoleName
Type | Default |
---|---|
string | "" |
clusterRoleName
can be optionally used to override the name of the
Kubernetes ClusterRole
used by the agent's ServiceAccount
.
Most users will not need to change this.
clusterRoleBindingName
Type | Default |
---|---|
string | "" |
clusterRoleBindingName
can be optionally used to override the name
of the Kubernetes ClusterRoleBinding
used by the agent's ServiceAccount
.
Most users will not need to change this.
roleName
Type | Default |
---|---|
string | "" |
roleName
provides a custom name for the Role
resource that the
teleport-kube-agent
chart creates for the Teleport pod. By default, the Role
has the name of the Helm release.
You should set this value if there is a Role
resource in the namespace of your
teleport-kube-agent
resources with the same name as your teleport-kube-agent
release.
roleBindingName
Type | Default |
---|---|
string | "" |
roleBindingName
provides a custom name for the RoleBinding
resource that the
teleport-kube-agent
chart creates for the Teleport pod. By default, the
RoleBinding
has the name of the Helm release.
You should set this value if there is a RoleBinding
resource in the namespace
of your teleport-kube-agent
resources with the same name as your
teleport-kube-agent
release.
serviceAccountName
Type | Default |
---|---|
string | "" |
serviceAccountName
is deprecated and will be removed in a future
version. Use serviceAccount.name
instead.
serviceAccount
serviceAccount
controls the Kubernetes ServiceAccounts deployed and used by
the chart.
serviceAccount.create
Type | Default |
---|---|
bool | true |
serviceAccount.create
controls whether Helm Chart creates the
Kubernetes ServiceAccount
resources for the agent and optionally for the
updater.
When off, you are responsible for creating the appropriate ServiceAccount
resources.
serviceAccount.name
Type | Default |
---|---|
string | "" |
serviceAccount.name
sets the name of the ServiceAccount
resource
used by the chart. By default, the ServiceAccount
has the name of the
Helm release.
rbac
rbac.create
Type | Default |
---|---|
bool | true |
rbac.create
controls if the chart should create RBAC Kubernetes resources.
- When
true
, the chart creates bothClusterRole
andClusterRoleBinding
resources for the agent, andRole
/RoleBinding
for the updater if enabled. - When
false
, the chart does not create theRole
andRoleBinding
resources. The user is responsible for deploying and maintaining them separately.
This value can be set to false
when deploying in constrained environments
where the user deploying the operator is not allowed to edit RBAC resources.
joinTokenSecret
joinTokenSecret
manages the join token secret creation and its name.
See the joinParams
section for more details.
joinTokenSecret.create
Type | Default |
---|---|
bool | true |
joinTokenSecret.create
controls whether the chart creates the
Kubernetes Secret
containing the Teleport join token.
If false, you must create a Kubernetes Secret with the configured name in
the Helm release namespace.
joinTokenSecret.name
Type | Default |
---|---|
string | "teleport-kube-agent-join-token" |
joinTokenSecret.name
is the name of the Kubernetes Secret
containing the Teleport join token used by the chart.
If joinTokenSecret.create
is false
, the chart will not attempt to create the secret itself.
Instead, it will read the value from an existing secret. joinTokenSecret.name
configures the name of this secret. This allows you to configure this secret externally and avoid having a plaintext
join token stored in your Teleport chart values.
To create your own join token secret, you can use a command like this:
$ kubectl --namespace teleport create secret generic my-token-secret --from-literal=auth-token=<replace-with-actual-token>
The key used for the auth token inside the secret must be auth-token
, as in the command above.
For example:
joinTokenSecret:
create: false
name: my-token-secret
joinParams:
method: "token"
tokenName: ""
log
log
controls the agent logging.
log.level
Type | Default |
---|---|
string | "INFO" |
log.level
is the log level for the Teleport process.
Available log levels are: DEBUG
, INFO
, WARNING
, ERROR
.
The default is INFO
, which is recommended in production.
DEBUG
is useful during first-time setup or to see more detailed logs for debugging.
log.output
Type | Default |
---|---|
string | "stderr" |
log.output
sets the output destination for the Teleport process.
This can be set to any of the built-in values: stdout
, stderr
or syslog
to use that destination.
The value can also be set to a file path (such as /var/log/teleport.log
)
to write logs to a file. Bear in mind that a few service startup messages
will still go to stderr
for resilience.
log.format
Type | Default |
---|---|
string | "text" |
log.format
sets the log output format for the Teleport process.
Possible values are text
(default) or json
.
log.extraFields
Type | Default |
---|---|
list | ["timestamp","level","component","caller"] |
log.extraFields
sets the fields used in logging for the Teleport process.
See the Teleport config file reference for
more details on possible values for extra_fields
.
affinity
Type | Default |
---|---|
object | {} |
affinity
sets the affinities for any pods created by the chart.
See the Kubernetes documentation
for more details.
dnsConfig
Type | Default |
---|---|
object | {} |
dnsConfig
contains custom Pod DNS Configuration for the agent pods.
This value is useful if you need to reduce the DNS load: set "ndots" to 0 and
only use FQDNs to refer to applications and databases.
See the Kubernetes pod DNS documentation for more information.
For example:
nameservers:
- 1.2.3.4
searches:
- ns1.svc.cluster-domain.example
- my.dns.search.suffix
options:
- name: ndots
value: "2"
dnsPolicy
Type | Default |
---|---|
string | "" |
dnsPolicy
sets the Pod's DNS Policy
See the Kubernetes pod DNS documentation for more information.
nodeSelector
Type | Default |
---|---|
object | {} |
nodeSelector
sets the node selector for any pods created by the chart.
See the Kubernetes documentation
for more details.
extraLabels
extraLabels
contains additional Kubernetes labels to apply on the resources
created by the chart.
See the Kubernetes label documentation
for more information.
extraLabels.clusterRole
Type | Default |
---|---|
object | {} |
extraLabels.clusterRole
are labels to set on the ClusterRole.
extraLabels.clusterRoleBinding
Type | Default |
---|---|
object | {} |
extraLabels.clusterRoleBinding
are labels to set on the ClusterRoleBinding.
extraLabels.role
Type | Default |
---|---|
object | {} |
extraLabels.role
are labels to set on the Role.
extraLabels.roleBinding
Type | Default |
---|---|
object | {} |
extraLabels.roleBinding
are labels to set on the RoleBinding.
extraLabels.config
Type | Default |
---|---|
object | {} |
extraLabels.config
are labels to set on the ConfigMap.
extraLabels.deployment
Type | Default |
---|---|
object | {} |
extraLabels.deployment
are labels to set on the Deployment or StatefulSet.
extraLabels.job
Type | Default |
---|---|
object | {} |
extraLabels.job
are labels to set on the post-delete Job created by the chart.
extraLabels.pod
Type | Default |
---|---|
object | {} |
extraLabels.pod
are labels to set on the Pods created by the
Deployment, StatefulSet, or Job.
extraLabels.podDisruptionBudget
Type | Default |
---|---|
object | {} |
extraLabels.podDisruptionBudget
are labels to set on the podDisruptionBudget.
extraLabels.podSecurityPolicy
Type | Default |
---|---|
object | {} |
extraLabels.podSecurityPolicy
are labels to set on the podSecurityPolicy.
extraLabels.secret
Type | Default |
---|---|
object | {} |
extraLabels.secret
are labels to set on the Secret.
extraLabels.serviceAccount
Type | Default |
---|---|
object | {} |
extraLabels.serviceAccount
are labels to set on the ServiceAccount.
annotations
annotations
contains annotations to apply to the different Kubernetes
objects created by the chart. See the Kubernetes annotation
documentation
for more details.
annotations.config
Type | Default |
---|---|
object | {} |
annotations.config
contains the Kubernetes annotations
put on the ConfigMap
resource created by the chart.
annotations.deployment
Type | Default |
---|---|
object | {} |
annotations.deployment
contains the Kubernetes annotations
put on the Deployment
or StatefulSet
resource created by the chart.
annotations.pod
Type | Default |
---|---|
object | {} |
annotations.pod
contains the Kubernetes annotations
put on the Pod
resources created by the chart.
annotations.secret
Type | Default |
---|---|
object | {} |
annotations.secret
contains the Kubernetes annotations
put on the Secret
resource created by the chart.
This has no effect when joinTokenSecret.create
is false
.
annotations.serviceAccount
Type | Default |
---|---|
object | {} |
annotations.serviceAccount
contains the Kubernetes annotations
put on the ServiceAccount
resource created by the chart.
extraArgs
Type | Default |
---|---|
list | [] |
extraArgs
contains extra arguments to pass to teleport start
for
the main Teleport pod
extraEnv
Type | Default |
---|---|
list | [] |
extraEnv
contains extra environment variables to set in the main
Teleport pod.
For example:
extraEnv:
- name: HTTPS_PROXY
value: "http://username:password@my.proxy.host:3128"
extraContainers
Type | Default |
---|---|
list | [] |
extraContainers
contains extra containers to add in the main Teleport
pod.
For example:
extraContainers:
- name: debug-sidecar
command:
- busybox
- sh
- -c
- "echo waiting && sleep infinity"
image: busybox:latest
imagePullPolicy: IfNotPresent
securityContext:
privileged: true
runAsNonRoot: false
extraVolumes
Type | Default |
---|---|
list | [] |
extraVolumes
contains extra volumes to mount into the Teleport pods.
See the Kubernetes volume documentation
for more details.
For example:
extraVolumes:
- name: myvolume
secret:
secretName: testSecret
extraVolumeMounts
Type | Default |
---|---|
list | [] |
extraVolumeMounts
contains extra volumes mounts for the main Teleport container.
See the Kubernetes volume documentation
for more details.
For example:
extraVolumesMounts:
- name: myvolume
mountPath: /path/on/host
hostAliases
hostAliases
sets Host aliases in the Teleport Pod.
See the Kubernetes hosts file documentation
for more details.
For example:
hostAliases:
- ip: "127.0.0.1"
hostnames:
- "foo.local"
- "bar.local"
- ip: "10.1.2.3"
hostnames:
- "foo.remote"
- "bar.remote"
imagePullPolicy
Type | Default |
---|---|
string | "IfNotPresent" |
imagePullPolicy
sets the pull policy for any pods created by the chart.
See the Kubernetes documentation
for more details.
initContainers
Type | Default |
---|---|
list | [] |
initContainers
sets the Teleport Pod's init-containers.
See the Kubernetes init-container documentation
for more details.
For example:
initContainers:
- name: "teleport-init"
image: "alpine"
args: ["echo test"]
resources
Type | Default |
---|---|
object | {} |
resources
sets the resource requests/limits for any pods created by the chart.
See the Kubernetes documentation
for more details.
initSecurityContext
Type | Default |
---|---|
object | {"allowPrivilegeEscalation":false,"capabilities":{"drop":["all"]},"readOnlyRootFilesystem":true,"runAsNonRoot":true,"runAsUser":9807} |
initSecurityContext
sets the init container security context for any
pods created by the chart.
See the Kubernetes documentation
for more details.
To unset the security context, set it to null
or ~
.
securityContext
Type | Default |
---|---|
object | {"allowPrivilegeEscalation":false,"capabilities":{"drop":["all"]},"readOnlyRootFilesystem":true,"runAsNonRoot":true,"runAsUser":9807} |
securityContext
sets the container security context for any pods created by the chart.
See the Kubernetes documentation
for more details.
To unset the security context, set it to null
or ~
.
podSecurityContext
Type | Default |
---|---|
object | {"fsGroup":9807} |
podSecurityContext
sets the pod security context for any pods created by the chart.
See the Kubernetes documentation
for more details.
To unset the security context, set it to null
or ~
.
priorityClassName
Type | Default |
---|---|
string | "" |
priorityClassName
sets the priority class used by any pods created by the chart.
The user is responsible for creating the PriorityClass
resource before deploying the chart.
See the Kubernetes documentation
for more details.
tolerations
Type | Default |
---|---|
list | [] |
tolerations
sets the tolerations for any pods created by the chart.
See the Kubernetes documentation
for more details.
probeTimeoutSeconds
Type | Default |
---|---|
int | 1 |
probeTimeoutSeconds
sets the timeout for the readiness and liveness probes
https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/