Teleport Kube agent fails to start when "jamf_service.enabled" is set to "false" in v16

[minhthong582000]

Summary

I am currently using the Teleport Kube Agent to register my Kubernetes cluster with Teleport. This setup works fine with Teleport version v15. However, upon upgrading to version v16, the agents fail to start, producing the following error:

ERROR: jamf_service either username+password or clientID+clientSecret must be provided

Expected behavior:

The configuration validation should not occur if jamf_service is set to false.

Current behavior:

In version v16, the agents perform configuration validation for the jamf_service, even if it is disabled with jamf_service.enabled: false

Recreation steps

Teleport Cluster Helm

I am using the teleport-cluster Helm chart, version 16.0.0 from https://charts.releases.teleport.dev:

# Warning: The clusterName cannot be changed during a Teleport cluster's lifespan.
# If you need to change it, you must redeploy a completely new cluster.
clusterName: "teleport.mydomain.cloud"
kubeClusterName: "metal"

# The `teleport-cluster` charts deploys two sets of pods: auth and proxy.
# `auth` contains values specific for the auth pods. You can use it to
#  set specific values for auth pods, taking precedence over chart-scoped values.
# For example, to override the [`postStart`](#postStart) value only for auth pods:
#
# auth:
#  postStart: ["curl", "http://hook"]
#  imagePullPolicy: Always
auth:
  # auth.teleportConfig contains YAML teleport configuration for auth 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:
  # https://goteleport.com/docs/reference/config/
  #
  # teleportConfig:
  #   teleport:
  #     cache:
  #       enabled: false
  #   auth_service:
  #     client_idle_timeout: 2h
  #     client_idle_timeout_message: "Connection closed after 2hours without activity"
  teleportConfig:
    auth_service:
      # Static tokens.
      # See: https://goteleport.com/docs/agents/join-services-to-your-cluster/join-token/#supported-token-types
      # See also: https://goteleport.com/docs/agents/join-services-to-your-cluster/join-token/#an-insecure-alternative-static-tokens
      tokens:
        - "kube:/secrets/kube-agent-token/auth-token"

# proxy contains values specific for the proxy pods
# You can override chart-scoped values, for example
# proxy:
#   postStart: ["curl", "http://hook"]
#   imagePullPolicy: Always
proxy:
  # proxy.teleportConfig contains YAML teleport configuration for proxy 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:
  # https://goteleport.com/docs/reference/config/
  #
  # teleportConfig:
  #   teleport:
  #     cache:
  #       enabled: false
  #   proxy_service:
  #     https_keypairs:
  #       - key_file: /my-custom-mount/key.pem
  #         cert_file: /my-custom-mount/cert.pem
  teleportConfig: {}

authentication:
  # Default authentication type. Possible values are 'local' and 'github' for OSS, plus 'oidc' and 'saml' for Enterprise.
  type: github

  # Sets the authenticator connector for SSO or the default connector for "local" authentication.
  # See SSO for Enterprise (https://goteleport.com/docs/enterprise/sso/).
  # See Passwordless for local
  # (http://goteleport.com/docs/access-controls/guides/passwordless/#optional-enable-passwordless-by-default).
  # Defaults to "local".
  connectorName: ""

  # Enable/disable local authentication by setting `authentication.local_auth` in `teleport.yaml`.
  # Disabling local auth is required for FedRAMP / FIPS; see https://gravitational.com/teleport/docs/enterprise/ssh-kubernetes-fedramp/.
  localAuth: true

  # Controls the locking mode: in case of network split should Teleport guarantee availability or integrity ?
  # Possible values are "best_effort" and "strict". When not defined, Teleport defaults to "best_effort".
  # See https://goteleport.com/docs/access-controls/guides/locking/#next-steps-locking-modes.
  lockingMode: ""

  # Second factor requirements for users of the Teleport cluster.
  # Controls the `auth_config.authentication.second_factor` field in `teleport.yaml`.
  # Possible values are 'off', 'on', 'otp', 'optional' and 'webauthn'.
  #
  # WARNING:
  #   If you set `publicAddr` for users to access the cluster under a domain different
  #   to clusterName you must manually set the webauthn Relying
  #   Party Identifier (RP ID) - https://www.w3.org/TR/webauthn-2/#relying-party-identifier
  #   If you don't, RP ID will default to `clusterName` and users will fail
  #   to register second factors.
  #
  #   You can do this by setting the value
  #   `auth.teleportConfig.auth_service.authentication.webauthn.rp_id`.
  #
  #   RP ID must be both a valid domain, and part of the full domain users are connecting to.
  #   For example, if users are accessing the cluster with the domain
  #   "teleport.example.com", RP ID can be "teleport.example.com" or "example.com".
  #
  #   Changing the RP ID will invalidate all already registered webauthn second factors.
  secondFactor: "on"

  # (Optional) When using webauthn this allows to restrict which vendor and key models can be used.
  # webauthn:
  #   attestationAllowedCas:
  #     - /path/to/allowed_ca.pem
  #     - |
  #       -----BEGIN CERTIFICATE-----
  #       ...
  #       -----END CERTIFICATE-----
  #   attestationDeniedCas:
  #     - /path/to/denied_ca.pem
  #     - |
  #       -----BEGIN CERTIFICATE-----
  #       ...
  #       -----END CERTIFICATE-----

