EKSハンズオンで社内アラートを二度鳴らした話
Amazon Elastic Kubernetes Service (EKS) の学習中に社内のセキュリティルールを破ってしまい、「これ、対応よろしく」とDMが...。
セキュリティアラートを1回と言わず2回も鳴らしてしまった新卒エンジニアが、原因を振り返ります。
レベルは低いですが、初心者こそやりがちな落とし穴なので、ぜひご参考に！
※この記事は生成AIを使わずに書きます。読みにくかったら🙏
結論：最低限守るべきEKS設定
✅ やること
- Worker Node は Private Subnet に配置し、NAT Gateway 経由で通信
- Control Plane には IP 制限を設定（Cloud9のEC2にアタッチしたElastic IPをCIDR
/32で許可）
❌ やらないこと
- Public Subnet に Worker Node を配置する（Public IPがついて直で外と通信できる）
- Control Plane のアクセス制限を全開（
0.0.0.0/0）にする（PublicAccess: trueだけでは危険）
何故アラートが鳴るの？ハンズオンでしょ？
結論を見ると、当たり前の話が書いてあります。私もそう思います。
ただ、あまり考えずに教材のコマンドをコピペしていて、罠にハマってしまった...。
取り組んだハンズオン
一回目のセキュリティアラート
二回目のセキュリティアラート
下の画像のように、どちらのハンズオンもCloud9のリソースを先に立て、ターミナルからクラスタを構築しました。そしてすぐ、セキュリティアラートが上司の元に届きました。
画像引用元：https://catalog.us-east-1.prod.workshops.aws/workshops/f5abb693-2d87-43b5-a439-77454f28e2e7/ja-JP/030-explore-cluster
🔔【第一回】 あれ、NodeにPublic IPついてる？
最初に取り組んだハンズオンはAWS公式が出している日本語のガイドです。非常にわかりやすかった。Cloud9の立ち上げから、フロントエンドとバックエンドのPodの作成方法まで丁寧に書かれています。
アラートがなった時
「2.1. eksctl と kubectl の導入」でeksctl と kubectlの導入が終わった後、「2.2. クラスターの作成」で、eksctlコマンドを実行しました。するとアラート発動🔥
AWS_REGION=$(aws configure get region)
eksctl create cluster \
--name=ekshandson \
--version 1.30 \
--nodes=3 --managed \
--region ${AWS_REGION} --zones ${AWS_REGION}a,${AWS_REGION}c
このコマンドは、指定したRegionに3台のNodeを持つEKSクラスターを作成するものですが、このNodeはPublic Subnetに配置されます。公式ドキュメントで確認してみましょう。
The default VPC CIDR used by eksctl is 192.168.0.0/16. It is divided into 8 (/19) subnets (3 private, 3 public & 2 reserved). The initial nodegroup is created in public subnets, with SSH access disabled unless --allow-ssh is specified. The nodegroup by default allows inbound traffic from the control plane security group on ports 1025 - 65535.
初期のノードグループはpublic subnetに配置されます。と書いてありますね。つまりEC2インスタンスに public IPが付与され、インターネットと直接通信できる状態になってします。
アラートをもらった後、この設定が明らかに問題であると、さすがの私も気づきました。また、原因の整理と実施記録の記載後、「もう同じミスはしまい！」と思っていました。次やるときは大丈夫だと思ってたんです。二度目のアラートが鳴るまでは。
🔔【第二回】 ちゃんと設定見たのに、また鳴るの！？
次に取り組んだのは英語のEKS Work Shopです。誰もが通る道らしい。あとSecurityのチャプターが難しいらしい。
アラートがなった時
「Setup」セクションはやらんでええか^^と「Using eksctl」の章に進みました。そして、今度こそちゃんとconfigurationを確認！managedNodeGroups.privateNetworking: trueになってたのでこれでいいと思ってました！
そして、ドヤ顔で実施記録に「同じミスはしないように〜〜」とか書き、eksctlコマンドを実行しました。するとアラート発動🔥
確認したconfiguration
apiVersion: eksctl.io/v1alpha5
kind: ClusterConfig
availabilityZones:
- ${AWS_REGION}a
- ${AWS_REGION}b
- ${AWS_REGION}c
metadata:
name: ${EKS_CLUSTER_NAME}
region: ${AWS_REGION}
version: "1.31"
tags:
karpenter.sh/discovery: ${EKS_CLUSTER_NAME}
created-by: eks-workshop-v2
env: ${EKS_CLUSTER_NAME}
iam:
withOIDC: true
vpc:
cidr: 10.42.0.0/16
clusterEndpoints:
privateAccess: true
publicAccess: true
remoteNetworkConfig:
remoteNodeNetworks:
- cidrs: ["10.52.0.0/16"]
remotePodNetworks:
- cidrs: ["10.53.0.0/16"]
addons:
- name: vpc-cni
version: 1.19.2
configurationValues: '{"env":{"ENABLE_PREFIX_DELEGATION":"true", "ENABLE_POD_ENI":"true", "POD_SECURITY_GROUP_ENFORCING_MODE":"standard"},"enableNetworkPolicy": "true", "nodeAgent": {"enablePolicyEventLogs": "true"}}'
resolveConflicts: overwrite
managedNodeGroups:
- name: default
desiredCapacity: 3
minSize: 3
maxSize: 6
instanceType: m5.large
privateNetworking: true
releaseVersion: "1.31.3-20250103"
updateConfig:
maxUnavailablePercentage: 50
labels:
workshop-default: "yes"
これ、よく見ると、clusterEndpoints: trueかつ、publicAccessCIDRsが未設定なんですよね。以下のドキュメントを参考にしてください。
つまり、control planeが0.0.0.0/0でインターネットと直接通信できる状態にしてしまったということです。
対処法
control planeのIPアドレス制限はEKS/クラスタの設定/VPCエンドポイントの設定で簡単に変更できます。NodeがおいてあるVPCやサブネットの設定を見ても何もわからないのがちょっと罠！
ただ、「対応よろしく」DMをいただいたとき、すぐに原因がわからず、パニックになってしまいました。
🌀余談：パニックになってやったこと
「さすがに同じミスは許されない！」とパニックになった私は、慌てて設定をいじりました。ネットワークの勉強からやり直した方がいい。
- NAT削除 →
kubectl get nodes落ちる（あたりまえ） - Public、IP っぽいものを片っ端から削除（何も置いてないPublic Subnetとか） → UIの色が変わってさらに焦る
- IP削除の流れでCloud9のElastic IPも削除 → セッション切れて詰む（さよならkubectl）
※上司のDMは優しかったです。
🏁おわりに
この記事では、教材通りにやってもセキュリティ上の穴が開いてしまった体験談を書きました。これからも公式ドキュメントを読み、コマンドの意味を考えながら進めていきたいものです。
私事ですが、同じようにk8s勉強中の方、よければXでつながりましょう〜！
Discussion