Setup Multiple Credentials for AWS EKS and AWS SSO in Multiple Accounts for FreeLens

READER BEWARE: THE FOLLOWING WRITTEN ENTIRELY BY AI WITHOUT HUMAN EDITING.

Introduction

Managing multiple AWS EKS clusters across different AWS accounts can be challenging, especially when you want to visualize and interact with them using FreeLens (OpenLens). When you add AWS SSO (Single Sign-On) into the mix, the configuration becomes even more complex. This guide walks you through setting up your AWS credentials, configuring kubectl contexts, and integrating everything with FreeLens for seamless multi-cluster Kubernetes management.

Prerequisites

Before you begin, ensure you have:

• AWS SSO configured for your organization
• Access to multiple AWS accounts through AWS SSO
• Multiple EKS clusters across different AWS accounts
• AWS CLI v2 installed (aws --version should show version 2.x)
• kubectl installed (kubectl version --client)
• FreeLens (OpenLens) installed
• aws-iam-authenticator installed (required for EKS authentication)

Understanding the Architecture

When working with AWS SSO, multiple EKS clusters, and FreeLens, you’re dealing with several interconnected components:

1. AWS SSO: Centralized authentication portal for multiple AWS accounts
2. AWS Profiles: Named configurations in your AWS config file
3. EKS Clusters: Kubernetes clusters running in different AWS accounts
4. kubectl Contexts: Named configurations pointing to different Kubernetes clusters
5. FreeLens: Kubernetes IDE that uses your kubectl configuration

The key challenge is setting up the authentication chain so FreeLens can seamlessly access all your EKS clusters through AWS SSO.

Step 1: Configure AWS SSO

Initial SSO Setup

First, configure AWS SSO with your organization’s SSO portal:

aws configure sso

This interactive command will prompt you for:

