【入門編】 KubernetesのAdmission Controllerを用いたセキュリティ強制 – オフェンシブセキュリティ & リバースエンジニアリング防御ガイド

こんにちは!セキュリティの世界へようこそ。今日は、Kubernetes(K8s)という「巨大なマンション」を守るための、最強の門番についてお話しします。

インフラの構築に携わっていると、「コンテナをデプロイしたけれど、本当に安全な設定になっているのかな?」と不安になることはありませんか?実は、攻撃者の視点から見ると、デフォルト設定のKubernetesは「鍵が開けっぱなしの窓」だらけに見えているのです。

今回は、そんな窓を自動で閉め、ルール違反の持ち込みをビシッと断る「Admission Controller(アドミッション・コントローラー)」という仕組みを、OPA GatekeeperやKyvernoといった具体的な道具を交えて、優しく紐解いていきましょう。

—

1. Kubernetesの「門番」:Admission Controllerとは?

想像してみてください。あなたは、最新設備の整った超高級マンション(Kubernetesクラスター)のオーナーです。

住人(開発者)たちが「新しい家具(Pod)を運び込みたい!」と言ってきたとき、もしその家具の中に「爆弾(悪意のあるプログラム)」が入っていたり、「廊下を占拠するほど巨大な荷物(リソースの無駄遣い)」だったりしたら困りますよね。

ここで活躍するのがAdmission Controllerです。

1. 認証・認可: まず「あなたは住人ですか?」と身分証を確認します。
2. Admission Controller(ここが重要!): 次に「その家具は、マンションの規則(セキュリティポリシー)に違反していませんか?」と中身を厳重にチェックします。
3. 登録: チェックをパスして初めて、マンションの台帳(etcd)に登録され、部屋に運び込まれます。

つまり、「危ない設定のPodは、動く前に門前払いする」という、究極の水際対策なのです。

—

2. なぜ「門番」が必要なの?泥棒の狙う隙間

「そもそも、ちゃんとした設定でデプロイすればいいだけじゃないの?」と思われるかもしれません。しかし、攻撃者(レッドチーム)の視点はもっと執拗です。

例えば、こんな「泥棒のテクニック」があります。

  • 特権コンテナの悪用: 「修理業者です!」と嘘をついて、マンションの全ての部屋を開けられるマスターキー(特権)を持とうとします。
  • 怪しい荷物の搬入: 信頼できない業者(怪しい公開レジストリ)から届いた、中身のわからない箱を運び込もうとします。

これらを「人間が気をつける」だけで防ぐのは限界があります。だからこそ、「ルールに合わないものは物理的に中に入れない」という自動化された仕組みが必要なのです。

—

3. Kyverno:親しみやすい「マンションの管理人さん」

まずご紹介するのがKyverno(キベルノ)です。これは、Kubernetesに慣れている方なら馴染み深い「YAML」という形式でルールを書けるのが特徴です。まるで「マンションの掲示板にルールを貼る」ような感覚で設定できます。

【実践】特権コンテナを禁止するルール

「特権(privileged)コンテナ」は、泥棒にマスターキーを渡すようなものです。これを禁止するルールを書いてみましょう。

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: disallow-privileged-containers
spec:
  validationFailureAction: Enforce # 違反した場合はデプロイを「拒否」します
  background: true
  rules:
  - name: check-privileged
    match:
      any:
      - resources:
          kinds:
          - Pod
    validate:
      message: "特権コンテナは禁止されています!安全な設定に変更してくださいね。"
      pattern:
        spec:
          containers:
          - securityContext:
              # privilegedがtrueになっているPodは、門番が追い返します
              =(privileged): "false"

この設定を入れておくだけで、うっかり危ない設定でPodを作ろうとしても、「ダメですよ!」と優しく(そして厳格に)ブロックしてくれます。

—

4. OPA Gatekeeper:厳格な「プロのセキュリティガード」

次にご紹介するのは、OPA Gatekeeper(オーピーエー・ゲートキーパー)です。こちらは、より複雑で高度なルールを記述できる、プロ仕様の警備システムです。

Gatekeeperは「Rego(レゴ)」という専用の言語を使いますが、基本は「テンプレート(ルールの型)」と「制約(具体的な値)」の2段構えで考えます。

【実践】信頼できる場所からのみ荷物を受け取る

「どこの馬の骨ともしれない業者の荷物は受け取らない」というルールを作ってみましょう。つまり、許可されたレジストリ(例:自社のプライベートレジストリ)以外のイメージを禁止します。

# まずは「制約(Constraint)」を作ります
apiVersion: constraints.gatekeeper.sh/v1beta1
kind: K8sAllowedRepos
metadata:
  name: allow-only-my-registry
spec:
  match:
    kinds:
      - apiGroups: [""]
        kinds: ["Pod"]
  parameters:
    # ここに許可するレジストリのリストを書きます
    repos: ["my-company-registry.io/", "docker.io/library/"]

このように設定すると、例えば evil-hacker-repo.com/malicious-image といった怪しい場所からコンテナを持ってこようとしても、Gatekeeperが「その業者は出入り禁止です!」と止めてくれるわけです。

—

5. 攻撃を防ぐための「防御ヘッダー」的な考え方

Webサイトを守るために「セキュリティヘッダー」を付けるように、KubernetesでもPodの中に「防御設定」を義務付けることが大切です。

Admission Controllerを使えば、以下のような「安全のための決まり事」を強制できます。

  • ReadOnlyRootFilesystem: 「部屋の壁に落書き(ファイルの書き換え)をさせない」設定です。
  • RunAsNonRoot: 「子供(一般ユーザー)として行動し、大人(ルート権限)のふりをさせない」設定です。

これらが設定されていないPodをデプロイしようとしたら、門番が「ちょっと待ってください、安全対策を忘れていますよ」と教えてくれる。そんな環境が理想的ですね。

—

まとめ:一歩ずつ、安全なマンションを作ろう

Kubernetesのセキュリティは、最初は難しく感じるかもしれません。でも、Admission Controllerは決してあなたを困らせるためのものではなく、「うっかりミスからシステムとあなたを守るための、頼れるパートナー」なのです。

1. まずは Kyverno で、よくある危ない設定を禁止することから始めてみましょう。
2. 慣れてきたら Gatekeeper で、より細かい組織独自のルールを作ってみてください。

「泥棒が入ってから後悔する」のではなく、「最初から鍵をしっかりかける」。この積み重ねが、世界トップクラスの堅牢なインフラを作り上げます。

少しずつ、楽しみながらセキュリティを学んでいきましょう!もし分からないことがあれば、いつでもまた聞きに来てくださいね。

コメント

タイトルとURLをコピーしました