こんにちは！インフラやセキュリティの世界へようこそ。
新しいシステムの構築やクラウドの管理、毎日本当にお疲れ様です！
さて、皆さんは今、飛ぶ鳥を落そろいの勢いで普及している「Kubernetes（クーベネティクス）」、通称K8s（ケーツーエス）に触れているところでしょうか？ コンテナを束ねて管理するこの仕組みは本当に便利ですが、便利であるがゆえに「設定の隙を突かれると、一瞬でシステム全体が乗っ取り屋の手に落ちる」という怖さも持っています。
今日は、そのKubernetesの心臓部である「APIサーバー」を守るための、とっても大切なお話をします。
難しそうに聞こえるかもしれませんが、身近な「お家の防犯」に例えて一歩ずつ紐解いていきますので、安心してついてきてくださいね！
—
1. 泥棒を招き入れる「合鍵なしの玄関」：匿名認証の恐怖
まずは、私たちが直面しているリスクを、お家の防犯に例えて考えてみましょう。
皆さんの大切なお家（＝Kubernetesクラスター）には、たくさんの貴重品（＝データやアプリケーション）が詰まっています。そのお家の玄関の鍵、どうなっていますか？
もし、「鍵をかけ忘れていて、名前すら名乗らない怪しい人が、誰でも自由にリビングまで入れる状態」だったら……想像するだけでゾッとしますよね。
Kubernetesの世界でも、これと全く同じことが起きる設定があるんです。それが、今回のお題である「匿名認証（Anonymous Authentication）」です。
Kubernetesの司令塔である「APIサーバー」は、デフォルトの状態だと、たまに「私、誰だか分からないんですけど、中に入ってもいいですか？」という名前すら名乗らない訪問者（匿名ユーザー）からのアクセスを許可してしまうことがあります。
「いやいや、そんな変な人が来るわけないよ」と思いますよね？
でも、インターネットの世界は広いです。悪意を持ったハッカーたちが、自動プログラム（ボット）を使って、世界中のサーバーの「鍵のかかっていない玄関」を24時間休まず探し回っています。ここで匿名認証を有効にしたままにしていると、泥棒に「どうぞお入りください」と赤じゅうたんを敷いて迎えているようなものなんです。
だからこそ、最初の要塞化ステップとして、「名無しの権兵衛（匿名アクセス）は一切お断り！」と設定することが絶対に必要なのですね。
—
2. 匿名アクセスをビシッと禁止する！ APIサーバーの設定
それでは、具体的にどうやってその「開けっ放しの玄関」に鍵をかけるのかを見ていきましょう。
KubernetesのAPIサーバーを起動するとき（または設定ファイルを編集するとき）、オプションで匿名認証をオフにする設定を記述します。
実際のKubernetesのマニフェストファイル（設定の設計図のようなものです）を見てみましょう。
apiVersion: v1
kind: Pod
metadata:
name: kube-apiserver
namespace: kube-system
spec:
containers:
- name: kube-apiserver
image: k8s.gcr.io/kube-apiserver:v28.0.0
command:
- kube-apiserver
# ここから下が、APIサーバーのセキュリティを引き締める重要な設定です！
- --anonymous-auth=false # 【超重要】「名前を名乗らない怪しいアクセスは一切拒否する」という設定です！
- --client-ca-file=/etc/kubernetes/pki/ca.crt
# （その他の設定は省略）この --anonymous-auth=false という一文を書き加えるだけで、APIサーバーは「お前は誰だ？ 身分証を見せろ！」と跳ね返してくれるようになります。まずはこの第一歩を確実にクリアしましょう！
—
3. 「身分証のチェック」を外部にお任せする：認証プロキシの仕組み
さて、匿名アクセスを禁止したのは良いものの、今度は「ちゃんと身分を証明できる正当な開発者やアプリ」を通す仕組みを作らなければなりません。
ここで登場するのが、今回のテーマのもう一つの主役「認証プロキシ（Authentication Proxy）」や「OIDC（OpenID Connect）」といった外部の認証の仕組みです。
これをまたお家の例えに戻してみましょう。
先ほどは「玄関の鍵を閉めました」。でも、家族が増えたり、信頼できる業者さんが来たりするたびに、お家のドアの鍵を何個も付け替えるのは大変ですよね。
そこで、「頑丈な門番（認証プロキシ）を家の手前に一人置くことにしよう！」と考えました。
1. 訪問者が来ると、まず門番が「あなたの身分証（社員証やGoogleアカウントなど）を見せてください」とチェックします。
2. 門番が「よし、この人は社内の〇〇さんだな」と確認したら、お家の玄関（APIサーバー）に向けて、「この人は〇〇さんなので通してあげてね」という特別な通行手形（ヘッダー情報）を添えてバトンタッチします。
3. APIサーバーは、その手形を信用して中に入れます。
このように、複雑な「本人確認（あの人が本当に本人か？）」の作業を、APIサーバー自身にやらせるのではなく、手前のプロキシ（門番）に肩代わりしてもらうのが「外部認証プロキシの構成」なんです。これにより、会社の共通ログイン基幹などと連携でき、セキュリティが劇的に向上します。
—
4. 認証プロキシを使うときの設定例
実際にKubernetesのAPIサーバー側で、「手前にあるプロキシ（門番）から送られてきた『この人は〇〇さんだよ』という情報（ヘッダー）を信用する」という設定をしてみましょう。
APIサーバーの設定ファイルに、以下のようなパラメータを追加します。
apiVersion: v1
kind: Pod
metadata:
name: kube-apiserver
namespace: kube-system
spec:
containers:
- name: kube-apiserver
image: k8s.gcr.io/kube-apiserver:v28.0.0
command:
- kube-apiserver
- --anonymous-auth=false # 匿名アクセスは相変わらず禁止！
# --- ここから下が認証プロキシ連携の設定です ---
# プロキシが「このユーザーだよ」と教えてくれるときに使うHTTPヘッダーの名前を指定します
- --requestheader-username-headers=X-Remote-User
# プロキシが「このユーザーの所属グループだよ」と教えてくれるヘッダーを指定します
- --requestheader-group-headers=X-Remote-Group
# プロキシがやり取りする際に使っていいよと許可する、信頼されたクライアント証明書のCAを指定します
- --requestheader-client-ca-file=/etc/kubernetes/pki/front-proxy-ca.crt
# どのヘッダーのプレフィックス（接頭辞）を信用するかを指定します
- --requestheader-allowed-names=front-proxy-client少し見慣れない英単語が並んでいて難しく感じるかもしれませんが、要するに、「手前の信頼できる門番（front-proxy-client）が、『X-Remote-User』という手紙に書いて渡してきたユーザー名だけは信用してあげる」というお約束を結んでいるだけなんです。
現場のインフラ担当としては、この「誰の言うことなら信用していいか（CAの証明書や許可する名前）」を厳しくカチッと決めることが、突破されない要塞を作る最大のコツになります。
—
まとめ：一歩ずつ、堅実なセキュリティをあなたのシステムへ
今回は、Kubernetes APIサーバーの「匿名認証の無効化」と「認証プロキシによる安全なアクセスの仕組み」についてお話ししました。
- 匿名認証はオフにする（名無しの訪問者は入れない！）
- 本人確認は信頼できるプロキシ（門番）にお任せする
- 設定ファイルできちんと「誰の情報を信用するか」を定義する
セキュリティの対策と聞くと、「なんだか難しくて失敗したらどうしよう…」と及び腰になってしまうかもしれません。でも、一つひとつの設定が「お家の防犯のどこにあたるのかな？」とイメージできれば、怖がる必要はまったくありません。
焦らず、一歩ずつ、あなたのシステムを安全で強固なものに育て上げていきましょう。
それでは、今日のインフラ構築もご安全に！
コメント