📋 EKS コントロールプレーンログ
& CloudTrail 監査ログ

Kubernetes APIサーバーのログとAWS監査ログを完全理解！

🎯 結論ファースト：30秒でわかるポイント

📹
EKS コントロールプレーンログ
Kubernetes内部で何が起きているかを記録
→ 「社内の防犯カメラ」
デフォルト：無効 ⚠️ 要設定
🏛️
CloudTrail 監査ログ
AWSサービスへのAPI呼び出しを記録
→ 「公的機関の監視記録」
デフォルト：有効 ✅
🎬
何を記録する？
誰が・いつ・何を・どうしたか
5種類のログで完全把握
API / Audit / Auth / Controller / Scheduler
📍
どこに保存？
CloudWatch Logs に自動送信
/aws/eks/クラスター名/cluster
S3やSIEMへの転送も可能

🏢 たとえ話で理解しよう

🏬 EKSクラスター = 大型商業施設
📹 社内監視システム
（コントロールプレーンログ）

施設内部 で何が起きているかを記録

🎫
受付カウンター（API Server）
来訪者の要求を受け付け、対応を指示
📋
入退館記録（Audit Log）
誰がいつ何をしたか全て記録
🪪
身分証確認（Authenticator）
IDカードが本物か、権限があるか確認
🎛️
施設管理室（Controller Manager）
空調・照明・エレベーターを自動制御
📅
予約管理（Scheduler）
会議室や設備の割り当てを最適化
🏛️ 公的監査システム
（CloudTrail）

外部との取引・契約 を公式記録

📝
施設の建設・増築申請
CreateCluster / UpdateCluster
🔐
セキュリティ設定の変更
UpdateClusterConfig
👥
従業員の採用・配置
CreateNodegroup
🗑️
施設の廃止
DeleteCluster

💡 ポイント：
「社内カメラ」は 日常業務の詳細 を記録
「公的記録」は 重要な決定・変更 を記録
両方合わせて初めて完全な監査が可能！

📊 5つのコントロールプレーンログ

🎫
api
🏬 たとえ話
受付カウンターの対応記録
「お客様からこんな依頼がありました」
記録内容：
• kubectl コマンドの実行
• Pod/Service等の作成・削除
• APIサーバーの起動オプション
📝 例: "kubectl get pods" が実行された
📋
audit
🏬 たとえ話
入退館と全行動の記録
「誰がいつ何をしたか」
記録内容：
• ユーザー名とIPアドレス
• リクエストの種類と対象
• 成功/失敗の結果
🔍 例: "user:admin が pod を削除した"
🪪
authenticator
🏬 たとえ話
身分証チェックの記録
「このIDは本物？権限は？」
記録内容：
• IAMユーザー/ロールの認証
• RBAC権限の確認
• 認証成功/失敗
🔐 例: "IAMロール X が認証成功"
🎛️
controllerManager
🏬 たとえ話
施設管理の自動処理記録
「システムが自動で対応しました」
記録内容：
• Podの自動再起動
• ReplicaSetの調整
• ServiceAccountの管理
⚙️ 例: "Pod X を再作成しました"
📅
scheduler
🏬 たとえ話
部屋の割り当て記録
「どの部屋に誰を案内したか」
記録内容：
• Podの配置先ノード
• スケジューリングの理由
• リソース制約による判断
📍 例: "Pod Y を Node-A に配置"

⚖️ 2つの監視システムの違い

🔍 コントロールプレーンログ vs CloudTrail
📹
コントロールプレーンログ
Kubernetes内部の活動を監視
  • 対象 Kubernetes API への操作
  • 例 Pod作成、Deployment更新、Secret参照
  • 保存先 CloudWatch Logs
  • デフォルト ❌ 無効（要設定）
  • コスト CloudWatch Logs の料金
+
🏛️
CloudTrail
AWS API への操作を監視
  • 対象 AWS API への操作
  • 例 CreateCluster、UpdateNodegroup、DeleteCluster
  • 保存先 S3 / CloudWatch Logs
  • デフォルト ✅ 有効（90日間保持）
  • コスト 基本無料（長期保存は有料）

