EKS コントロールプレーン

EKS のコントロールプレーンへのネットワークアクセス方法は、「パブリックエンドポイント経由」と「プライベートエンドポイント経由」の２種類存在します。パブリックエンドポイントを有効化しているクラスタについては、インターネットを経由して手元のラップトップなどローカル環境から EKS のコントロールプレーンへアクセスして、Kuberentes API を実行することができます。更に、パブリックエンドポイントでは接続できるクライアント IP アドレスを制限することが可能です（EC2 インスタンスにおけるセキュリティグループのイメージ）。したがって、例えば IP アドレスが固定されている環境などがあれば、その環境からのみ EKS クラスタの Kuberentes API を実行する、といった運用が可能になります。

POL で利用している EKS クラスタについてもパブリックエンドポイントを有効化して、更に接続可能なクライアント側の IP アドレスを必要な環境のみに制限しております。一方で、昨今のリモートワークの都合上、特定の環境からのみしか接続できないのは何かと不便でもあります。POL も昨年からフルリモートになっており、自分も毎日大阪からリモートワークをしています。

そこで、今回インターネットからの接続が制限されている EKS クラスタのコントロールプレーンのアクセス方法について調査してみたので、その内容を共有したいと思います。

AWS ドキュメントを漁る

AWS のドキュメント [1] では、インターネットからの接続が制限されている EKS クラスタのコントロールプレーンのアクセス方法について、下記３通りの方法が紹介されています。

・VPN or DirectConnect 経由
・EC2 踏み台ホスト
・Cloud9 を利用する

１つ目の「VPN or DirectConnect 経由」については POL ではそのような環境が整っていないため見送りました。また、２つ目の EC2 踏み台ホストについても、踏み台ホストの管理が少し面倒に感じたので見送りました。

最後に３つ目の「Cloud9 を利用する」方法について、POL では今までこちらの方法にて EKS クラスタの運用を実施してきました。Cloud9 は AWS が提供するブラウザ経由の IDE 環境で、Cloud9 の IP アドレスを Elastic IP で固定して EKS クラスタへの接続を Cloud9 の Elastic IP を許可すれば、Kuberentes クラスタの操作を実施することができます。また、Cloud9 環境は他のユーザーと共有することができるので、複数人での利用も可能です。Cloud9 での EKS クラスタ管理について詳細は、自分の過去の記事 [2] を参照いただければと思います。

しかし、「Cloud9 を利用する」方法については下記のようなデメリットも見えてきました。

・同じタイミングで別クラスタの操作を複数人で実施できない
・Lens (IDE) やその他便利ツールをローカル環境で利用したい

そこで、別の方法を模索します。

他社ドキュメントを漁る

EKS といえど、所詮はマネージド Kuberentes クラスタ、Azure や GCP などマネージド Kuberentes クラスタサービスを提供しているクラウドプロバイダーに良さそうなドキュメントがあるに違いない、ということで GCP のドキュメントを漁っていると、[3] のようなチュートリアルドキュメントをみつけることができました。

こちらのドキュメントでは、Kubernetes クラスタ上に privoxy というプロキシが稼働しているコンテナをデプロイし、privoxy 経由でプライベートなコントロールプレーンへのアクセスを実現しています。これを EKS 上でも利用できるように応用してみました。

上図は最終的に構築したシステムのアーキテクチャ図です。

まず、ターゲットなる EKS クラスタ上に privoxy が稼働する POD をデプロイしておきます。次に、クライアントは Systems Manager Session Manager 経由で EKS ノードに接続して、privoxy がリッスンしているポートをポートフォワードします。その後、クライアント上で HTTPS 接続をポートフォワードしているポートに流し込む (HTTPS_PROXY 環境変数などを利用する) ことで、ローカル PC からプライベートな EKS のコントロールプレーンにアクセスすることができます。

privoxy が稼働する POD のデプロイには工夫をしており、ClusterIP type の Service を紐付けておくのと、ClusterIP Service の IP アドレスと特定のホスト名を、EKS クラスタが存在する VPC 内のみで有効な Route53 プライベートホストゾーンに A レコードとして登録してあります。こうすることで、privoxy が稼働する POD の IP アドレスが変更されたり、POD 数をスケールアウトしても対応することができます。

apiVersion: v1
kind: Service
metadata:
 annotations:
   external-dns.alpha.kubernetes.io/hostname: privoxy.example.com
spec:
 ports:
 - port: 8118
   protocol: TCP
   targetPort: 8118
 selector:
   app: privoxy
 type: ClusterIP
---
apiVersion: apps/v1
kind: Deployment
spec:
 replicas: 1
 selector:
   matchLabels:
     app: privoxy
 template:
   metadata:
     labels:
       app: privoxy
   spec:
     containers:
     - image: privoxy.docker.example.com/privoxy:latese
       imagePullPolicy: IfNotPresent
       name: privoxy
       ports:
       - containerPort: 8118

また、Systems Manager Session Manager 経由でのポートフォワードについては Go 製の社内ツールを用意しているため、そのツールを利用することで設定や AWS CLI などを詳しくない方でも利用することができるようになっています。更に、Systems Manager Session Manager に接続できない限り、つまり、AWS 上の認証情報を保有していないユーザーは EKS クラスタのコントロールプレーンへ接続することができません。POL では Google Workspaces の認証情報を元に職能別に AWS の認証情報を管理しているため、エンジニアのみ EKS クラスタへアクセスできないようになっています [4]。

まとめ

privoxy と Systems Manager Session Manager をうまく組み合わせることでプライベートな EKS のコントロールプレーンにローカル環境からアクセスすることができました。

今回の取り組みについてや POL でのインフラに関することなど、興味ありましたら Meety を始めたのでお気軽に申し込んでください！

その他インフラに関することについて何でもお話したいです〜

参考資料

[1] Amazon EKS cluster endpoint access control - Amazon EKS
https://docs.aws.amazon.com/eks/latest/userguide/cluster-endpoint.html#private-access

[2] Elastic Beanstalk から EKS へ移行した話 (1/3) ~移行概要 & EKS クラスタ作成編 ~｜Takahiro Yamada｜note
https://note.com/tyrwzl/n/n14703cfca236#CLv5P

[3] コントローラ アクセス用のネットワーク プロキシを持つ GKE 限定公開クラスタの作成  |  Cloud アーキテクチャ センター
https://cloud.google.com/architecture/creating-kubernetes-engine-private-clusters-with-net-proxies

[4] AWS SSO を利用した AWS 認証情報｜Takahiro Yamada｜note
https://note.com/tyrwzl/n/nb8ec58449502