# Deprecated way to set the authentication type, `authentication.type` should be preferred.
# authenticationType: local

# Deprecated way to set the authentication second factor, `authentication.secondFactor` should be preferred.
# authenticationSecondFactor:
#   secondFactor: "otp"

# Teleport supports TLS routing. In this mode, all client connections are wrapped in TLS and multiplexed on one Teleport proxy port.
# Default mode will not utilize TLS routing and operate in backwards-compatibility mode.
#
# To use an ingress, set proxyListenerMode=multiplex, ingress.enabled=true and service.type=ClusterIP
#
# Possible values are 'separate' and 'multiplex'
proxyListenerMode: "multiplex"

# Optional setting for configuring session recording.
# See `session_recording` under https://goteleport.com/docs/setup/reference/config/#teleportyaml
sessionRecording: ""

# By default, Teleport will multiplex Postgres and MongoDB database connections on the same port as the proxy's web listener (443)
# Setting either of these values to true will separate the listeners out onto a separate port (5432 for Postgres, 27017 for MongoDB)
# This is useful when terminating TLS at a load balancer in front of Teleport (such as when using AWS ACM)
# These settings will not apply if proxyListenerMode is set to "multiplex".
separatePostgresListener: false
separateMongoListener: false

# Do not set any of these values unless you explicitly need to. Teleport always uses the cluster name by default.
#
# WARNING:
#   If you set `publicAddr` for users to access the cluster under a domain different
#   to clusterName, you must manually set the webauthn Relying
#   Party Identifier (RP ID) - https://www.w3.org/TR/webauthn-2/#relying-party-identifier
#   If you don't, RP ID will default to `clusterName` and users will fail
#   to register second factors.
#
#   You can do this by setting the value
#   `auth.teleportConfig.auth_service.authentication.webauthn.rp_id`.
#
#   RP ID must be both a valid domain, and part of the full domain users are connecting to.
#   For example, if users are accessing the cluster with the domain
#   "teleport.example.com", RP ID can be "teleport.example.com" or "example.com".
#
#   Changing the RP ID will invalidate all already registered webauthn second factors.
#
# Public cluster addresses, including port (e.g. teleport.example.com:443)
# Defaults to `clusterName` on port 443.
publicAddr:
  - "teleport.mydomain.cloud:443"
