こんにちは！インフラやセキュリティの世界へようこそ。
初めてKubernetes（K8s）やクラウドのセキュリティに触れるとき、次から次へと出てくる専門用語に「うっ……」と頭が痛くなってしまいますよね。でも、安心してください。一歩ずつ、身近な例えから紐解いていけば、誰でもしっかりと理解できるようになりますよ。
今回は、Kubernetesの心臓部である「Kubernetes API Server」の守り方について、お話ししていきますね。
—
1. Kubernetes API Serverって、たとえるなら「お家の玄関」なんです
みなさん、ご自身の「お家」を思い浮かべてみてください。
お家のなかには、大切な通帳や印鑑、家族のプライベートな情報がたくさん詰まっていますよね。泥棒からそれらを守るために、私たちはどうしているでしょうか？
1. 頑丈な鍵（認証）をつける：合鍵やピッキングに強い鍵を使い、「そもそもあなた誰ですか？」と本人確認をします。
2. 入っていい部屋を制限する（認可）：家族であっても、小さな子どもには金庫の鍵を渡さず、入れる部屋を制限しますよね。
3. そもそも怪しい人を家に入れない（IP制限）：近所の信頼できるエリアや、自分のスマホからしか開けられないスマートロックにしたりします。
Kubernetesの世界でも全く同じことが言えます。
Kubernetesの司令塔であるAPI Serverは、いわば「インフラ全体のマスターキーが保管されている巨大な金庫の扉」です。ここへのアクセスが野ざらしになっていたら……想像するだけで冷や汗が出てきますよね。
だからこそ、API Serverへのアクセスは「誰が、どこから、どんな権限で来ているか」をガチガチに固める必要があるのです。
—
2. 攻撃者はどうやってAPI Serverを狙ってくるの？
「うちのクラスターは社内からしか見えないから大丈夫！」
……本当にそうでしょうか？ 実は、サイバー攻撃者は非常に巧妙です。
よくあるインシデントのパターンとして、次のようなものがあります。
- 開発者のPCがマルウェアに感染し、PC内に保存されていたKubernetesのアクセス設定ファイル（
~/.kube/config）が盗み出される。 - クラウド環境のセキュリティ設定のミスで、API Serverが世界中に公開（パブリックIPが露出）されており、ボットネットが総当たり攻撃を仕掛けてくる。
もしAPI Serverの「玄関の鍵」が甘かったり、誰でも入れる状態になっていたら、攻撃者は一瞬でクラスターの管理者権限を奪い、勝手に仮想通貨のマイニング用コンテナを大量に立ち上げたり、社内の機密データを盗み出したりしてしまいます。
これを防ぐための具体的な防衛策を、一緒に見ていきましょう！
—
3. 防衛策①：ネットワークの関所を作る（IP制限）
まずは、「そもそも怪しい場所からのアクセスをシャットアウトする」というネットワークの防御です。
KubernetesのAPI Serverに対して、信頼できるオフィスのIPアドレスや、特定の踏み台サーバーからしか通信できないようにファイアウォール（クラウドならSecurity Groupなど）を設定します。
たとえるなら、「ご近所さんや特定のルートを通る人以外は、家の前を歩くことすらできないように門を閉ざす」ようなイメージですね。
クラウド環境（AWSのEKSなど）でAPI Serverのエンドポイントを公開・非公開に設定する際のイメージは、以下のようになります。
# 【参考】クラウド上のKubernetes（EKSなど）におけるアクセス制御の考え方
# 実際の設定はクラウドプロバイダーのコンソールやTerraform等で行います。
apiVersion: v1
kind: Config
# 攻撃者が勝手に外部からAPI Server（玄関）に近づけないよう、
# パブリックアクセスを完全に遮断し、プライベートネットワークからのみアクセスを許可します。
clusters:
- cluster:
server: https://<あなたのプライベートAPI-ServerのIP>:6443
# 信頼された証明書を設定し、偽物のサーバー（中間者攻撃）を防ぎます
certificate-authority-data: "LS0tLS1CRUdJTi..."
name: secure-cluster—
4. 防衛策②：RBAC（Role-Based Access Control）で「できること」を縛る
無事に玄関を通って中に入ってきた人（あるいはシステム）がいたとします。でも、その人に「家中のすべての部屋の鍵」を渡してしまうのは危険ですよね。
そこで登場するのが、KubernetesのRBAC（ロールベースアクセス制御）です。
「この人はログを見るだけ（Read-only）」、「あのシステムは特定のコンテナをデプロイするだけ」というように、役割（Role）ごとに権限を細かく割り当てます。
実際に、特定の名前空間（Namespace）のポッドを読むことしかできない「一般開発者用の安全な権限設定」をYAMLで書いてみましょう。
# 1. 権限の中身（ロール）を定義する
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
namespace: development # 権限を適用するお部屋（名前空間）を指定
name: pod-reader # ロール名（ポッドを読む人）
rules:
- apiGroups: [""]
resources: ["pods"] # ポッドというリソースに対して
verbs: ["get", "watch", "list"] # 「見る・監視する・一覧を出す」という操作だけ許可（書き込みや削除はできない！）
---
# 2. 誰にそのロールを渡すのかを紐付ける（ロールバインディング）
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: read-pods-global
namespace: development
subjects:
- kind: User
name: "yamada-san" # 山田さんというユーザーに対して
apiGroup: rbac.authorization.k8s.io
roleRef:
kind: Role
name: pod-reader # 先ほど定義した「pod-reader」の権限を付与する
apiGroup: rbac.authorization.k8s.ioこのように、verbs（動詞）の部分で create や delete を除外し、get や list だけに絞ることで、万が一山田さんのアカウントが乗っ取られたとしても、クラスター全体が破壊される最悪の事態を防ぐことができます。これが「最小権限の原則」です。
—
5. まとめ：一歩ずつ、堅牢なクラスターへ
今回は、Kubernetes API Serverのアクセス制限と認証・認可の基本について、お家の防犯にたとえながら解説しました。
- IP制限で、そもそも怪しい場所からの侵入を防ぐ
- 認証・認可（RBAC）で、本人確認を徹底し、最小限の権限だけを渡す
セキュリティ対策と聞くと「なんだか難しそう、面倒くさそう」と感じてしまうかもしれませんが、一つひとつの設定は「誰が・どこから・何をしていいか」というシンプルなルール決めの積み重ねです。
まずはご自身の開発環境やステージング環境の kubectl get clusterrolebindings などのコマンドを叩いて、「誰がどんな権限を持っているか」を眺めるところから始めてみませんか？
一歩ずつ、安全で強いインフラを作っていきましょう！
コメント