• SSO session name: A friendly name for your SSO session (e.g., my-company-sso)
• SSO start URL: Your organization’s AWS SSO portal URL (e.g., https://my-company.awsapps.com/start)
• SSO region: The AWS region where your SSO directory is configured (e.g., us-east-1)
• SSO registration scopes: Leave as default (sso:account:access)

After completing this, your browser will open for authentication. Once authenticated, you’ll be prompted to select:

• The AWS account you want to configure
• The permission set (IAM role) to use

Choose your first account and give it a profile name (e.g., dev-account).

Configure Additional AWS Accounts

Repeat the SSO configuration for each AWS account:

# Configure production account
aws configure sso --profile prod-account

# Configure staging account
aws configure sso --profile staging-account

# Configure sandbox account
aws configure sso --profile sandbox-account

Step 2: Manual AWS Config File Setup

While aws configure sso creates basic profiles, for FreeLens integration, you need more detailed configuration. Edit your ~/.aws/config file to include all necessary settings.

Understanding the AWS Config File Structure

The ~/.aws/config file has two types of entries:

1. SSO Session Definitions: Define reusable SSO sessions
2. Profile Definitions: Define named AWS profiles that reference SSO sessions

Complete AWS Config Example

Here’s a comprehensive example showing multiple accounts with SSO:

# SSO Session Definition
# This creates a reusable SSO session that multiple profiles can reference
[sso-session my-company-sso]
sso_start_url = https://my-company.awsapps.com/start
sso_region = us-east-1
sso_registration_scopes = sso:account:access

# Development Account Profile
[profile dev-account]
sso_session = my-company-sso
sso_account_id = 123456789012
sso_role_name = AdministratorAccess
region = us-west-2
output = json

# Production Account Profile
[profile prod-account]
sso_session = my-company-sso
sso_account_id = 234567890123
sso_role_name = PowerUserAccess
region = us-east-1
output = json

# Staging Account Profile
[profile staging-account]
sso_session = my-company-sso
sso_account_id = 345678901234
sso_role_name = AdministratorAccess
region = us-west-2
output = json

# Sandbox Account Profile
[profile sandbox-account]
sso_session = my-company-sso
sso_account_id = 456789012345
sso_role_name = DeveloperAccess
region = eu-west-1
output = json

# Default profile (optional, points to most-used account)
[default]
sso_session = my-company-sso
sso_account_id = 123456789012
sso_role_name = AdministratorAccess
region = us-west-2
output = json

Config File Breakdown

Let’s break down the important fields:

• [sso-session NAME]: Defines a reusable SSO session. All profiles using the same SSO portal can reference this.
• sso_start_url: Your organization’s AWS SSO portal URL.
• sso_region: The region where your SSO is configured (not the region for AWS resources).
• sso_session: In profile sections, references the SSO session to use.
• sso_account_id: The 12-digit AWS account ID.
• sso_role_name: The permission set/role name (as shown in AWS SSO portal).
• region: The default AWS region for this profile (where your EKS clusters are).
• output: Output format for AWS CLI commands (json, yaml, text, table).

Multiple Regions Per Account

If you have EKS clusters in different regions within the same account:

# Development Account - US West 2
[profile dev-account-us-west-2]
sso_session = my-company-sso
sso_account_id = 123456789012
sso_role_name = AdministratorAccess
region = us-west-2
output = json

# Development Account - US East 1
[profile dev-account-us-east-1]
sso_session = my-company-sso
sso_account_id = 123456789012
sso_role_name = AdministratorAccess
region = us-east-1
output = json

Step 3: Login to AWS SSO

Before you can access your EKS clusters, you need to authenticate with AWS SSO:

# Login to your SSO session
aws sso login --sso-session my-company-sso

This opens your browser for authentication. After successful login, your credentials are cached locally (typically for 8 hours).

To verify your access:

# Test development account
aws sts get-caller-identity --profile dev-account

# Test production account
aws sts get-caller-identity --profile prod-account

# Test staging account
aws sts get-caller-identity --profile staging-account

You should see output showing your assumed role for each account.

Step 4: Configure kubectl for EKS Clusters

Now that AWS credentials are configured, add your EKS clusters to your kubectl configuration.

Update kubeconfig for Each Cluster

Use the AWS CLI to update your kubeconfig:

# Development EKS cluster
aws eks update-kubeconfig \
  --name dev-eks-cluster \
  --region us-west-2 \
  --profile dev-account \
  --alias dev-eks

# Production EKS cluster
aws eks update-kubeconfig \
  --name prod-eks-cluster \
  --region us-east-1 \
  --profile prod-account \
  --alias prod-eks

# Staging EKS cluster
aws eks update-kubeconfig \
  --name staging-eks-cluster \
  --region us-west-2 \
  --profile staging-account \
  --alias staging-eks

# Sandbox EKS cluster
aws eks update-kubeconfig \
  --name sandbox-eks-cluster \
  --region eu-west-1 \
  --profile sandbox-account \
  --alias sandbox-eks

Understanding the update-kubeconfig Command

• --name: The name of your EKS cluster in AWS
• --region: The AWS region where the EKS cluster is located
• --profile: The AWS profile to use for authentication
• --alias: A friendly name for the kubectl context (optional but recommended)

This command adds a new context to your ~/.kube/config file with the appropriate cluster information and authentication settings.

Verify kubectl Contexts

List all available contexts:

kubectl config get-contexts

You should see output like:

CURRENT   NAME          CLUSTER                                               AUTHINFO
*         dev-eks       arn:aws:eks:us-west-2:123456789012:cluster/dev-eks    arn:aws:eks:us-west-2:123456789012:cluster/dev-eks
          prod-eks      arn:aws:eks:us-east-1:234567890123:cluster/prod-eks   arn:aws:eks:us-east-1:234567890123:cluster/prod-eks
          staging-eks   arn:aws:eks:us-west-2:345678901234:cluster/staging    arn:aws:eks:us-west-2:345678901234:cluster/staging
          sandbox-eks   arn:aws:eks:eu-west-1:456789012345:cluster/sandbox    arn:aws:eks:eu-west-1:456789012345:cluster/sandbox

Test kubectl Access

Switch to each context and verify access:

# Test dev cluster
kubectl config use-context dev-eks
kubectl get nodes

# Test prod cluster
kubectl config use-context prod-eks
kubectl get nodes

# Test staging cluster
kubectl config use-context staging-eks
kubectl get nodes

Step 5: Understanding the kubeconfig File Structure

Let’s examine what the update-kubeconfig command created in your ~/.kube/config file:

apiVersion: v1
kind: Config
clusters:
- cluster:
    certificate-authority-data: <base64-encoded-ca-cert>
    server: https://ABCDEF123456.gr7.us-west-2.eks.amazonaws.com
  name: arn:aws:eks:us-west-2:123456789012:cluster/dev-eks-cluster

contexts:
- context:
    cluster: arn:aws:eks:us-west-2:123456789012:cluster/dev-eks-cluster
    user: arn:aws:eks:us-west-2:123456789012:cluster/dev-eks-cluster
  name: dev-eks

users:
- name: arn:aws:eks:us-west-2:123456789012:cluster/dev-eks-cluster
  user:
    exec:
      apiVersion: client.authentication.k8s.io/v1beta1
      command: aws
      args:
      - --region
      - us-west-2
      - eks
      - get-token
      - --cluster-name
      - dev-eks-cluster
      - --output
      - json
      env:
      - name: AWS_PROFILE
        value: dev-account

current-context: dev-eks

Key Components

1. clusters: Contains cluster endpoint and certificate information
2. contexts: Associates a cluster with user credentials and optionally a namespace
3. users: Defines how to authenticate (in this case, using AWS CLI)
4. current-context: The default context kubectl will use

The critical part for AWS SSO is the user.exec section, which tells kubectl to run aws eks get-token using the specified AWS profile. This means kubectl will use your AWS SSO credentials automatically.

Step 6: Configure FreeLens

FreeLens reads your kubectl configuration automatically, but there are some important considerations for AWS SSO.

Adding Clusters to FreeLens

1. Open FreeLens
2. Click File → Add Cluster (or press Cmd+Shift+A on macOS / Ctrl+Shift+A on Windows/Linux)
3. FreeLens will automatically detect clusters from your ~/.kube/config
4. Select the clusters you want to add
5. Click Add Cluster

Alternatively, you can manually add clusters:

1. Click the + icon in the Catalog
2. Choose Add from kubeconfig
3. Select your ~/.kube/config file
4. Choose the contexts you want to add

FreeLens with AWS SSO: Important Considerations

Issue 1: Token Expiration

AWS SSO tokens typically expire after 8 hours. When this happens, FreeLens may show authentication errors. To resolve:

# Re-login to AWS SSO
aws sso login --sso-session my-company-sso

Then refresh FreeLens (disconnect and reconnect to the cluster).

Issue 2: AWS Profile Environment Variable

FreeLens needs to know which AWS profile to use. This is typically configured in your kubeconfig, but if you encounter issues, you can set environment variables before launching FreeLens:

On macOS/Linux:

# Set default AWS profile
export AWS_PROFILE=dev-account

# Launch FreeLens
open /Applications/FreeLens.app

On Windows (PowerShell):

$env:AWS_PROFILE = "dev-account"
& "C:\Program Files\FreeLens\FreeLens.exe"

Issue 3: AWS CLI Path

FreeLens must be able to find the aws CLI command. Ensure it’s in your system PATH:

# Check AWS CLI location
which aws

# If using macOS and installed via Homebrew, ensure the path is set
echo $PATH

If FreeLens can’t find AWS CLI, you may need to create a symlink or add the AWS CLI path to your system’s PATH environment variable.

Creating a Launch Script for FreeLens

To make FreeLens work seamlessly with AWS SSO, create a launch script that ensures credentials are refreshed:

macOS/Linux (~/bin/launch-freelens.sh):

#!/bin/bash
set -e

# SSO session name
SSO_SESSION="my-company-sso"

echo "Checking AWS SSO login status..."

# Try to get caller identity, if it fails, login
if ! aws sts get-caller-identity --profile dev-account &>/dev/null; then
    echo "AWS SSO credentials expired or not found. Logging in..."
    aws sso login --sso-session "$SSO_SESSION"
else
    echo "AWS SSO credentials are valid."
fi

echo "Launching FreeLens..."
open /Applications/FreeLens.app

echo "FreeLens launched successfully!"

Make it executable:

chmod +x ~/bin/launch-freelens.sh

Windows (PowerShell launch-freelens.ps1):

$SSOSession = "my-company-sso"

Write-Host "Checking AWS SSO login status..."

# Try to get caller identity
$identity = aws sts get-caller-identity --profile dev-account 2>&1

if ($LASTEXITCODE -ne 0) {
    Write-Host "AWS SSO credentials expired or not found. Logging in..."
    aws sso login --sso-session $SSOSession
} else {
    Write-Host "AWS SSO credentials are valid."
}

Write-Host "Launching FreeLens..."
Start-Process "C:\Program Files\FreeLens\FreeLens.exe"

Write-Host "FreeLens launched successfully!"

Step 7: Managing Multiple Clusters in FreeLens

Organizing Clusters with Labels

FreeLens allows you to organize clusters with labels. Add labels to your clusters:

1. Right-click on a cluster in FreeLens
2. Select Settings
3. Add labels like:
   • environment: development
   • account: dev-account
   • region: us-west-2

Workspace Organization

Create separate workspaces for different environments:

1. Development Workspace: Contains all dev clusters
2. Production Workspace: Contains all production clusters
3. Staging Workspace: Contains all staging clusters

This helps you avoid accidentally making changes to production clusters.

Switching Between Clusters

FreeLens makes it easy to switch between clusters:

1. Use the cluster dropdown in the top-left
2. Or use the keyboard shortcut Cmd+K (macOS) / Ctrl+K (Windows/Linux) to open the command palette
3. Type the cluster name to quickly switch

Step 8: Troubleshooting Common Issues

Problem: “error: You must be logged in to the server (Unauthorized)”

Cause: AWS SSO credentials have expired or are invalid.

Solution:

# Re-login to AWS SSO
aws sso login --sso-session my-company-sso

# Verify credentials
aws sts get-caller-identity --profile dev-account

Problem: “error: exec plugin: invalid apiVersion”

Cause: Mismatch between kubectl version and the apiVersion in kubeconfig.

Solution: Update the kubeconfig file manually. Change apiVersion: client.authentication.k8s.io/v1alpha1 to client.authentication.k8s.io/v1beta1 in your ~/.kube/config.

Or regenerate the kubeconfig:

aws eks update-kubeconfig --name cluster-name --profile profile-name

Problem: FreeLens shows “Could not find AWS CLI”

Cause: FreeLens cannot find the aws command in PATH.

Solution:

1. Find AWS CLI location: which aws
2. Create a symlink to a standard location:

   sudo ln -s /usr/local/bin/aws /usr/bin/aws
   

3. Or add AWS CLI directory to system PATH

Problem: “An error occurred (AccessDenied) when calling the AssumeRole operation”

Cause: Your SSO role doesn’t have permissions to access EKS.

Solution: Ensure your IAM role in the target account has the necessary EKS permissions:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "eks:DescribeCluster",
        "eks:ListClusters"
      ],
      "Resource": "*"
    }
  ]
}