# Public cluster kube addresses, including port. Defaults to `publicAddr` on port 3026.
# Only used when `proxyListenerMode` is not 'multiplex'.
kubePublicAddr: []
# Public cluster mongo listener addresses, including port. Defaults to `publicAddr` on port 27017.
# Only used when `proxyListenerMode` is not 'multiplex' and `separateMongoListener` is true.
mongoPublicAddr: []
# Public cluster MySQL addresses, including port. Defaults to `publicAddr` on port 3036.
# Only used when `proxyListenerMode` is not 'multiplex'.
mysqlPublicAddr: []
# Public cluster postgres listener addresses, including port. Defaults to `publicAddr` on port 5432.
# Only used when `proxyListenerMode` is not 'multiplex' and `separatePostgresListener` is true.
postgresPublicAddr: []
# Public cluster SSH addresses, including port. Defaults to `publicAddr` on port 3023.
# Only used when `proxyListenerMode` is not 'multiplex'.
sshPublicAddr: []
# Public cluster tunnel SSH addresses, including port. Defaults to `publicAddr` on port 3024.
# Only used when `proxyListenerMode` is not 'multiplex'.
tunnelPublicAddr: []

# ACME is a protocol for getting Web X.509 certificates
# Note: ACME can only be used for single-instance clusters. It is not suitable for use in HA configurations.
# For HA configurations, see either the "highAvailability.certManager" or "tls" values.
# Setting acme to 'true' enables the ACME protocol and will attempt to get a free TLS certificate from Let's Encrypt.
# Setting acme to 'false' (the default) will cause Teleport to generate and use self-signed certificates for its web UI.
# This section is mutually exclusive with the "tls" value below.
acme: false
# acmeEmail is the email address to provide during certificate registration (this is a Let's Encrypt requirement)
acmeEmail: ""
# acmeURI is the ACME server to use for getting certificates. The default is to use Let's Encrypt's production server.
acmeURI: ""

# Set enterprise to true to use enterprise image
# You will need to download your Enterprise license from the Teleport dashboard and create a secret to use this:
# kubectl -n ${TELEPORT_NAMESPACE?} create secret generic license --from-file=/path/to/downloaded/license.pem
enterprise: false

# CRDs are installed by default when the operator is enabled. This manual override allows to disable CRD installation
# when deploying multiple releases in the same cluster.
# installCRDs:

# Configuration of the optional Teleport operator
operator:
  # Set enabled to true to add the Kubernetes Teleport Operator
  enabled: true
  # Kubernetes Teleport Operator image
  image: public.ecr.aws/gravitational/teleport-operator
  # Resources to request for the operator container
  # https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/
  resources:
    requests:
      cpu: 10m
      memory: "128Mi"
    limits:
      memory: "128Mi"

# If true, create & use Pod Security Policy resources
# https://kubernetes.io/docs/concepts/policy/pod-security-policy/
# WARNING: the PSP won't be deployed for Kubernetes 1.23 and higher.
# Please read https://goteleport.com/docs/deploy-a-cluster/helm-deployments/migration-kubernetes-1-25-psp/
podSecurityPolicy:
  enabled: true

# Labels is a map of key-value pairs about this cluster
labels:
  name: metal

# Mode to deploy the chart in. The default is "standalone". Options:
# - "standalone": will deploy a Teleport container running auth and proxy services with a PersistentVolumeClaim for storage.
# - "aws": will deploy Teleport using DynamoDB for backend/audit log storage and S3 for session recordings. (1)
# - "gcp": will deploy Teleport using Firestore for backend/audit log storage and Google Cloud storage for session recordings. (2)
# - "scratch": will deploy Teleport containers but will not provide default configuration file. You must pass your own configuration. (3)
# (1) To use "aws" mode, you must also configure the "aws" section below.
# (2) To use "gcp" mode, you must also configure the "gcp" section below.
# (3) When set to "scratch", you must write the teleport configuration in auth.teleportConfig and proxy.teleportConfig.
# `scratch` usage is strongly discouraged, this is a last resort option and
# everything should be doable with `standalone` mode + overrides through
# `auth.teleportConfig` and `proxy.teleportConfig`.
chartMode: standalone

# validateConfigOnDeploy enables a Kubernetes job before install and upgrade that will verify
# if the teleport.yaml configuration is valid and will block the deployment if it is not
validateConfigOnDeploy: true

# Whether the chart should create a Teleport ProvisionToken for the proxies to join the Teleport cluster.
# Disabling this flag will cause the proxies not to be able to join the auth pods. In this case, the
# Helm chart user is responsible for configuring working join_params on the proxy.
createProxyToken: true

