> ## Documentation Index
> Fetch the complete documentation index at: https://docs.coreweave.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Traefik

> Deploy CoreWeave's Traefik Helm chart on CKS for ingress routing and Kubernetes API proxying

| Chart reference | Description |
| - | - |
| `coreweave/traefik` | CoreWeave's Helm chart for deploying Traefik on CKS clusters |

## About Traefik

The CoreWeave Traefik Helm chart is based on [the upstream Traefik chart](https://github.com/traefik/traefik-helm-chart). The CoreWeave chart includes additional templating for configurations commonly used in CKS clusters.

The chart's default values are set to work best on the CoreWeave platform. All code examples in this repository assume the default values. If you install the chart with different namespaces or resource names, update the values to match.

## Configuration

The following sections describe the chart's default Ingress behavior and how to enable TLS on Ingresses.

### Ingress DNS

By default, the chart applies a wildcard hostname through a `service.beta.kubernetes.io/external-hostname` annotation:

```text theme={"system"}
service.beta.kubernetes.io/external-hostname: '*'
```

This lets Traefik route to Ingress hosts within the CKS cluster. CKS automatically suffixes the wildcard hostname (`*`) with the appropriate domain name for your cluster. For Services that don't route through Traefik, specific DNS hostnames still take precedence.

To retrieve the applied value at any time, use `kubectl`:

```bash theme={"system"}
kubectl get svc traefik -n traefik -o=jsonpath='{.status.conditions[?(@.type=="ExternalRecords")].message}'
```

<Info>
  For more information on exposing Services, see [How to: Expose a Service](/products/networking/ingress-service/expose-service-dns).
</Info>

### IngressRouteTCP and Kubernetes API proxy

The chart's default values include a [Traefik IngressRouteTCP](https://doc.traefik.io/traefik/routing/providers/kubernetes-crd/#kind-ingressroutetcp) TCP router for your cluster's Kubernetes API server. This Service proxies HTTP traffic to your cluster over [Direct Connect](/products/networking/direct-connect/about-direct-connect) and provides TLS passthrough.

To locate the hostname of this Service, run the following command:

```bash theme={"system"}
kubectl get svc traefik-k8s -n traefik -o=jsonpath='{.status.conditions[?(@.type=="ExternalRecords")].message}'
```

<Warning>
  When you reach the Kubernetes API server over Direct Connect, use the publicly resolvable hostname from the `traefik-k8s` Service, not the private load balancer IP. The API server certificate includes a DNS subject alternative name (SAN) for this hostname, but it doesn't include the `traefik-k8s` load balancer IP. Connecting by IP causes TLS verification errors.

  For example, `k8s.[ORG-ID]-[CLUSTER-NAME].coreweave.app`. This hostname resolves to the private load balancer IP.
</Warning>

#### Configure client trust and authentication

The Traefik API proxy passes TLS through without terminating it, so clients connect directly to the Kubernetes API server. The API server presents a certificate signed by the cluster certificate authority (CA) and authenticates each request itself. A Managed Auth kubeconfig instead relies on a publicly trusted certificate and uses a CoreWeave API access token. If you change only the kubeconfig's `server` value, certificate verification fails with an error such as `x509: certificate signed by unknown authority` on Linux and Windows, or `certificate is not trusted` on macOS. Adding the cluster CA fixes verification, but the API server still rejects the CoreWeave API access token.

CKS publishes the cluster CA in the `cluster-info` ConfigMap in the `kube-public` namespace, which you can read without credentials. On a public cluster, read it from the [unmanaged endpoint](/products/cks/auth-access/unmanaged-auth/implement-unmanaged-auth):

```bash theme={"system"}
CA_DATA=$(curl -s https://api.[ORG-ID]-[CLUSTER-HASH].k8s.[ZONE].coreweave.com/api/v1/namespaces/kube-public/configmaps/cluster-info \
  | jq -r '.data.kubeconfig | capture("certificate-authority-data:\\s*(?<ca>\\S+)") | .ca')
```

If you already have a kubeconfig context that reaches the cluster, such as a Managed Auth kubeconfig through the Tailscale proxy in [CoreWeave Managed Auth](/products/cks/auth-access/tailscale-vpn#coreweave-managed-auth) mode on a private cluster, read it with `kubectl` instead. Replace `[CONTEXT]` with that context's name:

```bash theme={"system"}
CA_DATA=$(kubectl --context [CONTEXT] get configmap cluster-info --namespace kube-public --output json \
  | jq -r '.data.kubeconfig | capture("certificate-authority-data:\\s*(?<ca>\\S+)") | .ca')
```

Add a cluster entry for the `traefik-k8s` hostname that uses the CA as its `certificate-authority-data`. Then create a context that pairs it with a user that authenticates through OIDC or an authentication webhook, such as the `kubelogin` user from [Configure a kubectl context with kubelogin](/products/cks/auth-access/unmanaged-auth/implement-unmanaged-auth#step-5-configure-a-kubectl-context-with-kubelogin). Replace `[USER]` with that user's name:

```bash theme={"system"}
kubectl config set-cluster cks-traefik \
  --server=https://k8s.[ORG-ID]-[CLUSTER-NAME].coreweave.app
kubectl config set clusters.cks-traefik.certificate-authority-data "$CA_DATA"
kubectl config set-context cks-traefik --cluster=cks-traefik --user=[USER]
```

Requests through the Traefik API proxy don't pass through Managed Auth, so CoreWeave IAM access policies don't apply to them. Kubernetes RBAC authorizes them.

### Create Ingresses with TLS

<Warning>
  An Ingress with TLS requires `cert-manager` to create and manage the certificates. If you don't have an existing deployment, you can deploy CoreWeave's [cert-manager and its subchart, cert-issuer](/products/cks/clusters/coreweave-charts/cert-manager) for this purpose.
</Warning>

After you deploy the chart, you can use Traefik as the `IngressClass` for a Kubernetes Ingress with TLS. To create the TLS certificate, `cert-manager` uses the `ClusterIssuer` specified by the `cert-manager.io/cluster-issuer` annotation on the `Ingress` object.

## Example chart

In this example manifest, the Ingress uses the default Let's Encrypt `ClusterIssuer` from CoreWeave's [cert-issuer](/products/cks/clusters/coreweave-charts/cert-manager) chart. You can also configure your own TLS certificate solution.

```yaml title="ingress-example.yaml - An example using Traefik with TLS and DNS" highlight={5-7,13-14,27-28} theme={"system"}
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
  annotations:
    # This value must match either the ClusterIssuer created by Traefik,
    # or another pre-existing ClusterIssuer
        cert-manager.io/cluster-issuer: letsencrypt-prod
  name: ingress1
  namespace: namespace1
spec:
  ingressClassName: traefik
  rules:
  # The FQDN used to access this Ingress via the Traefik Service
  - host: &host ingress1.myorg-mycluster.coreweave.app
    http:
      paths:
      - backend:
          service:
            name: my-service
            port:
              number: 80
        path: /
        pathType: Prefix
  tls:
  - hosts:
    - *host
    # This secret will be automatically created for you
    secretName: ingress1-tls
```

<Info>
  For more information on Traefik as a Kubernetes Ingress provider, see [the official Traefik documentation](https://doc.traefik.io/traefik/providers/kubernetes-ingress/).
</Info>