知らなきゃ危険！EKSに潜むプライベートクラスターの罠

2020-10-15

知らなきゃ危険！EKSに潜むプライベートクラスターの罠

記事をシェアする

[！] この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

昨今のソフトウェア開発プロセスは、仮想マシンではなくコンテナを用いることが前提になりつつあります。そこで私たちも、コンテナ技術に触れてみようと思い、手始めに社内で使用しているシステムの一部をコンテナ環境に移行しました。コンテナ環境には、クラスター運用を少しでも楽にするため、クラウドのマネージドKubernetesサービスであるAmazon EKSを採用しました。

当社ではクラウドをデータセンター拡張の用途で利用しており、AWSに構築した仮想ネットワークには以下の特徴があります。

VPN接続しているオンプレミスからのみアクセス可能
インターネットへのアクセスはプロキシ経由

しかし、このネットワークにEKSクラスターを構築するためには、単純にサービスのウィザード画面を操作するだけではだめでした。そこで、この記事ではインターネットへのアクセスがない、プライベートなEKSクラスターを構築する方法を紹介します。なお、AWSやKubernetesの基礎知識はすでにあるものとします。

EKSクラスターのシステム構成図

当社の仮想ネットワークにEKSクラスターを構築できた際の最終的な構成図は以下のようになりました。

一般的なEKSクラスターと比べると、VPC Endpointを追加する必要がありました。また、他にも追加で実施すべき項目や分かりづらい内容がありましたので、ここからは詳しく説明します。

クラスターが利用するアクセス権限の作成

初めに、EKSクラスターが他のAWSリソースを利用するためのIAMロールを作成する必要があります。設定するAWS管理ポリシーは以下の2つです。

AmazonEKSServicePolicy：EKSがKubernetesクラスターを作成、運用するためのポリシー
AmazonEKSClusterPolicy：KubernetesクラスターのコントロールプレーンがAWSリソースを操作するためのポリシー

クラスターを作成する仮想ネットワークの作成

EKSクラスターを作成する前に、クラスターで利用するVPCを作成しておく必要があります。しかし、このVPCには考慮するべき要件 ⧉があります。この記事の構成で考慮するべきなのは以下の4つです。

2つ以上のアベイラビリティゾーンにサブネットが必要
DNSホスト名とDNS解決がサポートされている必要がある
VPCエンドポイントが必要
プライベートサブネットへのタグ付けが必要

重要なのは3つ目です。アウトバウンドインターネットアクセスのないVPC上にEKSクラスターを作成するには、そのクラスターが利用するAWSサービスに、VPCエンドポイントを使ってプライベート接続する必要があります。具体的には、以下のエンドポイントを有効化します。

com.amazonaws.region.ec2
com.amazonaws.region.ecr.api
com.amazonaws.region.ecr.dkr
com.amazonaws.region.s3

セキュリティグループに関する注意事項

VPCやサブネット同様に、セキュリティグループもEKSクラスターを作成する際に指定する必要があります。EKSクラスター用のセキュリティーグループはワーカーノードを作成する際に変更されるため、EKSクラスターごとに専用のセキュリティグループを使用することが推奨されています。

EKSクラスターの作成

いよいよEKSクラスターの作成です。EKSでは、Kubernetes APIサーバーとの通信に使用するクラスターエンドポイントへのアクセスを制御できます。今回はEKSクラスターをインターネットに公開したくないので、インターネットからは到達せずVPC経由でのみ利用可能な「プライベートエンドポイント」を有効化します。これにより、エンドポイントへのトラフィックは、VPCまたは接続されたネットワーク内から送信する必要があります。

その後、コンテナを動作させるためのワーカーノード（EC2インスタンス）を作成します。コンソール画面上で簡単な操作を行うだけでワーカーノードを作成することも可能ですが、今回はAWSが提供しているワーカーノード用のCloudFormationテンプレートを利用し、以下のようにネットワーク環境に合わせて作成しました。

ワーカーノードがプロキシ経由でインターネットにアクセスできるように環境変数を設定
オンプレミスからのトラフィックを許可するようにセキュリティグループのルールを追加

また、ワーカーノードを作成する際に注意すべき点は、EC2のインスタンスタイプです。ワーカーノード上で作成されるポッドは、ワーカーノードに割り当てられているセカンダリIPを使用して作成されます。セカンダリIPの最大数はインスタンスタイプによって異なるので、セカンダリIPの不足でポッドを起動できないことがないように、適切なインスタンスタイプを選択することが重要となります。

クラスター設定ファイルの取得

kubeconfigファイルはAWS CLIを使用して入手できます。EKSクラスターが作成されると、クラスターを作成したIAMユーザーが、管理者（「system:master」アクセス許可が付与されている）としてKubernetes RBAC認証テーブルに追加されます。最初は、そのIAMユーザーだけがkubectlを使用してKubernetes APIサーバーを呼び出すことができます。そのため、AWS CLIのprofileには、作成を行ったIAMユーザーのアクセスキーとシークレットアクセスキーを使用する必要があります。

C:\>aws configure
AWS Access Key ID [None]: xxxxxxxxxxxxxxxx
AWS Secret Access Key [None]: xxxxxxxxxxxxxxxx
Default region name [None]: ap-northeast-1
Default output format [None]: json
 
C:\>aws eks update-kubeconfig --name eksCluster
Added new context arn:aws:eks:ap-northeast-1:xxxxxxxxxxxx:cluster/eksCluster to /root/.kube/config

これにより、kubectlコマンドでEKSクラスターへ接続が可能になります。動作確認としてkubectl get nodeを実行してみると、以下のような結果が出力されたので、正常にアクセスできていることがわかります。

C:\>kubectl get node
NAME                                              STATUS   ROLES    AGE     VERSION
ip-10-110-3-158.ap-northeast-1.compute.internal   Ready    <none>   3m13s   v1.16.8-eks-e16311
ip-10-110-4-94.ap-northeast-1.compute.internal    Ready    <none>   3m14s   v1.16.8-eks-e16311

まとめ

今回はインターネットへのアクセスが存在しない、完全にプライベートなKuberntesサービスを構築する方法を紹介しました。これによって、外部からの不正なアクセスがなくなり、セキュリティを向上させることができます。コンテナの利用が拡大するにつれて、ワーカーノードに作成できるポッド数の制限が今後の懸念材料となりそうですが、AWSにて制限を緩和する変更を準備中のようなので、それに期待しています。

また、他のクラウドもマネージドKubernetesサービスを提供しているので、当社により適したサービスがないか、色々と他も試してみたいと思います。

記事をシェアする