# podMonitor controls the PodMonitor CR (from monitoring.coreos.com/v1)
# This CRD is managed by the prometheus-operator and allows workload to
# get monitored. To use this value, you need to run a `prometheus-operator`
# in the cluster for this value to take effect.
# See https://prometheus-operator.dev/docs/prologue/introduction/
podMonitor:
  # Whether the chart should deploy a PodMonitor.
  # Disabled by default as it requires the PodMonitor CRD to be installed.
  enabled: true
  # additionalLabels to put on the PodMonitor.
  # This is used to be selected by a specific prometheus instance.
  # Defaults to {prometheus: default} which seems to be the common default prometheus selector
  additionalLabels:
    instance: metal
  # interval is the interval between two metrics scrapes. Defaults to 30s
  interval: 30s

######################################################################
# Persistence settings (only used in "standalone" and "scratch" modes)
# NOTE: Changes in Kubernetes 1.23+ mean that persistent volumes will not automatically be provisioned in AWS EKS clusters
# without additional configuration. See https://docs.aws.amazon.com/eks/latest/userguide/ebs-csi.html for more details.
# This driver addon must be configured to use persistent volumes in EKS clusters after Kubernetes 1.23.
######################################################################
persistence:
  # Enable persistence using a PersistentVolumeClaim
  enabled: true
  # Leave blank to automatically create a PersistentVolumeClaim for Teleport storage.
  # If you would like to use a pre-existing PersistentVolumeClaim, put its name here.
  existingClaimName: ""
  # Size of persistent volume to request when created by Teleport.
  # Ignored if existingClaimName is provided.
  volumeSize: 10Gi

##################################################
# AWS-specific settings (only used in "aws" mode)
##################################################
aws:
  # The AWS region where the DynamoDB tables are located.
  region: ""
  # The DynamoDB table name to use for backend storage. Teleport will attempt to create this table automatically if it does not exist.
  # The container will need an appropriately-provisioned IAM role with permissions to create DynamoDB tables.
  backendTable: ""
  # The DynamoDB table name to use for audit log storage. Teleport will attempt to create this table automatically if it does not exist.
  # The container will need an appropriately-provisioned IAM role with permissions to create DynamoDB tables.
  # This MUST NOT be the same table name as used for 'backendTable' as the schemas are different.
  auditLogTable: ""
  # Whether to mirror audit log entries to stdout in JSON format (useful for external log collectors)
  auditLogMirrorOnStdout: false
  # The S3 bucket name to use for recorded session storage. Teleport will attempt to create this bucket automatically if it does not exist.
  # The container will need an appropriately-provisioned IAM role with permissions to create S3 buckets.
  sessionRecordingBucket: ""
  # Whether or not to turn on DynamoDB backups
  backups: false

  # Whether Teleport should configure DynamoDB's autoscaling.
  # Requires additional statements in the IAM Teleport Policy to be allowed to configure the autoscaling.
  # See https://goteleport.com/docs/setup/reference/backends/#dynamodb-autoscaling
  dynamoAutoScaling: false

  # DynamoDB autoscaling settings. Required if `dynamoAutoScaling` is `true`.
  # See https://goteleport.com/docs/setup/reference/backends/#dynamodb-autoscaling
  readMinCapacity: null # Integer
  readMaxCapacity: null # Integer
  readTargetValue: null # Float
  writeMinCapacity: null # Integer
  writeMaxCapacity: null # Integer
  writeTargetValue: null # Float