Additionally, your IAM role must be mapped in the EKS cluster’s aws-auth ConfigMap:

kubectl edit configmap aws-auth -n kube-system

Add your role:

mapRoles: |
  - rolearn: arn:aws:iam::123456789012:role/AWSReservedSSO_AdministratorAccess_1234567890abcdef
    username: admin:{{SessionName}}
    groups:
      - system:masters  

Problem: kubectl works but FreeLens doesn’t

Cause: Environment variables or PATH differences between terminal and FreeLens.

Solution:

1. Check AWS CLI path: which aws
2. Set AWS_PROFILE before launching FreeLens
3. Use the launch script provided earlier
4. Check FreeLens logs for specific errors:
   • macOS: ~/Library/Logs/FreeLens/
   • Linux: ~/.config/FreeLens/logs/
   • Windows: %APPDATA%\FreeLens\logs\

Step 9: Best Practices and Tips

1. Use Descriptive Context Names

When creating kubectl contexts, use descriptive names that include environment and region:

aws eks update-kubeconfig \
  --name my-cluster \
  --profile prod-account \
  --alias prod-us-east-1-my-cluster

2. Create Shell Aliases

Add convenient aliases to your shell configuration (~/.bashrc, ~/.zshrc):

# AWS SSO aliases
alias sso-login='aws sso login --sso-session my-company-sso'
alias sso-logout='rm -rf ~/.aws/sso/cache/*'