🎯 使い分けのポイント

📹 コントロールプレーンログを見る時
  • 「誰がPodを削除した？」
  • 「なぜPodがスケジュールされない？」
  • 「認証エラーの原因は？」
🏛️ CloudTrailを見る時
  • 「クラスターを作成したのは誰？」
  • 「ノードグループの設定変更履歴」
  • 「IRSAでどのAWS APIが呼ばれた？」

🔄 ログの流れを理解しよう

📊 EKSログが保存されるまで
👤
ユーザー操作
kubectl / API / Console
→
☸️
EKS Control Plane
5種類のコンポーネント
→
📊
CloudWatch Logs
/aws/eks/cluster-name/cluster
⬇️
🔍
Logs Insights
クエリで分析
📦
S3
長期保存
🛡️
SIEM
セキュリティ分析

📋 ログストリームの命名規則

// ログストリーム名の例
kube-apiserver- ランダムID
kube-apiserver-audit- ランダムID
authenticator- ランダムID
kube-controller-manager- ランダムID
kube-scheduler- ランダムID

⚙️ 有効化の方法

⚠️

重要：デフォルトでは無効！

EKSコントロールプレーンログは デフォルトで無効 です。
セキュリティ監査やトラブルシューティングのために、 必ず有効化 しましょう！

🖥️ AWSコンソール
💻 AWS CLI
🏗️ Terraform
📦 eksctl
🖥️ AWSコンソールでの設定手順

Step 1: EKSコンソールを開く

Amazon EKS → クラスター → 対象クラスターを選択

Step 2: Observabilityタブを選択

「Control plane logging」セクションを探す

Step 3: Manage loggingをクリック

5つのログタイプそれぞれのON/OFFを選択

Step 4: Save changesをクリック

✅ 完了！CloudWatch Logsへの送信が開始されます

💻 AWS CLIでの設定
# すべてのログタイプを有効化
aws eks update-cluster-config \
--name my-cluster \
--logging '{"clusterLogging":[{"types":["api","audit","authenticator","controllerManager","scheduler"],"enabled":true}]}'
# 現在の設定を確認
aws eks describe-cluster \
--name my-cluster \
--query 'cluster.logging'
🏗️ Terraformでの設定
resource "aws_eks_cluster" "main" {
name     = "my-cluster"
role_arn = aws_iam_role.cluster.arn

# ✅ 全ログタイプを有効化
enabled_cluster_log_types = [
"api" ,
"audit" ,
"authenticator" ,
"controllerManager" ,
"scheduler"
]

vpc_config {
subnet_ids = var.subnet_ids
}
}
📦 eksctlでの設定
# ClusterConfig YAMLファイル
apiVersion: eksctl.io/v1alpha5
kind: ClusterConfig

metadata:
name: my-cluster
region: ap-northeast-1

cloudWatch:
clusterLogging:
enableTypes:
- api
- audit
- authenticator
- controllerManager
- scheduler
# 既存クラスターに適用
eksctl utils update-cluster-logging \
--cluster my-cluster \
--enable-types api,audit,authenticator,controllerManager,scheduler \
--approve

🔍 便利なログ分析クエリ

📊 CloudWatch Logs Insights サンプルクエリ

🔐 aws-auth ConfigMapの変更を検出

fields @timestamp, @message
| filter @logStream like "kube-apiserver-audit"
| filter verb in [ "update" , "patch" ]
| filter objectRef.resource = "configmaps"
| filter objectRef.name = "aws-auth"
| filter objectRef.namespace = "kube-system"
| sort @timestamp desc

🚨 認証失敗を検出

fields @timestamp, @message
| filter @logStream like "authenticator"
| filter @message like "failed"
| sort @timestamp desc
| limit 50

🗑️ リソース削除の履歴

fields @timestamp, user.username, objectRef.resource, objectRef.name
| filter @logStream like "kube-apiserver-audit"
| filter verb = "delete"
| sort @timestamp desc
| limit 100