##################################################
# GCP-specific settings (only used in "gcp" mode)
##################################################
gcp:
  # The project name being used for the GCP account where Teleport is running.
  # See https://support.google.com/googleapi/answer/7014113?hl=en
  projectId: ""
  # The Firestore collection to use for backend storage. Teleport will attempt to create this collection automatically if it does not exist.
  # Either of the following must be true:
  # - The container will need an appropriately-provisioned IAM role/service account with permissions to create Firestore collections
  # - The service account credentials provided via 'credentialSecretName' will need permissions to create Firestore collections.
  backendTable: ""
  # The Firestore collection to use for audit log storage. Teleport will attempt to create this collection automatically if it does not exist.
  # Either of the following must be true:
  # - The container will need an appropriately-provisioned IAM role/service account with permissions to create Firestore collections
  # - The service account credentials provided via 'credentialSecretName' will need permissions to create Firestore collections.
  # This MUST NOT be the same collection name as used for 'backendTable' as the schemas are different.
  auditLogTable: ""
  # Whether to mirror audit log entries to stdout in JSON format (useful for external log collectors)
  auditLogMirrorOnStdout: false
  # The Google storage bucket name to use for recorded session storage. This bucket must already exist in the Google account being used.
  sessionRecordingBucket: ""
  # The name of the Kubernetes secret used to store the Google credentials.
  # You will need to create this secret manually. It must contain a JSON file from Google with the credentials that Teleport will use.
  # You can override this to a blank value if the worker node running Teleport already has a service account which grants access.
  credentialSecretName: teleport-gcp-credentials

# `highAvailability` contains settings controlling how Teleport pods are
# replicated and scheduled. This allows Teleport to run in a highly-available
# fashion: Teleport should sustain the crash/loss of a machine without interrupting
# the service.
#
# For auth pods:
#   When using "standalone" or "scratch" mode, you must use highly-available storage
#   (etcd, DynamoDB or Firestore) for multiple replicas to be supported.
#   Manually configuring NFS-based storage or ReadWriteMany volume claims
#   is NOT supported and will result in errors. Using Teleport's built-in
#   ACME client (as opposed to using cert-manager or passing certs through a secret)
#   is not supported with multiple replicas.
# For proxy pods:
#   Proxy pods need to be provided a certificate to be replicated (either via
#  `tls.existingSecretName` or via `highAvailability.certManager`).
#   If proxy pods are replicable, they will default to 2 replicas,
#   even if `highAvailability.replicaCount` is 1. To force a single proxy replica,
#   set `proxy.highAvailability.replicaCount: 1`.
highAvailability:
  # Controls the amount of pod replicas. The `highAvailability` comment describes
  # the replication requirements.
  #
  # WARNING: You **must** meet the replication criteria,
  # else the deployment will result in errors and inconsistent data.
  replicaCount: 1
  # Setting 'requireAntiAffinity' to true will use 'requiredDuringSchedulingIgnoredDuringExecution' to require that multiple Teleport pods must not be scheduled on the
  # same physical host. This will result in Teleport pods failing to be scheduled in very small clusters or during node downtime, so should be used with caution.
  # Setting 'requireAntiAffinity' to false (the default) uses 'preferredDuringSchedulingIgnoredDuringExecution' to make this a soft requirement.
  # This setting only has any effect when replicaCount is greater than 1.
  requireAntiAffinity: false
  # If enabled will create a Pod Disruption Budget
  # https://kubernetes.io/docs/concepts/workloads/pods/disruptions/
  podDisruptionBudget:
    enabled: false
    minAvailable: 1
  # Settings for cert-manager (can be used for provisioning TLS certs in HA mode)
  # These settings are mutually exclusive with the "tls" value below.
  certManager:
    # If set to true, a common name matching the cluster name will be set in the certificate signing request. This is mandatory for some CAs.
    addCommonName: false
    # If set to true, use cert-manager to get certificates for Teleport to use for TLS termination
    enabled: false
    # Name of the Issuer/ClusterIssuer to use for certs
    # NOTE: You will always need to create this yourself when certManager.enabled is true.
    issuerName: "letsencrypt-prod"
    # Kind of Issuer that cert-manager should look for.
    # This defaults to 'Issuer' to keep everything contained within the teleport namespace.
    issuerKind: "ClusterIssuer"
    # Group of Issuer that cert-manager should look for.
    # This defaults to 'cert-manager.io' which is the default Issuer group.
    issuerGroup: cert-manager.io
  # Injects delay when performing pod rollouts to mitigate the loss of all agent tunnels at the same time
  # See https://github.com/gravitational/teleport/issues/13129
  minReadySeconds: 15