# kubectl context switching
alias kdev='kubectl config use-context dev-eks'
alias kprod='kubectl config use-context prod-eks'
alias kstaging='kubectl config use-context staging-eks'

# Combined: login and verify
alias aws-dev='aws sso login --sso-session my-company-sso && kubectl config use-context dev-eks && kubectl get nodes'

3. Set Up Login Reminders

Since AWS SSO tokens typically expire after 8 hours and require browser-based authentication, you can set up reminders to re-login:

macOS/Linux (add to crontab for notifications):

# Send notification reminder every 6 hours during work hours
0 8-18/6 * * * /usr/bin/osascript -e 'display notification "AWS SSO token may need refresh" with title "AWS SSO"'

Or use a shell function that checks token validity:

# Add to ~/.bashrc or ~/.zshrc
check_aws_sso() {
  if ! aws sts get-caller-identity --profile dev-account &>/dev/null; then
    echo "⚠️  AWS SSO credentials expired. Run: aws sso login --sso-session my-company-sso"
    return 1
  fi
  return 0
}

4. Use AWS Credential Process

For more advanced scenarios, you can use credential_process in your AWS config:

[profile dev-account]
credential_process = /usr/local/bin/aws-sso-credential-process --profile dev-account
region = us-west-2

This requires additional setup but provides automatic token refresh.

