Kerberos認証をざっくり整理してみた（特徴・仕組み・設定ポイント）

はじめに

Kerberos 認証は Windows ドメインや Hadoop/Spark などで広く使われていますが、仕組みや設定項目がわかりづらいことが多いです。
本記事では、Kerberos 認証の基本を 特徴・認証フロー・設定ポイント・利用シーン という観点で整理してみました。

ユーザーとサービス（サーバ）間で パスワードを送らずに本人確認できる仕組み です。
MIT で開発され、現在は企業・官公庁・教育機関・大規模データ基盤で幅広く利用されています。

特徴	内容
パスワードを直接送らない	ネットワークにパスワードが流れないため盗聴に強い
チケットベースの認証	一度ログインすれば、以降は「チケット」で再認証なし（SSO）
暗号化通信	認証情報は暗号化されて送信されるため安全性が高い

Kerberos 認証では「チケットの期限」が重要になります。

項目	内容	例
ticket_lifetime	初回に発行されたチケットの有効時間	`10h`
renew_lifetime	延長可能な最大有効期間	`7d`

[libdefaults]
  ticket_lifetime = 10h
  renew_lifetime = 7d

コンポーネント	役割
クライアント（PC/ブラウザ）	TGT を保持し、SPNEGO で自動認証
Webサーバ（Apache/Nginx）	Kerberos モジュールで SPNEGO トークンを検証
KDC（Key Distribution Center）	Active Directory や MIT Kerberos サーバが担う

Windows ドメイン（Active Directory）
Windows ログインやファイル共有で自動的に Kerberos 認証が利用される（SSO）
Hadoop/Hive/Spark
認証付き HDFS アクセスや HiveServer2 接続時に利用
社内Webサービス（SSO）
ブラウザが SPNEGO を使い、自動ログイン
SSH（Kerberos対応）
パスワード不要で安全にログイン可能
メールサーバ（IMAP/SMTP）
企業向け環境での安全な送受信

同じクライアントから短時間に大量の kinit（認証要求）を送ると、KDC サーバに負荷がかかります。

項目	内容
CPU使用率	チケット発行時に暗号化処理（AESなど）が必要 → CPU負荷上昇
メモリ使用量	発行済み TGT 情報やログを一時保持 → 同時接続で逼迫の可能性
セッション管理	Kerberos自体はステートレスだが、ログや監視で内部的に管理情報が増える