Questions

• 怎麼從 v19 migrate 到 v20？跟 karpenter 的關係是什麼？對應到 karpenter 需要的版本為何？
  • https://github.com/terraform-aws-modules/terraform-aws-eks/releases/tag/v20.0.0
  • Karpenter 被包在 eks module 裡面，版本會跟著 eks module version 走
• 如果不升版的影響是什麼？
  • AWS 表示 aws-auth ConfigMap 已被 deprecated
  • 在 access entry release 前建立的 cluster，設定 auth 的方式只能從 ConfigMap 改成 ConfigMap & API(access entry)，而 ConfigMap & API 只能改成 API，沒辦法退回 ConfigMap

Access Entry

使用原理

利用 AWS API 來修改 IAM principals (users/roles) 存取 EKS 的方式，舊的方法為直接修改 aws-auth ConfigMap

使用方式 on console

• 如果是在 access entry 釋出前建立的 cluster，預設會使用 ConfigMap 進行權限管理

  

• 切換成 access entry 之後，會從 ConfigMap 自動生成 access entry 的紀錄

  

• 建立 access entry 時，需要選擇要連接哪個 IAM principal

  

• 還有他應該要被貼上哪些 policies，以及存取的範圍（可選全 cluster / namespaces）

  

• Terraform 的設定方式：https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/eks_access_entry#import

為啥大家都說 aws-auth configmap 很爛

1. 手動編輯容易出錯，格式錯誤就有可能導致無法存取

2. 無法透過 AWS API 管理、權限管理不靈活

   因為存取範圍還是取決於 k8s RBAC，aws-auth ConfigMap 新增角色的步驟繁瑣：

   1. 建立 AWS IAM role new_role，決定 IAM policy（但不影響 EKS 內部權限）
   2. 修改 aws-auth ConfigMap，把 new_role 對應到 EKS 裡的 Role group new_dev
   3. 在 EKS 裡面宣告 Role 或 ClusterRole 來定義 new_dev 的權限

   如果使用 access entry，則可以統一在 entry 裡設定權限範圍 (cluster/namespace) 和動作 (access policy)；更新過的權限對應會紀錄在 control plane 上

3. 無法使用 CloudTrail 追蹤權限變更

Migrate from 19.x → 20.x

https://gitlab.kkinternal.com/going-cloud/sre/gc-host/-/merge_requests/31/diffs