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.

What the chart deploys

Teleport services

The teleport-kube-agent chart can run any or all of three Teleport services:

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:

roles

This parameter is not mandatory to preserve backwards compatibility with older chart versions, but we recommend it is set.

roles is a comma-separated list of services which should be enabled when running the teleport-kube-agent chart.

values.yaml example:

roles: kube,app,db

enterprise

When enterprise is set to true, the container image used for Teleport agent pods run by the teleport-kube-agent chart will be the enterprise version. This should be set to true for connecting to Teleport Cloud and self-hosted Teleport Enterprise clusters to use enterprise features within the Kube Agent.

values.yaml example:

enterprise: true

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

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 and Enroll 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 if:

• 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

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.

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

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

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.

roleBindingName

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.

values.yaml example:

roleBindingName: myrolebinding

roleName

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.

values.yaml example:

roleName: myrole

serviceAccountName

This field is deprecated and will be removed in a future version. Use serviceAccount.name instead.

authToken

authToken provides a Teleport join token which will be used to join the Teleport instance to a Teleport cluster.

The value joinParams supports more methods to join the Teleport cluster and takes precedence if both authToken and joinParams are set.

A token must be specified for the agent to join the Teleport cluster, either though authToken, joinParams, or an existing Kubernetes Secret.

If you do not have the correct services (Teleport refers to these internally as Roles) assigned to your join token, the Teleport instance will fail to join the Teleport cluster.

values.yaml example:

authToken: <replace-with-actual-token>

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.

joinParams.method

joinParams.method defines which join method will be used to join the Teleport cluster. Possible values are token, iam and ec2.

• For iam, see Joining Nodes Via AWS IAM Role.
• For ec2, see Joining Nodes Via AWS EC2 Identity Document.
• For token (default value), the token must be provided through joinParams.tokenName or through an existing Kubernetes Secret.

values.yaml example:

joinParams:
  method: "token"|"ec2"|"iam"

joinParams.tokenName

When joinParams.method is iam or ec2, joinParams.tokenName contains the name of the token that will be used to join the cluster. In this case, the value is not sensitive as authorization is checked through AWS IAM or EC2.

When joinParams.method is token (by default), joinParams.tokenName contains the join 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.

values.yaml example:

joinParams:
  tokenName: "my-token"

proxyAddr

proxyAddr provides the public-facing Teleport proxy endpoint which should be used to join the cluster. This is the same URL that is used to access the web UI of your Teleport cluster. It is the same as the value configured for proxy_service.public_addr in a traditional Teleport cluster. The port used is usually either 3080 or 443.

Here are a few examples:

kubeClusterName

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.

values.yaml example:

kubeClusterName: my-gke-cluster

kubernetesDiscovery

kubernetesDiscovery is a YAML list object detailing the Kubernetes App Discovery Configuration

You can specify multiple discovery configurations by adding additional list elements.

values.yaml example:

kubernetesDiscovery:
- types: ["app"]
  namespaces: [ "toronto", "porto" ]
  labels:
    env: staging
- types: ["app"]
  namespaces: [ "seattle", "oakland" ]
  labels:
    env: testing

kubernetesDiscovery.types

kubernetesDiscovery.types is a list of Teleport resource types to be created from the discovered Kubernetes Services. Currently only supports app.

kubernetesDiscovery.namespaces

kubernetesDiscovery.namespaces is a list of Kubernetes namespaces to be scanned for resources.

kubernetesDiscovery.labels

kubernetesDiscovery.labels is a map of labels to be matched against the Kubernetes Services. Only Services with matching labels will be imported to Teleport.

apps

apps is a YAML list object detailing the applications that should be proxied by Teleport Application access.

You can specify multiple apps by adding additional list elements.

values.yaml example:

apps:
- name: grafana
  uri: http://localhost:3000
  labels:
    purpose: monitoring
- name: jenkins
  uri: http://jenkins:8080
  labels:
    purpose: ci

appResources

appResources is a YAML list object detailing the resource selectors of the applications that should be proxied by the Teleport Application Service.

You can specify multiple selectors by including additional list elements.

values.yaml example:

appResources:
- labels:
    "env": "prod"
- labels:
    "env": "test"

awsDatabases

annotations:
  serviceAccount:
    eks.amazonaws.com/role-arn: arn:aws:iam::1234567890:role/my-rds-autodiscovery-role

awsDatabases is a YAML list object detailing the filters for the AWS databases that should be discovered and proxied by Teleport Database access.

