What causes "awscreds: read container authorization token file: %w" in JuliusBrussee/caveman?

Verify the file exists at the exact path in AWS_CONTAINER_AUTHORIZATION_TOKEN_FILE (ls -l) inside the container.

awscreds: read container authorization token file

Error message

awscreds: read container authorization token file: %w

What it means

containerAuthToken fails to read the file named by AWS_CONTAINER_AUTHORIZATION_TOKEN_FILE, which EKS Pod Identity / IRSA uses to carry the container authorization token. The library refuses to continue without the token rather than sending unauthenticated metadata requests.

Solutions

Verify the file exists at the exact path in AWS_CONTAINER_AUTHORIZATION_TOKEN_FILE (ls -l) inside the container.
Ensure the Kubernetes service-account token volume is mounted (EKS Pod Identity/IRSA admission injected it).
Fix read permissions or run as a user that can read the file.
Alternatively set AWS_CONTAINER_AUTHORIZATION_TOKEN directly if appropriate.

Example fix

// before
tokenFile := "/var/run/secrets/pod-identity/tokn" // typo
// after
tokenFile := "/var/run/secrets/pod-identity/token"

Defensive patterns

Strategy: validation

Validate before calling

if f := os.Getenv("AWS_CONTAINER_AUTHORIZATION_TOKEN_FILE"); f != "" {
    if _, err := os.Stat(f); err != nil {
        return fmt.Errorf("auth token file missing: %w", err)
    }
}

Try / catch

if err := creds.Load(ctx); err != nil {
    if errors.Is(err, fs.ErrNotExist) { /* token volume not mounted; retry with backoff */ }
}

Prevention

Wait for the projected service-account token volume before startup (init container or readiness gate)
Stat the token file in a readiness probe
Never hardcode token paths — read them from the env var

When it happens

Trigger: AWS_CONTAINER_AUTHORIZATION_TOKEN_FILE is set but os.ReadFile on the path fails: file missing, wrong path, no read permission, or the projected service-account token volume is not mounted.

Common situations: Pod running before the serviceaccount token volume is mounted; typo'd path; running the same code locally where the token file doesn't exist; container image drops read permissions on the mount.

Understand the failure class

Background: "failed to read file", EACCES, ENOENT and "could not read <path>" errors: when a program can't read a file from disk — this error's family across 49 libraries.

Related errors

AI-assisted analysis of JuliusBrussee/caveman@3ee70a1026 (2026-09-20). Data as JSON: /api/errors/e6158e3166fe73f8. Report an issue: GitHub.

Appendix: source

Thrown at shared/platform/awscreds/awscreds.go:447

	if err != nil {
		return nil, err
	}
	if auth != "" {
		req.Header.Set("Authorization", auth)
	}
	req.Header.Set("Accept", "application/json")
	body, err := p.doJSON(p.link, req, "container credentials")
	if err != nil {
		return nil, err
	}
	return credentialsFromJSON(body, "container")
}

func (p *Provider) containerAuthToken() (string, error) {
	if file := p.env("AWS_CONTAINER_AUTHORIZATION_TOKEN_FILE"); file != "" {
		raw, err := os.ReadFile(file)
		if err != nil {
			return "", fmt.Errorf("awscreds: read container authorization token file: %w", err)
		}
		return strings.TrimSpace(string(raw)), nil
	}
	return p.env("AWS_CONTAINER_AUTHORIZATION_TOKEN"), nil
}

// containerCredentialHosts is the fixed set of non-loopback addresses the AWS
// SDKs will talk to in PLAINTEXT for container credentials: the ECS task-role
// endpoint and EKS Pod Identity (v4 and v6). Accepting all of 169.254.0.0/16 and
// fe80::/10 — every link-local address — instead meant any neighbouring
// link-local listener could be handed the task role's Authorization token.
var containerCredentialHosts = []netip.Addr{
	netip.MustParseAddr("169.254.170.2"),  // ECS task role
	netip.MustParseAddr("169.254.170.23"), // EKS Pod Identity
	netip.MustParseAddr("fd00:ec2::23"),   // EKS Pod Identity over IPv6
}

// imdsHosts is the same idea for the instance metadata service.

View on GitHub (pinned to 3ee70a1026)