Integrations

The bundled IAM authenticator

Talking to EKS means turning AWS credentials into a Kubernetes token. Frost bundles the standard tool for that, so kubectl works without the AWS CLI installed.

What it is

aws-iam-authenticator is the upstream Kubernetes SIG tool that turns AWS credentials into a token an EKS API server accepts. kubectl runs it as an exec credential plugin: every time it needs to authenticate, it spawns the binary, reads a short-lived token from its output, and uses that for the request.

Frost ships a copy inside the application. That is the difference between "the clusters Frost discovered are ready to use" and "install the AWS CLI first, then configure it" — with the bundled binary, kubectl works immediately after a refresh.

How Frost uses it

Each cluster Frost writes to ~/.kube/config gets a user entry pointing at the bundled binary:

exec:
  apiVersion: client.authentication.k8s.io/v1
  command: /Applications/Frost.app/Contents/Resources/aws-iam-authenticator
  args: ["token", "-i", "production"]
  env:
    - name: AWS_PROFILE
      value: prod-admin
  interactiveMode: Never

• -i is the cluster name, as EKS knows it — not the context name Frost chose.
• AWS_PROFILE pins the profile the cluster was discovered with, so kubectl authenticates as that permission set no matter what your shell's environment says.
• interactiveMode: Never because the plugin never needs a terminal: the SSO token it builds on is already on disk, refreshed by Frost.

The credentials chain ends at the same place everything else does — the profile in ~/.aws/config and the token cache Frost keeps current. When Frost's token expires and is refreshed, kubectl keeps working without you touching anything.

Where the binary lives

Frost probes for the binary at startup rather than assuming a layout, so installs from older versions — which kept it in a different place inside the package — keep working. Whichever copy it finds is the path written into your kubeconfig.

Using a different authenticator

Set AWS_IAM_AUTHENTICATOR_PATH in Frost's environment to an absolute path and that path is written into the kubeconfig entries instead. Useful if you already manage the binary yourself, need a specific version, or want the entries to point at something on PATH that survives app updates.

# macOS / Linux, launching Frost from a shell
AWS_IAM_AUTHENTICATOR_PATH=/usr/local/bin/aws-iam-authenticator open -a Frost

The variable is read when Frost starts, and the new path lands in your kubeconfig at the next refresh.

You can also replace the entries by hand — nothing in the kubeconfig merge cares which command a user entry names, as long as the name matches the cluster. Note that a refresh will rewrite entries whose names match the clusters it rediscovers.

Version and provenance

The binary is not committed to the repository. The release workflow downloads it from the upstream GitHub release at build time, at a version pinned in the workflow, and verifies the download against a SHA-256 checksum pinned per platform and architecture. A mismatch fails the build rather than shipping unverified bytes.

Because it is fetched during the build, the exact version travels with each Frost release; the pin is visible in .github/workflows/build.yaml.

Windows on ARM

Upstream publishes no windows_arm64 build of the authenticator, so the ARM64 Frost installer bundles the windows_amd64 binary and Windows runs it under emulation. Frost itself stays native ARM64 — only this helper is emulated, and only for the fraction of a second kubectl spends waiting for a token.

If you would rather have a native binary there, point Frost at one with AWS_IAM_AUTHENTICATOR_PATH.

If you do not use EKS

The authenticator is only ever invoked by kubectl, so on a machine with no clusters it sits unused inside the app bundle. Frost itself never runs it — it only writes its path into the kubeconfig entries the EKS scan produces.