5. Document Your Setup

Create a README in your team’s documentation with:

• SSO start URL
• Account IDs and their purposes
• Cluster names and regions
• Required IAM permissions
• Common troubleshooting steps

6. Security Considerations

• Never commit AWS credentials to source control
• Use IAM roles with least-privilege permissions
• Enable MFA for AWS SSO
• Regularly rotate SSO session tokens
• Use separate AWS accounts for dev/staging/prod
• Audit EKS cluster access regularly:

  kubectl get configmap aws-auth -n kube-system -o yaml
  

Step 10: Advanced Configuration

Using Different Roles Per Cluster

If you need to use different IAM roles for different clusters within the same account:

# Read-only access to prod cluster
[profile prod-readonly]
sso_session = my-company-sso
sso_account_id = 234567890123
sso_role_name = ReadOnlyAccess
region = us-east-1

# Full access to prod cluster (for emergencies)
[profile prod-admin]
sso_session = my-company-sso
sso_account_id = 234567890123
sso_role_name = AdministratorAccess
region = us-east-1

Then create separate contexts:

aws eks update-kubeconfig \
  --name prod-cluster \
  --profile prod-readonly \
  --alias prod-readonly

aws eks update-kubeconfig \
  --name prod-cluster \
  --profile prod-admin \
  --alias prod-admin

Cross-Account EKS Access

If you need to access EKS clusters in Account B from Account A:

# Base account
[profile account-a]
sso_session = my-company-sso
sso_account_id = 111111111111
sso_role_name = AdministratorAccess
region = us-west-2

# Cross-account role assumption
[profile account-b-via-a]
source_profile = account-a
role_arn = arn:aws:iam::222222222222:role/EKSAccessRole
region = us-east-1

Multiple SSO Portals

If your organization has multiple SSO portals (e.g., different regions or business units):

[sso-session us-sso]
sso_start_url = https://us-company.awsapps.com/start
sso_region = us-east-1

[sso-session eu-sso]
sso_start_url = https://eu-company.awsapps.com/start
sso_region = eu-west-1

[profile us-dev]
sso_session = us-sso
sso_account_id = 123456789012
sso_role_name = DeveloperAccess
region = us-west-2

[profile eu-dev]
sso_session = eu-sso
sso_account_id = 987654321098
sso_role_name = DeveloperAccess
region = eu-west-1

Complete Working Example

Here’s a complete, real-world setup for an organization with dev, staging, and prod environments across multiple AWS accounts:

AWS Config File (~/.aws/config):

# SSO Session
[sso-session my-company]
sso_start_url = https://mycompany.awsapps.com/start
sso_region = us-east-1
sso_registration_scopes = sso:account:access

# Development Account
[profile dev]
sso_session = my-company
sso_account_id = 111111111111
sso_role_name = AdministratorAccess
region = us-west-2
output = json

# Staging Account
[profile staging]
sso_session = my-company
sso_account_id = 222222222222
sso_role_name = PowerUserAccess
region = us-west-2
output = json

# Production Account (read-only default)
[profile prod]
sso_session = my-company
sso_account_id = 333333333333
sso_role_name = ReadOnlyAccess
region = us-east-1
output = json

# Production Account (admin access for emergencies)
[profile prod-admin]
sso_session = my-company
sso_account_id = 333333333333
sso_role_name = AdministratorAccess
region = us-east-1
output = json

Setup Script:

#!/bin/bash
set -euo pipefail

echo "=== AWS EKS Multi-Account Setup ==="

# Login to AWS SSO
echo "Step 1: Logging into AWS SSO..."
aws sso login --sso-session my-company

# Configure kubectl contexts
echo "Step 2: Configuring kubectl contexts..."

echo "  - Adding dev cluster..."
aws eks update-kubeconfig \
  --name dev-cluster-usw2 \
  --region us-west-2 \
  --profile dev \
  --alias dev