You can specify multiple database filters by adding additional list elements.

• 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.

values.yaml 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

kubectl create secret generic teleport-azure-client-secret --from-literal=client_secret=<your-azure-client-secret>
secret/teleport-azure-client-secret created

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"

azureDatabases is a YAML list object detailing the filters for the Azure databases that should be discovered and proxied by Teleport Database access.

You can specify multiple database filters by adding additional list elements.

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.

values.yaml 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

databases is a YAML list object detailing the databases that should be proxied by Teleport Database access.

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

kubectl create secret generic my-postgres-ca --from-file=ca.pem=/path/to/database-ca.pem

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

databaseResources is a YAML list object detailing the resource selectors of the databases that should be proxied by the Teleport Database Service.

You can specify multiple selectors by adding elements to the list.

values.yaml example:

databaseResources:
- labels:
    "env": "prod"
    "engine": "postgres"
- labels:
    "env": "test"
    "engine": "mysql"

teleportVersionOverride

Normally the version of Teleport being used will match the version of the chart being installed. If you install chart version 10.0.0, you'll be using Teleport 10.0.0. Upgrading the Helm chart will use the latest version from the repo.

You can optionally override this to use a different published Teleport Docker image tag like 10.1.2 or 11.

values.yaml example:

teleportVersionOverride: "11"

caPin

When caPin is set, the Teleport pod will use its values to check the Auth Service's identity when first joining a cluster. This enables a more secure way of adding new Teleport instances to a cluster. See "Adding Nodes to the Cluster".

Each list element can be the pin itself (recommended, works out of the box), or a path to a file containing the pin. For the latter it is your responsibility to mount the file using extraVolumes.

values.yaml example:

caPin: ["sha256:7e12c17c20d9cb504bbcb3f0236be3f446861f1396dcbb44425fe28ec1c108f1"]

insecureSkipProxyTLSVerify

When insecureSkipProxyTLSVerify is set to true, the Teleport instance will skip the verification of the TLS certificate presented by the Teleport Proxy Service specified using proxyAddr.

This can be used for joining a Teleport instance to a Teleport cluster which does not have valid TLS certificates for testing.

values.yaml example:

insecureSkipProxyTLSVerify: false

teleportConfig

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

existingCASecretName

tls.existingCASecretName sets the SSL_CERT_FILE environment variable to load a trusted CA or bundle in PEM format into Teleport pods. This can be set to inject a root and/or intermediate CA so that Teleport can build a full trust chain on startup. The injected CA will be used to validate TLS communications, with the Proxy Service, with upstream applications or databases.

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

values.yaml example:

tls:
  existingCASecretName: my-root-ca

existingDataVolume

When existingDataVolume is set to the name of an existing volume, the /var/lib/teleport mount will use this volume instead of creating a new emptyDir volume.

values.yaml example:

existingDataVolume: my-volume

podSecurityPolicy

podSecurityPolicy.enabled

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.

To disable PSP creation, you can set enabled to false.

Kubernetes reference

values.yaml example:

podSecurityPolicy:
  enabled: false

labels

labels can be used to add a map of key-value pairs for the kubernetes_service which is deployed using the teleport-kube-agent chart. These labels can then be used with Teleport's RBAC policies to define access rules for the cluster.

values.yaml example:

labels:
  environment: production
  region: us-east

storage

storage.enabled

Enables the creation of a Kubernetes persistent volume to hold Teleport instance state.

Kubernetes reference

Chart upgrades for legacy releases

If you are upgrading a legacy teleport-kube-agent release (pre-v11), the way the teleport-kube-agent chart handles upgrades differs depending on the value of storage.enabled. Prior to v11, the chart ran the Teleport pod as a Deployment if storage.enabled was false and a StatefulSet if it was true. In v11 and after, the chart always runs the Teleport pod as a StatefulSet.

During an upgrade, if storage.enabled is false, the chart installs a StatefulSet resource to run the Teleport pod alongside the existing Deployment. Once the StatefulSet joins the cluster and becomes healthy, the chart deletes the Deployment using a Helm hook, and the upgrade finishes.

If storage.enabled is true, then during the upgrade, the teleport-kube-agent chart will use the existing StatefulSet resource to run the Teleport pod. The chart will import the pod's identify from the previously configured external storage into a Kubernetes Secret.

New chart installations

New installations of teleport-kube-agent always launch the Teleport pod as a StatefulSet, and the pod reads its state from a Kubernetes Secret. Setting storage.enabled to true is not required for the Teleport pod to maintain its state.

