【入門編】 Kubernetes APIサーバーの公開と匿名認証の無効化 – オフェンシブセキュリティ & リバースエンジニアリング防御ガイド

こんにちは！インフラや開発の現場に飛び込んだばかりの頃は、覚えることがたくさんあって大変ですよね。「Kubernetes（K8s）」なんて名前を聞くだけで、なんだか難しそうな要塞を思い浮かべてしまうかもしれません。

でも、安心してください。今日は、Kubernetesの心臓部である「APIサーバー」がインターネットという広大な世界にポツンと露出してしまったとき、一体どんな危険が潜んでいるのか、そしてどうやってそれをガッチリ守ればいいのかを、身近な防犯にたとえて一歩ずつ優しく解説していきますね。

一緒に「破られないお城」の作り方を学んでいきましょう！

—

1. 家の鍵をかけ忘れたまま旅行に出かけるようなもの？APIサーバーの露出リスク

まずは、想像してみてください。あなたは今、新しく買ったとても便利な「全自動おうち管理システム」を自宅に設置しました。このシステムは、スマホからエアコンをつけたり、お風呂を沸かしたりできる超優れものです。

しかし、設定をちょっとミスしてしまい、そのシステムのリモコン（操作パネル）を世界中の誰もが見られる道路の真ん中に掲示板として置いてしまったとしたら……？

想像しただけでゾッとしますよね。「誰でも自由におうちの鍵を開けられます」「勝手に入って家電をいじってもいいですよ」と、世界中に宣言しているようなものです。

Kubernetesの世界における「APIサーバー」は、まさにこのおうち管理システムのリモコンそのものです。
クラスター全体（おうち全体）の命令をすべて受け付ける超重要パーツなのですが、これが設定ミスによってインターネット（道路の真ん中）に裸のままで晒されてしまうことがあるんです。

匿名認証（Anonymous Authentication）という「誰でもウェルカム」な罠

ここでさらに厄介なのが「匿名認証（Anonymous Authentication）」という機能です。
Kubernetesは、デフォルトのままだと「おっと、名前や身分証（パスワードやトークン）を持っていない人でも、とりあえず中に入れてあげようか」という優しい（すぎる）設定になっている場合があります。

これが有効なままAPIサーバーがインターネットに露出していると、攻撃者（泥棒）は身分証すら偽造する必要なく、正面から堂々とあなたのクラスターの門を叩いてこう言います。

> 「こんにちは！通りすがりの者ですが、このクラスターの管理者権限を全部いただけますか？」

そして、APIサーバーは「あ、身分証はないけど、まあいっか！」と、やすやすと鍵を渡してしまうのです。これが、世の中で最も恐れられているクラウドの誤設定インシデントのメカニズムです。

—

2. 攻撃者はどうやってあなたのAPIサーバーを見つけ出すのか？

泥棒は、闇雲に街を歩き回って鍵の開いた家を探すわけではありません。もっとスマートで残酷な方法を使っています。

彼らは、インターネット全体を高速でスキャンする専用の検索エンジン（例えば、有名なところだと Shodan や Censys などがあります）を使います。
「KubernetesのAPIサーバー特有の返答を返すIPアドレスはないかな？」と、ほんの数秒で世界中を探し回るのです。

もし、あなたの会社のテスト環境や個人プロジェクトのKubernetesが、うっかりパブリックIP（インターネット側から直接アクセスできるアドレス）に紐づいていて、ポート 6443（Kubernetes APIサーバーのデフォルトの扉）を開けっ放しにしていたら……。

検索エンジンは瞬時にそれを見つけ出し、攻撃者のボット（自動プログラム）に通知します。
通知を受けたボットは、先ほどの「匿名認証」を使って、あなたの大切なサーバーに侵入し、勝手に怪しいコンテナ（仮想サーバー）を立ち上げて「マイニング（暗号資産の不正採掘）」を始めたり、社内の機密データを盗み出したりしてしまうのです。

「まだ作りかけのテスト環境だから大丈夫だよ」と思っていても、インターネットの海では、見つかるまでに数分もかかりません。本当の本当に怖いことですよね。

—

3. 防犯の基本！「匿名認証の無効化」と「正しい身分証の確認」

さて、ここからが本番です。この恐ろしいリスクを防ぐために、私たちが最初に行うべき対策を学びましょう。やることはとってもシンプルです。

1. 「名無しの権兵衛（匿名ユーザー）」の入室を完全に禁止する
2. 正当な身分証（証明書やトークン）を持った人だけを通すようにする

APIサーバーの設定を変更してみよう

KubernetesのAPIサーバーを起動・管理している設定ファイル（一般的にはマニフェストファイル、あるいはマネージドサービスの場合はコンソール画面）で、匿名認証を明示的にオフにします。