echo "  - Adding staging cluster..."
aws eks update-kubeconfig \
  --name staging-cluster-usw2 \
  --region us-west-2 \
  --profile staging \
  --alias staging

echo "  - Adding prod cluster (read-only)..."
aws eks update-kubeconfig \
  --name prod-cluster-use1 \
  --region us-east-1 \
  --profile prod \
  --alias prod-readonly

echo "  - Adding prod cluster (admin access)..."
aws eks update-kubeconfig \
  --name prod-cluster-use1 \
  --region us-east-1 \
  --profile prod-admin \
  --alias prod-admin

# Verify access
echo "Step 3: Verifying cluster access..."

for context in dev staging prod-readonly; do
  echo "  - Testing $context..."
  if kubectl --context="$context" get nodes &>/dev/null; then
    echo "    ✓ $context is accessible"
  else
    echo "    ✗ $context is not accessible"
  fi
done

echo ""
echo "=== Setup Complete ==="
echo ""
echo "Available contexts:"
kubectl config get-contexts

echo ""
echo "To switch contexts, use:"
echo "  kubectl config use-context <context-name>"
echo ""
echo "To use with FreeLens:"
echo "  1. Open FreeLens"
echo "  2. Go to File → Add Cluster"
echo "  3. Select contexts from kubeconfig"
echo ""

Daily Usage Script:

#!/bin/bash
# daily-eks-work.sh - Run this script at the start of your work day

set -e

SSO_SESSION="my-company"

# Check if SSO credentials are valid
echo "Checking AWS SSO credentials..."
if ! aws sts get-caller-identity --profile dev &>/dev/null; then
    echo "Refreshing AWS SSO login..."
    aws sso login --sso-session "$SSO_SESSION"
else
    echo "AWS SSO credentials are valid."
fi

# Verify all clusters are accessible
echo ""
echo "Verifying cluster access..."
for context in dev staging prod-readonly; do
    if kubectl --context="$context" cluster-info &>/dev/null; then
        node_count=$(kubectl --context="$context" get nodes --no-headers | wc -l)
        echo "  ✓ $context: $node_count nodes"
    else
        echo "  ✗ $context: Not accessible"
    fi
done

echo ""
echo "Ready to work! Current context:"
kubectl config current-context

echo ""
echo "Launch FreeLens? (y/n)"
read -r response
if [[ "$response" == "y" ]]; then
    echo "Launching FreeLens..."
    open /Applications/FreeLens.app
fi

Conclusion

Setting up AWS SSO with multiple EKS clusters and FreeLens requires careful configuration of AWS credentials, kubectl contexts, and FreeLens integration. The key points to remember:

1. AWS SSO Configuration: Use sso-session blocks for reusable SSO configurations and reference them in profile definitions
2. AWS Config File: Properly structure your ~/.aws/config with all necessary profiles and regions
3. kubectl Contexts: Use descriptive aliases when adding clusters to make switching between them easier
4. FreeLens Integration: Ensure AWS CLI is in PATH and consider using launch scripts for automatic credential refresh
5. Best Practices: Use separate profiles for different permission levels, document your setup, and implement security best practices

With this setup, you can seamlessly manage multiple Kubernetes clusters across different AWS accounts using FreeLens, all authenticated through AWS SSO.

Resources

• AWS CLI SSO Documentation
• EKS User Guide
• FreeLens Documentation
• kubectl Configuration
• AWS IAM Identity Center (SSO)
• Managing Users and Roles for EKS

Troubleshooting Checklist

When things go wrong, work through this checklist:

• AWS SSO credentials are valid: aws sts get-caller-identity --profile <profile>
• AWS CLI version is 2.x or higher: aws --version
• kubectl can access clusters: kubectl --context=<context> get nodes
• AWS CLI is in system PATH: which aws
• kubeconfig file is properly formatted: kubectl config view
• IAM role has EKS permissions in target account
• IAM role is in EKS aws-auth ConfigMap: kubectl get cm aws-auth -n kube-system -o yaml
• FreeLens can find AWS CLI
• Cluster certificate is valid (not expired)
• Network connectivity to EKS API endpoint: curl -I <eks-endpoint>

If all else fails, regenerate your kubeconfig and re-add clusters to FreeLens:

# Backup existing config
cp ~/.kube/config ~/.kube/config.backup

# Remove and re-add clusters
aws eks update-kubeconfig --name <cluster> --profile <profile> --alias <alias>