# 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](https://github.com/gravitational/teleport/tree/branch/v18/examples/chart/teleport-kube-agent).

This reference details available values for the `teleport-kube-agent` chart.

---

WARNING

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`](https://goteleport.com/docs/enroll-resources/kubernetes-access/introduction.md) | `kube`                                 | Uses Teleport to handle authentication<br />with and proxy access to a Kubernetes cluster   |
| [`application_service`](https://goteleport.com/docs/enroll-resources/application-access.md)            | `app`                                  | Uses Teleport to handle authentication<br />with and proxy access to web-based applications |
| [`database_service`](https://goteleport.com/docs/enroll-resources/database-access/guides.md)           | `db`                                   | Uses Teleport to handle authentication<br />with and proxy access to databases              |
| [`discovery_service`](https://goteleport.com/docs/enroll-resources/auto-discovery.md)                  | `discovery`                            | Uses Teleport to discover new resources<br />and dynamically add them to the cluster        |
| [`jamf_service`](https://goteleport.com/docs/zero-trust-access/device-trust/jamf-integration.md)       | `jamf`                                 | Uses Teleport to integrate with Jamf Pro<br />and sync devices with Device Trust inventory  |

### 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`.                                                                               |
| `Secret`              | `jamfCredentialsSecret.name` (default: `teleport-jamf-api-credentials`) | Used for integrating Jamf Prod with Teleport (`jamf_service`).                                                                                                                                                                                                                                              | `jamfCredentialsSecret.create` 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](https://kubernetes.io/docs/reference/kubernetes-api/authorization-resources/self-subject-access-review-v1/) 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`](#kubeclustername)                                  |
| Teleport Application service | `app`             | [`apps`](#apps) or [`appResources`](#appresources)                     |
| Teleport Database service    | `db`              | [`databases`](#databases) or [`databaseResources`](#databaseresources) |
| Teleport Discovery service   | `discovery`       | [`kubeClusterName`](#kubeclustername)                                  |
| Teleport Jamf service        | `jamf`            | [`jamfApiEndpoint`](#jamfapiendpoint), [`jamfClientId`](#jamfclientid) |

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`          |

## `relayAddr`

| Type     | Default |
| -------- | ------- |
| `string` | `""`    |

`relayAddr` defines the optional address of the Teleport Relay Service tunnel endpoint that this agent should use.

If set, the agent will open reverse tunnels to the specified Relay in addition to the tunnels to the control plane, for the protocols supported by the Relay.

relayAddr is available starting from Teleport v18.5.0, taking effect for the Kubernetes service.

## `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`](#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`](#joinparams), or [an existing Kubernetes Secret](#jointokensecret).

The token used must at least grant the required system roles. For example, if the chart [`roles`](#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`](#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](https://goteleport.com/docs/reference/deployment/join-methods.md) 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 tokens
- `kubernetes`: either the `in-cluster` variant (if the agent runs in the same Kubernetes cluster as the `teleport-cluster` chart) or the `JWKS/OIDC` variants (work 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](https://goteleport.com/docs/reference/deployment/join-methods.md#delegated-join-methods), 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`](#jointokensecret) for more details and instructions.

If method is `kubernetes`, you must set [`teleportClusterName`](#teleportclustername).

## `teleportClusterName`

| Type     | Default |
| -------- | ------- |
| `string` | `""`    |

`teleportClusterName` is the name of the joined Teleport cluster. Setting this value is required when joining via the [Kubernetes JWKS or OIDC](https://goteleport.com/docs/reference/deployment/join-methods.md#kubernetes-jwks) join method.

When this value is set, the chart mounts a kubernetes service account token via a projected volume and configures Teleport to use it for joining.

## `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](https://goteleport.com/docs/enroll-resources/application-access/reference.md#configuration) for more details.

Proxied applications can be defined statically (through this value) or dynamically (through the [`appResources`](#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

```

---

SUPPORTED VALUES

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](https://goteleport.com/docs/enroll-resources/application-access/reference.md#configuration).

---

## `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](https://goteleport.com/docs/enroll-resources/application-access.md) for more details.

Proxied applications can be defined statically (through [`apps`](#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"

```

---

EXAMPLE

Once `appResources` is set, you can dynamically register application with `tsh` by following [the Dynamic App Registration guide](https://goteleport.com/docs/enroll-resources/application-access/configuration/dynamic-registration.md).

---

## `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.

---

IAM ROLES

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](https://goteleport.com/docs/enroll-resources/database-access/enrollment/aws/rds/mysql-postgres-mariadb.md#step-36-create-iam-policies-for-teleport). 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.

---

AZURE IAM

For Azure database auto-discovery to work, your Database Service pods will need to have appropriate IAM permissions as per the [database documentation](https://goteleport.com/docs/enroll-resources/database-access/enrollment/azure/azure-postgres-mysql.md#step-25-configure-iam-permissions-for-teleport).

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`](#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](https://goteleport.com/docs/enroll-resources/database-access.md) for more details.

Proxied applications can be defined statically (through this value) or dynamically (through the [`databaseResources`](#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

```

---

SUPPORTED VALUES

You can see a list of all the supported [values which can be used in a Teleport Database Service configuration here](https://goteleport.com/docs/enroll-resources/database-access/reference/configuration.md).

---

---

TRUSTING DATABASE CA

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](https://goteleport.com/docs/enroll-resources/database-access.md) for more details.

Proxied databases can be defined statically (through [`databases`](#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"

```

---

EXAMPLE

Once `databaseResources` is set, you can dynamically register database with `tsh` by following [this guide](https://goteleport.com/docs/enroll-resources/database-access/guides/dynamic-registration.md).

---

## `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](https://goteleport.com/docs/reference/architecture/kubernetes-applications-architecture.md) for more details.

---

NOTE

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

```

## `jamfApiEndpoint`

| Type     | Default |
| -------- | ------- |
| `string` | `""`    |

`jamfApiEndpoint` sets the Jamf Pro API endpoint used for Jamf service. Example: "<https://yourtenant.jamfcloud.com/api>".

This setting is required if the chart `roles` contains `jamf`.

## `jamfClientId`

| Type     | Default |
| -------- | ------- |
| `string` | `""`    |

`jamfClientId` sets the Jamf Pro API Client ID used for Jamf service.

This setting is required if the chart `roles` contains `jamf`.

## `jamfClientSecret`

| Type     | Default |
| -------- | ------- |
| `string` | `""`    |

`jamfClientSecret` sets the Jamf Pro API client secret used for Jamf service.

This setting is required if the chart `roles` contains `jamf` and `jamfCredentialsSecret.create` is set to `true`. If you provide your own Kubernetes Secret, this setting can remain unset.

## `jamfCredentialsSecret`

`jamfCredentialsSecret` manages the Kubernetes Secret containing the Jamf API credentials (either Jamf client secret or password).

### `jamfCredentialsSecret.create`

| Type   | Default |
| ------ | ------- |
| `bool` | `true`  |

`jamfCredentialsSecret.create` controls whether the chart creates the Kubernetes `Secret` containing the Jamf Pro API Client Secret. If false, you must create a Kubernetes Secret with the configured name in the Helm release namespace.

### `jamfCredentialsSecret.name`

| Type     | Default                           |
| -------- | --------------------------------- |
| `string` | `"teleport-jamf-api-credentials"` |

`jamfCredentialsSecret.name` is the name of the Kubernetes Secret containing the Jamf Pro API Client Secret used by the chart.

If `jamfCredentialsSecret.create` is `false`, the chart will not attempt to create the secret itself. Instead, it will read the value from an existing Kubernetes Secret. `jamfCredentialsSecret.name` configures the name of this secret. This allows you to configure this secret externally and avoid having a plaintext Jamf Pro API Client Secret stored in your Teleport chart values.

To create your own Kubernetes Secret containing Jamf Pro API Client Secret, run the command:

```
$ kubectl --namespace teleport create secret generic my-jamf-secret --from-literal=credential=<replace-with-actual-secret>
```

---

NOTE

The key used for the Jamf Pro API Client Secret inside the secret must be `credential`, as in the command above.

---

For example:

```
jamfCredentialsSecret:
  create: false
  name: my-jamf-secret

```

## `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.

---

WARNING

`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`](#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.

---

WARNING

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](https://goteleport.com/docs/reference/helm-reference/teleport-cluster.md#acme) or enable [cert-manager support](https://goteleport.com/docs/reference/helm-reference/teleport-cluster.md#highavailabilitycertmanager).

---

## `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](https://goteleport.com/docs/reference/deployment/config.md) for the list of supported fields.

```
teleportConfig:
  app_service:
    debug_app: true
  discovery_service:
    enabled: true
    azure:
    - types: ["aks"]
      tags:
        "*":"*"

```

## `terminationGracePeriodSeconds`

| Type      | Default |
| --------- | ------- |
| `integer` | `30`    |

`terminationGracePeriodSeconds` is the time the pod has to do a graceful shutdown. If teleport has not existed after this delay, the process gets killed. Teleport will wait until every connection backed by the agent is over before exiting. If you want to reduce the disruption of rolling out agents at the price of a slower rollout, you can increase this value to an hour.

See the [Kubernetes Pod Lifecycle docs](https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/#pod-termination) for more details.

## `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.

---

NOTE

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](#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
```

---

DANGER

The Teleport distroless container trusts by default CAs from the `ca-certificates` package (Mozilla PKI). When `existingCASecretName` is set, Teleport only trusts the CA bundle from the secret. If you need Teleport to interact with other systems (e.g. AWS, GitHub, ...), the secret must contain their CA. Else, Teleport will fail to establish TLS connections with external services.

---

### `tls.existingCASecretKeyName`

| Type     | Default    |
| -------- | ---------- |
| `string` | `"ca.pem"` |

`tls.existingCASecretKeyName` determines which key in the CA secret will be used as a trusted CA bundle file.

## `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 updater can fetch the update information using two protocols:

- the webapi update protocol (in this case the Teleport Proxy Service is the one driving the version rollout)
- the version server protocol (this is an HTTP server serving static files specifying the version and if the update is critical).

The webapi protocol takes precedence over the version server one if the Teleport Proxy Service supports it. The version server protocol failover can be disabled by unsetting `updater.versionServer`. The webapi protocol can be disabled by setting `updater.proxyAddr` to `""`. For backward compatibility reasons, the webapi protocol is not enabled if a custom `updater.versionServer` is set.

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` 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 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`](#updaterversionserver) and [`releaseChannel` ](#updaterreleasechannel). This field supports gotemplate.

Setting this field makes the updater fetch the version using the version server protocol. Setting this field to a custom value disables the webapi update protocol to ensure backward compatibility.

### `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`](#updaterversionserver) and [`releaseChannel`](#updaterreleasechannel). You must not change the default value if you are a Teleport Cloud user unless instructed by Teleport support.

This value is used when the updater is fetching the version using the version server protocol. It is also used as a failover when fetching the version using the webapi protocol if `updater.group` is unset.

### `updater.group`

| Type     | Default |
| -------- | ------- |
| `string` | `""`    |

`updater.group` is the update group used when fetching the version using the webapi protocol. When unset, the group defaults to `default`.

### `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](https://kubernetes.io/docs/concepts/storage/volumes/) 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](https://kubernetes.io/docs/concepts/storage/volumes/) 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`](https://github.com/gravitational/teleport/blob/branch/18/examples/chart/teleport-cluster/templates/psp.yaml).

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](https://goteleport.com/docs/zero-trust-access/deploy-a-cluster/helm-deployments/migration-kubernetes-1-25-psp.md).

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`](#roles) contains `kube`.

---

NOTE

These are Teleport-specific RBAC labels, not Kubernetes labels.

---

---

NOTE

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`](#apps) section. To set labels for databases, add a `static_labels` element to the [`databases`](#databases) section.

For more information on how to set static/dynamic labels for Teleport services, see [labelling nodes and applications](https://goteleport.com/docs/zero-trust-access/rbac-get-started/labels.md).

---

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.

---

SIZING GUIDELINES

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`](#authtoken), [`joinParams`](#joinparams), or [`joinTokenSecret`](#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.

---

WARNING

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.

---

NOTE

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/getting-started/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 Community Edition Agent pods created by the chart.

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

---

INTERACTION WITH TELEPORT KUBE AGENT UPDATER

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.

---

By default, the image contains only the Teleport application and its runtime dependencies, and does not contain a shell. This setting only takes effect when [`enterprise`](#enterprise) is `false`. When running an enterprise version, you must use [`enterpriseImage`](#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.

---

INTERACTION WITH TELEPORT KUBE AGENT UPDATER

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.

---

By default, the image contains only the Teleport application and its runtime dependencies, and does not contain a shell. This setting only takes effect when [`enterprise`](#enterprise) is `true`. When running an OSS version, you must use [`image`](#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](https://kubernetes.io/docs/concepts/containers/images/#specifying-imagepullsecrets-on-a-pod) 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`.

---

NOTE

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

---

NOTE

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`](#serviceaccountname-1) 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 both `ClusterRole` and `ClusterRoleBinding` resources for the agent, and `Role`/`RoleBinding` for the updater if enabled.
- When `false`, the chart does not create the `Role` and `RoleBinding` 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`](#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>
```

---

NOTE

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](https://goteleport.com/docs/reference/deployment/config.md) for more details on possible values for `extra_fields`.

## `skipHooks`

| Type   | Default |
| ------ | ------- |
| `bool` | `false` |

`skipHooks` configures the chart to not render any hooks. This can be used in CI flows where the chart is rendered and applied separately.

---

DANGER

After disabling the hooks, uninstalling the `teleport-kube-agent` chart will no longer remove the agents state (stored in secrets named after the chart pods). If you set this boolean to true, you are responsible for deleting the secrets after uninstalling the chart.

Failure to do so might leave valid Teleport credentials in your cluster, or cause issues when a new agent with the same name is deployed in the cluster.

---

## `affinity`

| Type     | Default |
| -------- | ------- |
| `object` | `{}`    |

`affinity` sets the affinities for any pods created by the chart. See [the Kubernetes documentation](https://kubernetes.io/docs/concepts/configuration/assign-pod-node/#affinity-and-anti-affinity) for more details.

## `disableTopologySpreadConstraints`

| Type   | Default |
| ------ | ------- |
| `bool` | `false` |

`disableTopologySpreadConstraints` turns off the topology spread constraints. The feature is automatically turned off on Kubernetes versions below 1.18.

## `topologySpreadConstraints`

| Type   | Default |
| ------ | ------- |
| `list` | `[]`    |

`topologySpreadConstraints` sets the topology spread constraints for any pods created by the chart. See [the Kubernetes documentation](https://kubernetes.io/docs/concepts/scheduling-eviction/topology-spread-constraints/) for more details.

When unset, the chart defaults to a soft topology spread constraint that tries to spread pods across hosts and zones.

```
topologySpreadConstraints:
  - maxSkew: 1
    topologyKey: kubernetes.io/hostname
    whenUnsatisfiable: ScheduleAnyway
    labelSelector:
      matchLabels: # dynamically computed
  - maxSkew: 1
    topologyKey: topology.kubernetes.io/zone
    whenUnsatisfiable: ScheduleAnyway
    labelSelector:
      matchLabels: # dynamically computed

```

## `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 ](https://kubernetes.io/docs/concepts/services-networking/dns-pod-service/#pod-dns-config)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 ](https://kubernetes.io/docs/concepts/services-networking/dns-pod-service/#pod-s-dns-policy)for more information.

## `nodeSelector`

| Type     | Default |
| -------- | ------- |
| `object` | `{}`    |

`nodeSelector` sets the node selector for any pods created by the chart. See [the Kubernetes documentation](https://kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/#nodeselector) for more details.

## `extraLabels`

`extraLabels` contains additional Kubernetes labels to apply on the resources created by the chart. See [the Kubernetes label documentation ](https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/)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](https://kubernetes.io/docs/concepts/overview/working-with-objects/annotations/) 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](https://kubernetes.io/docs/concepts/storage/volumes/) 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](https://kubernetes.io/docs/concepts/storage/volumes/) 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](https://kubernetes.io/docs/tasks/network/customize-hosts-file-for-pods/) 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](https://kubernetes.io/docs/concepts/containers/images/#updating-images) for more details.

## `initContainers`

| Type   | Default |
| ------ | ------- |
| `list` | `[]`    |

`initContainers` sets the Teleport Pod's init-containers. See [the Kubernetes init-container documentation](https://kubernetes.io/docs/concepts/workloads/pods/init-containers/) 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](https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/) for more details.

## `goMemLimitRatio`

| Type    | Default |
| ------- | ------- |
| `float` | `0.9`   |

`goMemLimitRatio` configures the GOMEMLIMIT env var set by the chart. GOMEMLIMIT instructs the go garbage collector to try to keep allocated memory below a given threshold. This is a best-effort attempt, but this helps to prevent OOMs in case of bursts.

When the memory limits are set and goMemLimitRatio is non-zero, the chart sets the GOMEMLIMIT to `resources.memory.limits * goMemLimitRatio`. The value must be between 0 and 1. Set to 0 to unset GOMEMLIMIT. This has no effect if GOMEMLIMIT is already set through `extraEnv`.

## `initSecurityContext`

| Type     | Default                                                                                                                                                                            |
| -------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `object` | `{"allowPrivilegeEscalation":false,"capabilities":{"drop":["ALL"]},"readOnlyRootFilesystem":true,"runAsNonRoot":true,"runAsUser":9807,"seccompProfile":{"type":"RuntimeDefault"}}` |

`initSecurityContext` sets the init container security context for any pods created by the chart. See [the Kubernetes documentation](https://kubernetes.io/docs/tasks/configure-pod-container/security-context/#set-the-security-context-for-a-container) for more details.

The default value is compatible with [the restricted PSS](https://kubernetes.io/docs/concepts/security/pod-security-standards/).

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,"seccompProfile":{"type":"RuntimeDefault"}}` |

`securityContext` sets the container security context for any pods created by the chart. See [the Kubernetes documentation](https://kubernetes.io/docs/tasks/configure-pod-container/security-context/#set-the-security-context-for-a-container) for more details.

The default value is compatible with [the restricted PSS](https://kubernetes.io/docs/concepts/security/pod-security-standards/).

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](https://kubernetes.io/docs/tasks/configure-pod-container/security-context/#set-the-security-context-for-a-pod) 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](https://kubernetes.io/docs/concepts/scheduling-eviction/pod-priority-preemption/) for more details.

## `tolerations`

| Type   | Default |
| ------ | ------- |
| `list` | `[]`    |

`tolerations` sets the tolerations for any pods created by the chart. See [the Kubernetes documentation](https://kubernetes.io/docs/concepts/configuration/taint-and-toleration/) 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/>