aws-google-authとdirenvを使ってEKSのクラスタ切り替えを安全に行う

EKS

f:id:cloudfish:20200116173700p:plain:w300

みなさんEKSクラスタの切り替えはどうしてますか？kubectxを利用されている方は多いのではないでしょうか？
kubectxは切り替えは非常に便利なのですが、逆に便利すぎてクラスタの選択を誤って冷や汗をかいたということはないでしょうか。
私自身は10程度のEKSクラスタを扱っていますが、あえて利便性を落として自分がミスしにくいと思う方法で切り替えを行っています。
今回はこのEKSクラスタを安全に切り替える方法について紹介したいと思います。

前提条件

aws.amazon.com

  • aws-google-authがインストールされていること

github.com

検証していませんが、saml2awsでも同じことができると思います。

設定方法

aws-google-authやdirenvの設定方法についてはここでは触れませんので別途調べてみてください。

プロジェクトごとにディレクトリを構成する

- clusterが複数ある場合はプロジェクトのディレクト配下に配置
- clusterのディレクトリにkubeconfigを配置

ProjectA
 ├── cluster_1
 |     ├── .envrc   #direnv用設定
 |     └── .kube    #kubeconfig
 └── cluster_2
 |     ├── .envrc
 |     └── .kube
ProjectB
 └── cluster_1
 |     ├── .envrc
 |     └── .kube
 :
  • kubeconfigの配置

以下のコマンドで直下にkubeconfigを配置できます

aws eks --region ap-northeast-1 update-kubeconfig --name cluster_1 --kubeconfig=.kube/config
  • direnvを設定

- clusterのディレクトリ直下に以下の内容で.envrcを作成する

export KUBECONFIG=$(pwd)/.kube/config
export AWS_PROFILE=test_admin
#zshの場合は以下の設定で右側にawsのprofile名とクラスタ名が表示されます
CLUSTER_NAME=$(grep "cluster: arn:aws:eks" .kube/config |awk -F"/" '{print $2}')
export RPROMPT="%F{154}$AWS_PROFILE:$CLUSTER_NAME%f"

AWS_PROFILE名はaws-google-authのログイン時に設定しdirenvで設定した名称と同一にする。

aws-google-auth -u hoge@gmail.com -I GOOGLE_IDP_ID -S GOOGLE_SP_ID -D -d 3600 -r arn:aws:iam::123456789012:role/test_admin -p test_admin -R ap-northeast-1

動作確認

cluster_1のディレクトリにcdすると以下のようにAWS_PROFILEとKUBECONFIGが環境変数に設定されます。

$cd cluster_a
direnv: loading .envrc
direnv: export +AWS_PROFILE +KUBECONFIG +RPROMPT
$                                                     test_admin:cluster_1

この後、aws-google-authで該当のAWSアカウントにログインすると、kubectlコマンドが利用できるようになります。

$kubectl get node                               test_admin:cluster_1
NAME                                               STATUS   ROLES    AGE   VERSION
ip-10-10-137-223.ap-northeast-1.compute.internal   Ready    <none>   58d   v1.14.7-eks-1861c5
ip-10-10-148-4.ap-northeast-1.compute.internal     Ready    <none>   58d   v1.14.7-eks-1861c5

仕組み

クラスタ毎にディレクトリを作成してその直下にkubeconfigを配置し、direnvでkubeconfigの切り替えを行います。また、aws-google-authを使いログインするとクラスタにアクセスできるようになります。　
　こうすることで該当のクラスタのディレクトリにcdすることでクラスタの切り替えを行いつつ、aws-google-authを利用して不用意にクラスタにアクセスできないようにしています。また、AWSのプロファイル名をdirenvの環境変数と同一にしておくことによって、セッションが残っていたとしてもディレクトリを抜けることによってプロファイルが参照されなくなるので思わぬミスが減らせます。

ディレクトリを抜けてkubectlコマンドを実行した場合、以下のようなエラーになります。

$kubectl get node
The connection to the server kubernetes.docker.internal:6443 was refused - did you specify the right host or port?

メリット、デメリット

メリット

デメリット

  • kubectxに比べてクラスタの切り替えが手間となる。
  • 初期設定に少し手間がかかる。

まとめ

　いかがでしょうか？利便性は少し落ちますが、それよりも安全性に重点を置いた仕組みにしました。このあたりはどの方法を選択してもトレードオフになるのではないかと思います。
　この方法で落ち着いてからは、今のところ冷や汗をかいたような場面には遭遇していませんが、もっといい方法がないかというのも模索していますので、もし他にもいい方法があれば是非教えてください。