# Settings for mounting your own TLS keypair to secure Teleport's web UI.
# These settings are mutually exclusive with the "highAvailability.certManager" and "acme" values above.
tls:
  # Name of an existing secret to use which contains a TLS keypair. Will automatically set the https_keypairs section in teleport.yaml.
  # Create the secret in the same namespace as Teleport using `kubectl create secret tls my-tls-secret --cert=/path/to/cert/file --key=/path/to/key/file`
  # See https://kubernetes.io/docs/concepts/configuration/secret/#tls-secrets for more information.
  existingSecretName: ""
  # (optional) Name of an existing secret to use which contains a CA or trust bundle in x509 PEM format.
  # Useful for building trust when using intermediate certificate authorities.
  # This will automatically set the SSL_CERT_FILE environment variable to trust the CA.
  # Create the secret with `kubectl create secret generic --from-file=ca.pem=/path/to/root-ca.pem
  # The filename inside the secret is important - it _must_ be ca.pem
  existingCASecretName: ""

##################################################
# Values that you shouldn't need to change.
##################################################

# Container image for the cluster.
# Since version 13, hardened distroless images are used by default.
# You can use the deprecated debian-based images by setting the value to
# `public.ecr.aws/gravitational/teleport`. Those images will be
# removed with teleport 14.
image: public.ecr.aws/gravitational/teleport-distroless
# Enterprise version of the image
# Since version 13, hardened distroless images are used by default.
# You can use the deprecated debian-based images by setting the value to
# `public.ecr.aws/gravitational/teleport-ent`. Those images will be
# removed with teleport 14.
enterpriseImage: public.ecr.aws/gravitational/teleport-ent-distroless
# Optional array of imagePullSecrets, to use when pulling from a private registry
imagePullSecrets: []
# Teleport logging configuration
log:
  # 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.
  level: DEBUG
  # Log output
  # Use a file path to log to disk: e.g. '/var/lib/teleport/teleport.log'
  # Other supported values: 'stdout', 'stderr' and 'syslog'
  output: stderr
  # Log format configuration
  # Possible output values are 'json' and 'text' (default).
  format: text
  # Possible extra_fields values include: timestamp, component, caller, and level.
  # All extra fields are included by default.
  extraFields: ["timestamp", "level", "component", "caller"]

##################################
# Extra Kubernetes configuration #
##################################

# nodeSelector to apply for pod assignment
# https://kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/#nodeselector
nodeSelector: {}

# Affinity for pod assignment
# https://kubernetes.io/docs/concepts/configuration/assign-pod-node/#affinity-and-anti-affinity
# NOTE: If affinity is set here, highAvailability.requireAntiAffinity cannot also be used - you can only set one or the other.
affinity: {}

# Kubernetes annotations to apply
# https://kubernetes.io/docs/concepts/overview/working-with-objects/annotations/
annotations:
  # Annotations for the ConfigMap
  config: {}
  # Annotations for the Deployment
  deployment: {}
  # Annotations for each Pod in the Deployment
  pod: {}
  # Annotations for the Service object
  service: {}
  # Annotations for the ServiceAccount object
  serviceAccount: {}
  # Annotations for the certificate secret generated by cert-manager v1.5+ when
  # highAvailability.certManager.enabled is true
  certSecret: {}
  # Annotations for the Ingress object
  ingress:
    external-dns.alpha.kubernetes.io/exclude: "true"
    cert-manager.io/cluster-issuer: letsencrypt-staging

# Kubernetes service account to create/use.
serviceAccount:
  # Specifies whether a ServiceAccount should be created
  create: true
  # The name of the ServiceAccount to use.
  # If not set and serviceAccount.create is true, the name is generated using the release name.
  # If create is false, the name will be used to reference an existing service account.
  name: ""
  # To set annotations on the service account, use the annotations.serviceAccount value.

# Set to true (default) to create Kubernetes ClusterRole and ClusterRoleBinding.
rbac:
  # Specifies whether a ClusterRole and ClusterRoleBinding should be created.
  # Set to false if your cluster level resources are managed separately.
  create: true