If storage.enabled is true, the chart creates a volume mount for the Teleport pod that persists across the lifetimes of all Teleport pods deployed on a particular node. The Teleport pod uses this volume mount to manage its data, which is useful for storing session recordings locally.

You can configure this persistent storage using storage.storageClassName and storage.requests.

If storage.enabled is false, the chart configures the Teleport pod to manage its data with a temporary directory that exists until the Teleport pod stops running.

values.yaml example:

storage:
  enabled: true

storage.storageClassName

The storage class name the persistent volume should use when creating persistent volume claims. The provided storage class name needs to exist on the Kubernetes cluster for Teleport to use.

Kubernetes reference

values.yaml example:

storage:
  storageClassName: teleport-storage-class

storage.requests

The size of persistent volume to create.

values.yaml example:

storage:
  requests: 128Mi

image

image sets the container image used for Teleport agent pods run by the teleport-kube-agent chart.

You can override this to use your own Teleport image rather than a Teleport-published image.

values.yaml example:

image: my.docker.registry/teleport-image-name

imagePullSecrets

Kubernetes reference

A list of secrets containing authorization tokens which can be optionally used to access a private Docker registry.

values.yaml example:

imagePullSecrets:
- name: my-docker-registry-key

highAvailability

highAvailability.replicaCount

highAvailability.replicaCount can be used to set the number of replicas used in the deployment.

Set to a number higher than 1 for a high availability mode where multiple Teleport pods will be deployed.

values.yaml example:

highAvailability:
  replicaCount: 3

highAvailability.requireAntiAffinity

Kubernetes reference

Setting highAvailability.requireAntiAffinity to true will use requiredDuringSchedulingIgnoredDuringExecution to require that multiple Teleport pods must not be scheduled on the same physical host.

Setting highAvailability.requireAntiAffinity to false (the default) uses preferredDuringSchedulingIgnoredDuringExecution to make node anti-affinity a soft requirement.

values.yaml example:

highAvailability:
  requireAntiAffinity: true

highAvailability.podDisruptionBudget

highAvailability.podDisruptionBudget.enabled

Kubernetes reference

Enable a Pod Disruption Budget for the Teleport Pod to ensure HA during voluntary disruptions.

values.yaml example:

highAvailability:
  podDisruptionBudget:
    enabled: true

highAvailability.podDisruptionBudget.minAvailable

Kubernetes reference

Ensures that this number of replicas is available during voluntary disruptions, can be a number of replicas or a percentage.

values.yaml example:

highAvailability:
  podDisruptionBudget:
    minAvailable: 1

podMonitor

podMonitor controls the PodMonitor CR (from monitoring.coreos.com/v1) that monitors the workload (Auth and Proxy Services) deployed by the chart. This custom resource configures Prometheus and makes it scrape Teleport metrics.

The CRD is deployed by the prometheus-operator and allows workload to get monitored. You need to deploy the prometheus-operator in the cluster prior to configuring the podMonitor section of the chart. See the prometheus-operator documentation for setup instructions.

podMonitor.enabled

Whether the chart should deploy a PodMonitor resource. This is disabled by default as it requires the PodMonitor CRD to be installed in the cluster.

podMonitor.additionalLabels

Additional labels to put on the created PodMonitor Resource. Those labels are used to be selected by a specific Prometheus instance.

podMonitor.interval

interval is the interval between two metrics scrapes by Prometheus.

clusterRoleName

clusterRoleName can be optionally used to override the name of the Kubernetes ClusterRole used by the teleport-kube-agent chart's ServiceAccount.

values.yaml example:

clusterRoleName: kubernetes-clusterrole

clusterRoleBindingName

clusterRoleBindingName can be optionally used to override the name of the Kubernetes ClusterRoleBinding used by the teleport-kube-agent chart's ServiceAccount.

values.yaml example:

clusterRoleBindingName: kubernetes-clusterrolebinding

priorityClassName

priorityClassName allows to specify a priority class for the teleport-kube-agent deployment/statefulset.

values.yaml example:

priorityClassName: "teleport-kube-agent"

serviceAccount.create

Kubernetes reference

Boolean value to control whether Helm Chart should create the ServiceAccount. When off, the serviceAccount.name parameter should be set to the existing ServiceAccount name.

values.yaml example:

serviceAccount:
  create: false
  name: kubernetes-serviceaccount

serviceAccount.name