APIサーバーの起動オプション（フラグ）に、以下の一行を追加（または変更）してください。

# Kubernetes APIサーバーの設定例（マニフェストの一部）
spec:
  containers:
  - name: kube-apiserver
    image: k8s.gcr.io/kube-apiserver:v1.28.0
    command:
    - kube-apiserver
    # ▼ ここがポイント！匿名認証を「false（無効）」に設定します
    - --anonymous-auth=false
    - --authorization-mode=Node,RBAC
    # その他の設定が続きます...

【ここがポイント！】

--anonymous-auth=false: 「名乗らないやつは、たとえ皇帝であっても門前払いにする！」という強力なセキュリティの門番を設定しています。これだけで、身分証なしの怪しいアクセスはすべて「401 Unauthorized（認証エラー）」ではじき返されるようになります。
--authorization-mode=Node,RBAC: 「中に入れたとしても、その人が何をしていい人なのか（権限）」を厳しくチェックする仕組み（RBAC: ロールベースアクセス制御）を有効にしています。

もしあなたがAWSのEKS、Google CloudのGKE、AzureのAKSといった「マネージドKubernetesサービス」を使っている場合は、コンソールの「エンドポイントのアクセス設定」から「パブリックアクセスを無効化（プライベートクラスターにする）」、もしくは「アクセスできるIPアドレスを自社のオフィスやVPNだけに限定する」という設定がポチポチっと数クリックで可能です。ぜひ確認してみてくださいね！

—

4. ネットワークの要塞化：そもそもインターネットにさらさない

APIサーバーの認証を固めるのは大前提ですが、セキュリティの鉄則は「多層防御（タレイソウボウギョ）」です。つまり、鍵を頑丈にするだけでなく、「そもそも泥棒が家の近くまで来られないようにする」ことも大切です。

家で言えば、頑丈な門を建てて、部外者が敷地に入れないようにすることですね。これをネットワークの世界では、プライベートエンドポイントの利用やネットワークポリシー（NetworkPolicy）、ファイアウォール（セキュリティグループ）による制限と呼びます。

現場で使えるファイアウォール設定の考え方

もし、どうしても開発者の自宅や外部からAPIサーバーにアクセスする必要がある場合は、誰彼構わず通すのではなく、「特定の信頼できるIPアドレス（会社や自宅の固定IP、踏み台サーバー等）からだけ通信を許可する」ように設定します。

クラウドのセキュリティグループやファイアウォールの設定イメージを見てみましょう。

{
  "GroupName": "k8s-api-server-security-group",
  "Description": "Kubernetes APIサーバーへのアクセス制御",
  "IpPermissions": [
    {
      "IpProtocol": "tcp",
      "FromPort": 6443,
      "ToPort": 6443,
      "IpRanges": [
        {
          "CidrIp": "203.0.113.50/32",
          "Description": "【安全】自社のオフィスネットワークからのアクセスのみを許可する"
        }
      ]
    }
  ],
  "IpPermissionsDenied": [
    {
      "IpProtocol": "tcp",
      "FromPort": 6443,
      "ToPort": 6443,
      "IpRanges": [
        {
          "CidrIp": "0.0.0.0/0",
          "Description": "【危険】インターネット全体からのアクセスは絶対に許可しない！"
        }
      ]
    }
  ]
}

このように、0.0.0.0/0（世界中のすべての場所）からのアクセスをスパッと遮断し、本当に許可された安全なIPアドレスからしかポート 6443 に触れないようにすることで、万が一Kubernetes側に別の脆弱性が見つかったとしても、被害を最小限に食い止めることができます。

—

5. おわりに：安全なインフラ作りは、一歩ずつの積み重ねから

今回は、KubernetesのAPIサーバーがインターネットに露出してしまうリスクと、その対策についてお話ししました。

APIサーバーはクラスターの心臓部。インターネットに裸で晒してはいけない！
「匿名認証」はデフォルトで有効な場合があるため、必ず --anonymous-auth=false で無効化する。
ファイアウォールやセキュリティグループを使って、信頼できる場所からしか通信できないように網を張る。

セキュリティの勉強を始めたばかりの頃は、「覚えることが多くて自分にできるかな…」と不安になるかもしれません。でも大丈夫です。現場のプロたちも、こうした小さな「うっかり設定ミス」を防ぐためのルールを一つひとつ丁寧に積み重ねて、強固なシステムを作り上げています。

今日学んだ知識を頭の片隅に置いて、ご自身の環境や会社のインフラ設定をぜひ一度見直してみてくださいね。「うちのサーバー、大丈夫かな？」と気付くこと自体が、最高に素晴らしいセキュリティの第一歩ですよ！

それでは、また次回の記事でお会いしましょう。一歩ずつ、安全で快適な開発ライフを楽しんでいきましょうね！