這篇也是紀錄 Amazon EKS 常見的 Q&A，在一開始用 Amazon EKS 的用戶建立好 Cluster 後常常都會遇到「You must be logged in to the server (Unauthorized)」 不知道如何用 kubectl 訪問 Amazon EKS，這篇簡單的紀錄一些方法。
在 AWS 官方文件有幾篇提到關於如何管理 Kubernetes Cluster authorization 可以先讀一下，在預設情況下建立 Amazon EKS 時會依照「當下」的 IAM user/role 自動 grant system:masters 權限給 Amazon EKS Cluster。
When you create an Amazon EKS cluster, the IAM entity user or role, such as a federated user that creates the cluster, is automatically granted system:masters permissions in the cluster’s RBAC configuration in the control plane.
所以當建立 & 訪問 Amazon EKS 使用的是相同的 IAM user/role 時不會遇到問題，如果要添加其他的 IAM users/roles 也擁有訪問權限必須設定 ConfigMap 的 aws-auth 來開通權限，所以意味著你要能訪問 Amazon EKS 有兩種方法
- 建立 EKS Cluster 使用的 IAM user/role
- ConfigMap
aws-auth 設定的 IAM users/roles
OK，問題來了。
如果沒有設定 ConfigMap aws-auth 又忘了當時建立 EKS Cluster 的 IAM user/role 該如何找回來？
This IAM entity does not appear in the ConfigMap, or any other visible configuration, so make sure to keep track of which IAM entity originally created the cluster. To
根據 AWS 文件提到建立 Amazon EKS Cluster 的 IAM 權限並不存在 ConfigMap 也無法從 Kubernetes 上查到，作者過去還在學習時就很常因為腦弱所以乾脆砍掉重建 Amazon EKS 花費了不少等待的時間。但事實上在建立 EKS Cluster 時所使用的 IAM user/role 是有紀錄在 CloudTrail 的，如果是在 90 天內可以在 CloudTrail Console 查到，之後的就必須將 CloudTrail 存到 Amazon S3 後再撈出來。
查詢 "Event name" = eks.amazonaws.com 以及 Event source = CreateCluster 就能撈到是誰執行這個 EKS API，也就是我們要的 IAM user/role ARN。
{
"eventVersion": "1.08",
"userIdentity": {
"arn": "arn ..."
}
}這時候又把 CloudTrail 的重要性拿出來講一次，在 AWS 上所有的 API 紀錄都會保存在 CloudTrail 甚至是 Amazon S3 Object 也都支援了，