# Options for the Teleport proxy service
# This setting only applies to the proxy service. The teleport auth service is internal-only and always uses a ClusterIP.
# You can override the proxy's backend service to any service type (other than "LoadBalancer") here if really needed.
# To use an Ingress, set service.type=ClusterIP and ingress.enabled=true
service:
  type: ClusterIP
  # Additional entries here will be added to the service spec.
  spec:
    {}
    # loadBalancerIP: "1.2.3.4"

# Options for ingress
# If you set ingress.enabled to true, service.type MUST also be set to something other than "LoadBalancer" to prevent
# additional unnecessary load balancers from being created. Ingress controllers should provision their own load balancer.
# Using an Ingress also requires that you use the `tsh` client to connect to Kubernetes clusters and databases behind Teleport.
# See https://goteleport.com/docs/architecture/tls-routing/#working-with-layer-7-load-balancers-or-reverse-proxies-preview for details.
ingress:
  enabled: false
  # Setting suppressAutomaticWildcards to true will not automatically add *.<clusterName> as a hostname served
  # by the Ingress. This may be desirable if you don't use Teleport Application Access.
  suppressAutomaticWildcards: false
  # Additional entries here will be added to the ingress spec.
  spec:
    ingressClassName: nginx

# Extra arguments to pass to 'teleport start' for the main Teleport pod
extraArgs: []

# Extra environment to be configured on the Teleport pod
extraEnv:
  []
  # Get env from secret
  # - name: TELEPORT_GITHUB_CLIENT_ID
  #   valueFrom:
  #     secretKeyRef:
  #       name: teleport-github-app-secret
  #       key: clientID
  # - name: TELEPORT_GITHUB_CLIENT_SECRET
  #   valueFrom:
  #     secretKeyRef:
  #       name: teleport-github-app-secret
  #       key: clientSecret

# Extra volumes to mount into the Teleport pods
# https://kubernetes.io/docs/concepts/storage/volumes/
extraVolumes:
  - name: teleport-kube-agent-join-token
    secret:
      secretName: teleport-kube-agent-join-token
      items:
        - key: auth-token
          path: auth-token
  # - name: teleport-github-app-secret
  #   secret:
  #     secretName: teleport-github-app-secret

# Extra volume mounts corresponding to the volumes mounted above
extraVolumeMounts:
  - name: teleport-kube-agent-join-token
    mountPath: /secrets/kube-agent-token
    readOnly: true
  # - name: teleport-github-app-secret
  #   mountPath: /secrets/teleport-github-app-secret/clientID
  #   subPath: clientID
  # - name: teleport-github-app-secret
  #   mountPath: /secrets/teleport-github-app-secret/clientSecret
  #   subPath: clientSecret

# Allow the imagePullPolicy to be overridden
imagePullPolicy: IfNotPresent

# A list of initContainers to run before each Teleport pod starts
# https://kubernetes.io/docs/concepts/workloads/pods/init-containers/
initContainers: []
# - name: "teleport-init"
#   image: "alpine"
#   args: ["echo test"]

# If set, will run the command as a postStart handler
# https://kubernetes.io/docs/tasks/configure-pod-container/attach-handler-lifecycle-event/
postStart:
  command: []

# Resources to request for the teleport container
# https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/
resources:
  requests:
    cpu: "50m"
    memory: "256Mi"
  limits:
    memory: "256Mi"

# Security context to add to the container
securityContext:
  {}
  # runAsUser: 99

# Priority class name to add to the deployment
priorityClassName: ""

# Tolerations for pod assignment
# https://kubernetes.io/docs/concepts/configuration/taint-and-toleration/
tolerations: []

# Timeouts for the readiness and liveness probes
# https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-startup-probes/
probeTimeoutSeconds: 1

# Kubernetes termination grace period
# https://kubernetes.io/docs/concepts/containers/container-lifecycle-hooks/#hook-handler-execution
#
# This should be greater than 30 seconds as pods are waiting 30 seconds in a preStop hook.
terminationGracePeriodSeconds: 60

Teleport Kube agent Helm