👤 特定ユーザーの操作履歴

fields @timestamp, verb, objectRef.resource, objectRef.name
| filter @logStream like "kube-apiserver-audit"
| filter user.username = "admin"
| sort @timestamp desc
| limit 100

✅ ベストプラクティス

🏆 EKSログ管理のベストプラクティス
🔓
全ログタイプを有効化
5つすべてのログタイプを有効にすることを推奨。後から「あの時のログがない」となるのを防ぎます。
📅
適切な保持期間を設定
CloudWatch Logsのログ保持期間を設定。コンプライアンス要件に応じて90日〜1年が一般的。
🔔
アラートを設定
aws-authの変更やSecretへのアクセスなど、重要なイベントにはCloudWatch Alarmsを設定。
📦
S3に長期保存
サブスクリプションフィルターでS3にエクスポート。コスト効率の良い長期保存が可能。
🔗
CloudTrailと併用
Kubernetes内部のログとAWS APIのログ、両方を組み合わせて完全な監査証跡を構築。
🛡️
SIEM連携を検討
大規模環境ではSplunk、Datadog、Falcoなどと連携して高度なセキュリティ分析を実施。
💰 コストについて
📥
データ取り込み
CloudWatch Logs への取り込み料金
約 $0.50/GB
💾
ストレージ
保存料金
約 $0.03/GB/月
🔍
クエリ
Logs Insights クエリ
約 $0.005/GB スキャン
💡
コスト削減のコツ
保持期間の最適化
S3への自動エクスポート

⚖️ コスト vs セキュリティのバランス
ログ保存のコストは、セキュリティインシデント発生時の
調査・復旧コストと比較すると非常に小さいものです。

❓ よくある質問

🤔 5つのログタイプ、全部有効にすべき？
はい、本番環境では全て有効化を推奨します。
特に重要なのは「audit」と「authenticator」です。これらはセキュリティ監査に必須です。
ただし、ログ量が多いクラスターではコストを確認しながら判断してください。
🤔 コントロールプレーンログとCloudTrail、どっちが大事？
両方とも重要で、役割が異なります。
• コントロールプレーンログ ：Kubernetes内部の操作（Pod作成、設定変更など）
• CloudTrail ：AWS APIの操作（クラスター作成、ノードグループ変更など）
完全な監査には 両方が必要 です。
🤔 ログの有効化でクラスターに影響はある？
パフォーマンスへの影響はほぼありません。
ログはコントロールプレーン側で処理され、ワークロードには影響しません。
ただし、設定変更中（数分間）はクラスターのステータスが「Updating」になります。
🤔 ログが大量で分析が大変…何かいい方法は？
いくつかの方法があります：
• CloudWatch Logs Insights ：クエリで効率的にフィルタリング
• Falco ：異常検知の自動化（OSS）
• サードパーティSIEM ：Splunk、Datadog等との連携
• CloudTrail Insights ：異常なAPI呼び出しを自動検出
🤔 監査ログの最大サイズ制限は？
CloudWatch Logsのエントリは最大1MBです。
Kubernetes API リクエストの最大サイズは1.5MiBなので、非常に大きなリクエストは切り詰められる可能性があります。
通常の操作では問題になりません。

🎓 まとめ

📹
コントロールプレーンログ
Kubernetes内部を監視
5種類のログタイプ
デフォルト無効→要設定
🏛️
CloudTrail
AWS API操作を監視
EKS管理操作を記録
デフォルト有効
📊
CloudWatch Logs
ログの保存先
Insights で分析
S3/SIEM連携可能
🔐
セキュリティ
監査証跡を確保
インシデント調査
コンプライアンス対応
🏬 商業施設にたとえると：

📹 コントロールプレーンログ = 社内の防犯カメラと入退館記録
🏛️ CloudTrail = 役所への届出・契約書の記録

両方を有効にして、EKSクラスターの完全な監査体制を構築しましょう！📋

Created by SSuzuki1063

AWS SAP Learning Resources