serviceAccount.name provides a custom name for the ServiceAccount resource that the teleport-kube-agent chart creates for the Teleport pod. By default, the ServiceAccount has the name of the Helm release.

You should set this value if there is a ServiceAccount resource in the namespace of your teleport-kube-agent resources with the same name as your teleport-kube-agent release.

values.yaml example:

serviceAccount:
  name: kubernetes-serviceaccount

joinTokenSecret

joinTokenSecret.create

Boolean value to control whether Helm Chart should create the Secret. When off, the joinTokenSecret.name parameter should be set to the existing Secret name.

joinTokenSecret.name

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 teleport-kube-agent-join-token --from-literal=auth-token=<replace-with-actual-token>

values.yaml example:

joinTokenSecret:
  create: false
  name: "secret-i-created-before"

joinParams:
  method: "token"
  tokenName: ""

log

log.level

log.level sets the log level used for the Teleport process.

Available log levels (in order of most to least verbose) 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.

values.yaml example:

log:
  level: DEBUG

log.output

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.

values.yaml example:

log:
  output: stderr

log.format

log.format sets the output type for the Teleport process.

Possible values are text (default) or json.

values.yaml example:

log:
  format: json

log.extraFields

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.

values.yaml example:

log:
  extraFields: ["timestamp", "level"]

affinity

Kubernetes reference

Kubernetes affinity to set for pod assignments.

values.yaml example:

affinity:
  nodeAffinity:
    requiredDuringSchedulingIgnoredDuringExecution:
      nodeSelectorTerms:
      - matchExpressions:
        - key: gravitational.io/dedicated
          operator: In
          values:
          - teleport

dnsConfig

Kubernetes reference

Kubernetes pod DNS configuration. This value can reduce the DNS load by setting ndots to 0.

dnsConfig:
  nameservers:
    - 1.2.3.4
  searches:
    - ns1.svc.cluster-domain.example
    - my.dns.search.suffix
  options:
    - name: ndots
      value: "2"

dnsPolicy

Kubernetes reference

Kubernetes pod DNS policy.

dnsPolicy: "Default"

nodeSelector

nodeSelector can be used to add a map of key-value pairs to constrain the nodes that Teleport pods will run on.

Kubernetes reference

values.yaml example:

nodeSelector:
  role: node
  region: us-east

extraLabels.clusterRole

Kubernetes reference

Kubernetes labels that should be applied to the ClusterRole created by the chart.

values.yaml example:

extraLabels:
  clusterRole:
    app.kubernetes.io/name: teleport-kube-agent

extraLabels.clusterRoleBinding

Kubernetes reference

Kubernetes labels that should be applied to the ClusterRoleBinding created by the chart.

values.yaml example:

extraLabels:
  clusterRoleBinding:
    app.kubernetes.io/name: teleport-kube-agent

extraLabels.role

Kubernetes reference

Kubernetes labels that should be applied to the Role created by the chart for the Teleport pod.

values.yaml example:

extraLabels:
  role:
    app.kubernetes.io/name: teleport-kube-agent

extraLabels.roleBinding

Kubernetes reference

Kubernetes labels that should be applied to the RoleBinding created by the chart for the Teleport pod.

values.yaml example:

extraLabels:
  roleBinding:
    app.kubernetes.io/name: teleport-kube-agent

extraLabels.config

Kubernetes reference

Kubernetes labels that should be applied to the ConfigMap created by the chart.

values.yaml example:

extraLabels:
  config:
    app.kubernetes.io/name: teleport-kube-agent

extraLabels.deployment

Kubernetes reference

Kubernetes labels that should be applied to the Deployment or StatefulSet created by the chart.

values.yaml example:

extraLabels:
  deployment:
    app.kubernetes.io/name: teleport-kube-agent

extraLabels.pod

Kubernetes reference

Kubernetes labels that should be applied to every Pod in the Deployment or StatefulSet created by the chart.

values.yaml example:

extraLabels:
  pod:
    app.kubernetes.io/name: teleport-kube-agent

extraLabels.podDisruptionBudget

Kubernetes reference

Kubernetes labels that should be applied to the PodDisruptionBudget created by the chart (if enabled).

values.yaml example:

extraLabels:
  podDisruptionBudget:
    app.kubernetes.io/name: teleport-kube-agent

extraLabels.podSecurityPolicy

Kubernetes reference

Kubernetes labels that should be applied to the PodSecurityPolicy created by the chart (if enabled).

values.yaml example:

extraLabels:
  podSecurityPolicy:
    app.kubernetes.io/name: teleport-kube-agent