I am using the teleport-kube-agent Helm chart, version 16.0.0, from https://charts.releases.teleport.dev, with values:

# Address of the teleport proxy with port (usually :3080).
  proxyAddr: "teleport.mydomain.cloud:443"
  roles: "kube"
  kubeClusterName: "operations"
  apps: []
  appResources: []
  awsDatabases: []
  azureDatabases: []
  databases: []
  databaseResources: []
  teleportVersionOverride: ""
  caPin: []
  insecureSkipProxyTLSVerify: false
  enterprise: false
  teleportConfig: {}
  tls:
    existingCASecretName: ""
  existingDataVolume: ""
  podSecurityPolicy:
    enabled: true
  labels:
    name: "operations"
  highAvailability:
    # Set to >1 for a high availability mode where multiple Teleport agent pods will be deployed.
    replicaCount: 1
    requireAntiAffinity: false
    podDisruptionBudget:
      enabled: false
      minAvailable: 1

  storage:
    enabled: true
    storageClassName: "local-path"
    requests: 128Mi

  serviceAccountName: ""

  serviceAccount:
    create: true
    name: ""

  rbac:
    create: true

  joinTokenSecret:
    create: false
    name: teleport-kube-agent-join-token

  log:
    level: INFO
    output: stderr
    format: json
    extraFields: ["timestamp", "level", "component", "caller"]

  affinity: {}

  nodeSelector: {}

  extraLabels:
    clusterRole: {}
    clusterRoleBinding: {}
    role: {}
    roleBinding: {}
    config: {}
    deployment: {}
    pod: {}
    podDisruptionBudget: {}
    podSecurityPolicy: {}
    secret: {}
    serviceAccount: {}

  annotations:
    config: {}
    deployment: {}
    pod: {}
    serviceAccount: {}

  extraArgs: []

  extraEnv: []

  extraVolumes: []
  # - name: myvolume
  #   secret:
  #     secretName: testSecret

  extraVolumeMounts: []
  # - name: myvolume
  #   mountPath: /path/on/host

  imagePullPolicy: IfNotPresent

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

  resources: {}

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

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

  tolerations: []

  probeTimeoutSeconds: 1

And here is the Configmap Generated by Helm:

apiVersion: v1
data:
  teleport.yaml: |
    app_service:
      enabled: false
    auth_service:
      enabled: false
    db_service:
      enabled: false
    discovery_service:
      enabled: false
    jamf_service:
      enabled: false
    kubernetes_service:
      enabled: true
      kube_cluster_name: operations
      labels:
        name: operations
    proxy_service:
      enabled: false
    ssh_service:
      enabled: false
    teleport:
      join_params:
        method: token
        token_name: /etc/teleport-secrets/auth-token
      log:
        format:
          extra_fields:
          - timestamp
          - level
          - component
          - caller
          output: json
        output: stderr
        severity: INFO
      proxy_server: teleport.mydomain.cloud:443
    version: v3
kind: ConfigMap
metadata:
  labels:
    argocd.argoproj.io/instance: operations-teleport-kube-agent
  name: operations-teleport-kube-agent
  namespace: kube-infra

Proposed Solution

Checking the source code in the configuration library (lib/config/configuration.go), it appears that the jamf_service configuration will be validated regardless of whether it is enabled (https://github.com/gravitational/teleport/blob/78d6325ec1940680f4bce0ee59ecd18833a9ef8a/lib/config/configuration.go#L476-L480). This behavior is inconsistent with other configurations (such as Okta, tracing, and windowsDesktop,etc.), which only validate when their respective enabled fields are set to true.

I propose modifying the code to conditionally validate the jamf_service configuration only when it is enabled, similar to the approach taken with other configurations. The suggested code change is:

if fc.Jamf.Enabled() {
    if err := applyJamfConfig(fc, cfg); err != nil {
        return trace.Wrap(err)
    }
}

I also created a PR to implement this, please review and let me know if it have any problem.

Thank you!

[gecube]

Hi!

The same. It stops me from using teleport agent v16.0.0. Waiting for the fix. P.S. I am enterprise client and expected that I will be able to upgrade smoothly.