Amazon EKS Guide — KubeBolt Docs

Authentication

How KubeBolt authenticates to EKS depends on where it runs:

In the cluster (Helm) — the API uses its own ServiceAccount and the chart’s ClusterRole. No AWS credentials are involved.
On your machine (Homebrew, krew, single binary) — it uses your kubeconfig like kubectl does, so the aws eks get-token exec in an EKS kubeconfig needs the AWS CLI and an active profile or SSO session on the host.
Single-container image — the image ships aws-cli. Mount your kubeconfig and your AWS config into the non-root user’s home:

docker run -p 3000:3000 \
  -v ~/.kube/config:/kubeconfig:ro -e KUBECONFIG=/kubeconfig \
  -v ~/.aws:/home/kubebolt/.aws:ro -e AWS_PROFILE=<profile> \
  ghcr.io/clm-cloud-solutions/kubebolt:latest

IRSA and EKS Pod Identity matter only for the optional agent’s Prometheus-read mode, which signs its AMP queries with the ServiceAccount’s AWS identity.

Docker Compose

The compose file mounts ~/.aws for EKS token generation, but the API image it builds does not include the AWS CLI, so a kubeconfig that runs aws eks get-token fails inside the container. Until that is fixed, run KubeBolt on the host (Homebrew or the binary), use the single-container image above, or give Compose a kubeconfig with a static token (for example a ServiceAccount token). The Compose steps themselves:

git clone https://github.com/clm-cloud-solutions/kubebolt.git
cd kubebolt

kubectl config use-context my-eks-cluster
./deploy/docker-kubeconfig.sh
cd deploy && docker compose up -d

The helper is not an EKS step: compose mounts /tmp/docker-kubeconfig, so it runs on every install. On a routable endpoint it rewrites nothing. Full Compose reference in Installation methods.

Helm with ALB Ingress

The chart creates two PVCs (10 GiB for VictoriaMetrics, 1 GiB for KubeBolt’s own data) on the default StorageClass. On EKS that needs the Amazon EBS CSI driver add-on (and its IAM role) — without it both PVCs stay Pending and the pods never start. Check with kubectl get storageclass.

helm install kubebolt \
  oci://ghcr.io/clm-cloud-solutions/kubebolt/helm/kubebolt \
  --namespace kubebolt --create-namespace \
  --set ingress.enabled=true \
  --set ingress.className=alb \
  --set ingress.hosts[0].host=kubebolt.example.com \
  --set ingress.hosts[0].paths[0].path=/ \
  --set ingress.hosts[0].paths[0].pathType=Prefix

This needs the AWS Load Balancer Controller; add its annotations (alb.ingress.kubernetes.io/scheme, target-type, certificate) through ingress.annotations. The Ingress fronts the UI and API only — agents in other clusters dial the gRPC port, which you expose separately (see Remote clusters).

KubeBolt itself needs no DaemonSet, so the kubeconfig and in-cluster modes work on EKS Fargate (the embedded VictoriaMetrics and the API need persistent volumes, which Fargate supports only through EFS). The optional agent’s DaemonSet does not run on Fargate nodes; its promread Deployment does.

Metrics Server

Unlike GKE and AKS, EKS does not install Metrics Server. Without it, KubeBolt still shows every resource, event and insight; only the live CPU/memory bars read “no data”. Install it with:

kubectl apply -f https://github.com/kubernetes-sigs/metrics-server/releases/latest/download/components.yaml

Amazon Managed Prometheus (AMP)

If your metrics already live in AMP, you don’t need a second pipeline: deploy the agent with agent.promRead.enabled=true and it reads kube-state-metrics, node and target-health families (and OpenCost’s, with agent.promRead.cost.enabled=true) straight from your workspace, signing requests with AWS SigV4 (agent.promRead.auth.mode=awsSigV4, credentials from IRSA or Pod Identity). Configure it from the Add cluster wizard — see Connecting clusters and Metrics.