見出し画像

kubelet の認証 (authentication)・認可 (authorization) 設定に関して

toshi

Kubernetes を運用する上で、kubelet の認証 (authentication) と認可 (authorization) の設定はとても重要です。これを適切に設定しないと、意図しないアクセスが許可されてしまったり、逆に必要なアクセスまで拒否されてしまったりすることがあります。

「kubelet の設定って難しそう…」と感じるかもしれませんが、ひとつひとつ見ていけば仕組みがつかめるはずです。この記事では、それぞれの設定項目が何を意味するのかを整理していきます。

1. 認証 (authentication) の設定

認証とは、「このリクエストは 誰からのものか？」を確認する仕組みです。kubelet では、匿名アクセス (anonymous)、Webhook 認証 (webhook)、クライアント証明書認証 (x509) など、複数の方法を組み合わせて設定できます。

(1) 匿名アクセス (anonymous)

anonymous:
  enabled: false

  • anonymous.enabled: false
    → 匿名ユーザーのリクエストを禁止 する設定。
    → これを true にすると、認証なしで kubelet にリクエストできるようになるため、セキュリティリスクが高まる。

🔍 イメージ
「家の玄関を開けっ放しにするか、鍵をかけるか」と考えるとわかりやすいです。匿名アクセスを true にすると、誰でも勝手に家に入れる状態になってしまいます。通常は false にしておくのが安全です。

(2) Webhook 認証 (webhook)

webhook:
  cacheTTL: 0s
  enabled: true

  • enabled: true
    → kubelet が Webhook 認証 を利用する。
    → kube-apiserver へ認証の問い合わせを行い、リクエストを許可するか判断する仕組み。

  • cacheTTL: 0s
    → 認証結果をキャッシュしない。
    → 毎回 kube-apiserver に問い合わせるため、最新の認証情報が適用されるが、負荷が増える。

🔍 イメージ
「毎回受付で身分証を確認するオフィス」を想像してください。キャッシュ (cacheTTL) を使うと、一度身分証を見せたらしばらくは通れるようになりますが、キャッシュなし (0s) にすると、毎回受付で確認される ような状態になります。セキュリティは強くなりますが、そのぶん手間が増えます。

(3) クライアント証明書認証 (x509)

x509:
  clientCAFile: /etc/kubernetes/pki/ca.crt

  • clientCAFile: /etc/kubernetes/pki/ca.crt
    → クライアント証明書を使った認証を有効にする。
    → kubelet にアクセスするクライアント (kubectl など) は、信頼できる証明書 を提示しなければならない。

🔍 イメージ
「社員証がないとオフィスに入れない会社」のような仕組みです。適切な証明書 (clientCAFile) を持っていれば入室でき、持っていない人は入れません。

2. 認可 (authorization) の設定

認可とは、「このユーザーが この操作を実行する権限を持っているか？」を判断する仕組みです。

(1) すべて許可する設定 (AlwaysAllow)

authorization:
  mode: AlwaysAllow

  • mode: AlwaysAllow
    → すべてのリクエストを許可 する設定。
    → 認可チェックを行わない ため、セキュリティ的には非常にリスクが高い。

🔍 イメージ
「誰でも自由にオフィスの会議室を使える」ような状態です。管理者の承認なしに、すべての操作が実行できてしまう ため、本番環境では 絶対に避けるべき 設定です。

(2) Webhook 認可 (webhook)

webhook:
  cacheAuthorizedTTL: 0s
  cacheUnauthorizedTTL: 0s

  • cacheAuthorizedTTL: 0s
    → 認可されたリクエストをキャッシュしない。
    → 毎回 Webhook に問い合わせるため、最新のポリシーが即時適用される。

  • cacheUnauthorizedTTL: 0s
    → 拒否されたリクエストもキャッシュしない。
    → 再試行時にも、毎回 Webhook に問い合わせる。

🔍 イメージ
「オフィスの入退室管理がすべてリアルタイムで更新される」状態です。例えば、部門異動した瞬間にアクセス権限が変わる ような仕組みになり、管理はしやすいですが、処理の負荷は増えます。

3. この設定のリスクと改善策

リスク

✅ 認証 (authentication) の設定

  • 匿名アクセス (anonymous) を禁止 → OK

  • Webhook 認証を毎回実行 (cacheTTL: 0s) → OK

  • クライアント証明書 (x509) を要求 → OK

❌ 認可 (authorization) の設定

  • AlwaysAllow により、すべてのリクエストを許可 → 非常に危険
    → 認証さえ通れば、どんな操作でも実行できるため 実質「フリーパス」状態 になってしまう。

推奨される設定

本番環境では、AlwaysAllow を避けて、Webhook か RBAC を使用するのがベストです。

(1) Webhook を使う場合

authorization:
  mode: Webhook
  webhook:
    cacheAuthorizedTTL: 5s
    cacheUnauthorizedTTL: 5s

  • 認可の結果を 5 秒間キャッシュ し、頻繁な問い合わせによる負荷を軽減。

(2) RBAC を使う場合

authorization:
  mode: RBAC

  • Role-Based Access Control (RBAC) を利用し、必要な操作のみ許可する。

4. まとめ

  • 認証 (authentication) は厳格に設定するのが基本！

    • 匿名アクセス (anonymous) は禁止。

    • Webhook 認証 (webhook) を使用し、キャッシュはなし。

    • クライアント証明書 (x509) を使ってアクセス管理。

  • 認可 (authorization) は AlwaysAllow を避ける！

    • Webhook または RBAC を使うのがベスト。

このように設定すれば、セキュアな kubelet のアクセス管理が可能になります！

いいなと思ったら応援しよう！