extraLabels.secret

Kubernetes reference

Kubernetes labels that should be applied to the Secret created by the chart (if enabled).

values.yaml example:

extraLabels:
  secret:
    app.kubernetes.io/name: teleport-kube-agent

extraLabels.serviceAccount

Kubernetes reference

Kubernetes labels that should be applied to the ServiceAccount created by the chart for the Teleport pod.

values.yaml example:

extraLabels:
  serviceAccount:
    app.kubernetes.io/name: teleport-kube-agent

annotations.config

Kubernetes reference

Kubernetes annotations which should be applied to the ConfigMap created by the chart.

values.yaml example:

annotations:
  config:
    kubernetes.io/annotation: value

annotations.deployment

Kubernetes reference

Kubernetes annotations which should be applied to the Deployment created by the chart.

values.yaml example:

annotations:
  deployment:
    kubernetes.io/annotation: value

annotations.pod

Kubernetes reference

Kubernetes annotations which should be applied to each Pod created by the chart.

values.yaml example:

annotations:
  pod:
    kubernetes.io/annotation: value

annotations.secret

Kubernetes reference

Kubernetes annotations which should be applied to the Secret created by the chart.

values.yaml example:

annotations:
  secret:
    kubernetes.io/annotation: value

annotations.serviceAccount

Kubernetes reference

Kubernetes annotations which should be applied to the ServiceAccount created by the chart.

values.yaml example:

annotations:
  serviceAccount:
    kubernetes.io/annotation: value

extraVolumes

Kubernetes reference

A list of extra Kubernetes Volumes which should be available to any Pod created by the chart. These volumes will also be available to any initContainers configured by the chart.

values.yaml example:

extraVolumes:
- name: myvolume
  secret:
    secretName: mysecret

extraArgs

A list of extra arguments to pass to the teleport start command when running a Teleport Pod.

values.yaml example:

extraArgs:
- "--debug"

extraEnv

Kubernetes reference

A list of extra environment variables to be set on the main Teleport container.

values.yaml example:

extraEnv:
- name: HTTPS_PROXY
  value: "http://username:[email protected]:3128"

extraVolumeMounts

Kubernetes reference

A list of extra Kubernetes volume mounts which should be mounted into any Pod created by the chart. These volume mounts will also be mounted into any initContainers configured by the chart.

values.yaml example:

extraVolumeMounts:
- name: myvolume
  mountPath: /path/to/mount/volume

hostAliases

Configure aliases in the pod's /etc/hosts. This can be used to have the agent join the Teleport cluster through a different non-public route, or to allow the agent to access applications or databases that are not resolvable. See the Kubernetes documentation for more details.

hostAliases:
  - ip: "127.0.0.1"
    hostnames:
      - "foo.local"
      - "bar.local"
  - ip: "10.1.2.3"
    hostnames:
      - "foo.remote"
      - "bar.remote"

imagePullPolicy

Kubernetes reference

Allows the imagePullPolicy for any pods created by the chart to be overridden.

values.yaml example:

imagePullPolicy: Always

initContainers

Kubernetes reference

A list of initContainers which will be run before the main Teleport container in any pod created by the chart.

values.yaml example:

initContainers:
- name: teleport-init
  image: alpine
  args: ['echo test']

resources

Kubernetes reference

Resource requests/limits which should be configured for each container inside the pod. These resource limits will also be applied to initContainers.

values.yaml example:

resources:
  requests:
    cpu: 1
    memory: 2Gi

initSecurityContext

Container security context to set for the initContainer. Defaults to:

initSecurityContext:
  allowPrivilegeEscalation: false
  capabilities:
    drop:
      - all
  readOnlyRootFilesystem: true
  runAsNonRoot: true
  runAsUser: 9807

To unset the security context, set it to null or ~.

securityContext

Container security context to set for the main Teleport container. Defaults to:

securityContext:
  allowPrivilegeEscalation: false
  capabilities:
    drop:
      - all
  readOnlyRootFilesystem: true
  runAsNonRoot: true
  runAsUser: 9807

To unset the security context, set it to null or ~.

tolerations

Kubernetes reference

Kubernetes Tolerations to set for pod assignment.

values.yaml example:

tolerations:
- key: "dedicated"
  operator: "Equal"
  value: "teleport"
  effect: "NoSchedule"

probeTimeoutSeconds

Kubernetes reference

Kubernetes timeouts for the liveness and readiness probes.

values.yaml example:

probeTimeoutSeconds: 5