Integrations

EKS cluster discovery

After the profiles are written, Frost looks for EKS clusters across every region and account you can reach, and keeps ~/.kube/config in step with what it finds.

How the scan works

The EKS step runs at the end of every refresh, once the profiles exist:

List the regions Frost calls ec2:DescribeRegions with the first generated profile, so the list is the set of regions enabled for your organisation rather than a hardcoded one that goes stale.
Try every region with every profile For each region and profile pair, Frost calls eks:ListClusters. Most pairs fail — a profile without EKS access, or a region you do not use — and those failures are expected and ignored.
Describe what it found Each cluster that was listed is then described (eks:DescribeCluster) for its API endpoint and certificate authority data, which is what a kubeconfig entry needs.
Merge into ~/.kube/config One cluster, one user and one context per discovered cluster.

The calls run in parallel, so a scan across dozens of regions and profiles takes seconds rather than minutes. Everything it found — and every access error it hit — is recorded on the Activity page, grouped by region.

Access errors in this step are normal. A profile scoped to one team's account will be denied in every region, which is exactly what should happen. Only successful describes produce kubeconfig entries.

What is written to your kubeconfig

Each discovered cluster contributes three entries under one name:

clusters:
  - name: production
    cluster:
      server: https://XXXXXXXX.gr7.eu-west-1.eks.amazonaws.com
      certificate-authority-data: LS0tLS1CRUdJTi…
users:
  - name: production
    user:
      exec:
        apiVersion: client.authentication.k8s.io/v1
        command: /path/to/Frost/resources/aws-iam-authenticator
        args: ["token", "-i", "production"]
        env:
          - name: AWS_PROFILE
            value: prod-admin
        interactiveMode: Never
contexts:
  - name: production
    context:
      cluster: production
      user: production

The command is the copy of aws-iam-authenticator bundled inside the Frost application, so kubectl works whether or not the AWS CLI is installed. AWS_PROFILE pins the credentials each cluster is reached with — the profile that discovered it.

How contexts are named

A context named after an ARN is unusable in a runbook, so Frost derives the shortest name that is still unambiguous across the clusters it found:

Situation	Context name
One region, one permission set	`production`
Several regions, one permission set	`production:eu-west-1`
One region, several permission sets	`production:admin`
Several of each	`production:eu-west-1:admin`

The decision is made once per scan and applied to every cluster, so all your contexts share one naming scheme rather than a mix. Because it is derived from cluster metadata rather than local state, everyone on the team ends up with the same names:

kubectl

$ kubectl config get-contexts -o name
production
staging
analytics

# a script anyone on the team can run, unchanged
$ kubectl --context production rollout restart deploy/api
deployment.apps/api restarted

Clusters that share a name across accounts, while also sharing a region and permission set, can end up with the same context name — one entry then replaces the other. If you run identically named clusters in several accounts, give them distinct names, or open an issue so we can weigh disambiguating on account too.

How the merge treats your kubeconfig

Frost reads ~/.kube/config, replaces any cluster, user or context whose name matches one it just discovered, and writes the file back. Entries you added yourself — clusters from other providers, contexts from kind or Docker Desktop — are kept, as is your current context.

The file is re-serialized as YAML on every write, so comments and your original formatting are not preserved. If you keep notes in that file, keep them somewhere else — or point Frost's clusters at a separate file by keeping ~/.kube/config out of the picture with KUBECONFIG.

The write itself is atomic and leaves the file's own properties alone: the permissions you gave ~/.kube/config are kept, a ~/.kube/config that is a symlink stays one, and an interrupted refresh cannot truncate it. A file Frost has to create from nothing is created 0600. Security & privacy →

Clusters are not removed when they disappear from AWS. A stale context simply stops authenticating; delete it with kubectl config delete-context if you want it gone.

Permissions

Discovery needs ec2:DescribeRegions on at least the first profile, plus eks:ListClusters and eks:DescribeCluster in the accounts you want scanned. Actually reaching a cluster afterwards is a Kubernetes RBAC question: your IAM principal has to be mapped inside the cluster (through EKS access entries or aws-auth), which is configured on the cluster side, not by Frost.

If kubectl reports an authentication error against a discovered cluster, troubleshooting walks through the usual causes.