Kubernetes監査ログ
Kubernetes監査ログで、クラスタ内で起こった事象を記録します。これにはユーザーアクティビティや、コントロールプレーン、ノードデーモン、クラスタサービス、Kubernetes API自体といったコンポーネントによるKubernetes APIへのすべての要求が記載されます。
Kubernetes監査ログはAPIサーバーによるJSON出力で、構築され、重要なメタデータを含んでいます。Site24x7アプリケーションログでKubernetes監査ログを監視して、Kubernetesクラスタ環境を可視化します。
監査ログのメリット
- だれがいつどこで何を行ったかの情報を取得
- クラスター内問題のデバッグ
- 権限および条件関連のRBACポリシー問題のトラブルシュート
目次
監査ポリシーと監査バックエンド
監査ポリシーとバックエンドは、APIサーバーで設定しなければならない2つの設定があり、これにより監査ログを出力します。
監査ポリシー：監査ポリシーでどのイベントを記録し、どのデータを記載するかを定義します。audit-policy.yamlファイルで、記録したいAPIリクエストのタイプを定義します。監査ログは監査ポリシー設定に基づいて収集されます。
監査バックエンド：監査イベントはポリシールールに基づいて処理され、バックエンドが監査イベントを次の外部ストレージにプッシュします。
- ログバックエンド：ログファイル（オンプレミスとクラウド環境ともに利用可能）にイベントを書き込みます。
- Webhookバックエンド：ローカルファイルの代わりに外部HTTP API宛にイベントを送信します。
詳細はKubernetes Auditingドキュメントを参照してください。
ログバックエンド設定
Kubernetes監査ログはデフォルトで無効化されています。次の環境の監査ログを有効および無効化できます。
オンプレミス
次の3ステップでオンプレミス環境の監査ログの有効化と設定を行ってください。
ステップ1：監査ポリシーの作成
ファイルパス/etc/kubernetes/audit-policy.yamlにポリシーファイルaudit-policy.yamlを作成します。ポリシーファイルに定義されている最初のマッチングルールをＡＰＩサーバーが処理するように、最上部のルールを定義します。
Kubernetesドキュメントのサンプルのポリシーファイルは次のとおりです。.
kind: Policy
# Don't generate audit events for all requests in RequestReceived stage.
omitStages:
- "RequestReceived"
rules:
# Log pod changes at RequestResponse level
- level: RequestResponse
resources:
- group: ""
# Resource "pods" doesn't match requests to any subresource of pods,
# which is consistent with the RBAC policy.
resources: ["pods"]
# Log "pods/log", "pods/status" at Metadata level
- level: Metadata
resources:
- group: ""
resources: ["pods/log", "pods/status"] # Don't log requests to a configmap called "controller-leader"
- level: None
resources:
- group: ""
resources: ["configmaps"]
resourceNames: ["controller-leader"] # Don't log watch requests by the "system:kube-proxy" on endpoints or services
- level: None
users: ["system:kube-proxy"]
verbs: ["watch"]
resources:
- group: "" # core API group
resources: ["endpoints", "services"] # Don't log authenticated requests to certain non-resource URL paths.
- level: None
userGroups: ["system:authenticated"]
nonResourceURLs:
- "/api*" # Wildcard matching.
- "/version" # Log the request body of configmap changes in kube-system.
- level: Request
resources:
- group: "" # core API group
resources: ["configmaps"]
# This rule only applies to resources in the "kube-system" namespace.
# The empty string "" can be used to select non-namespaced resources.
namespaces: ["kube-system"] # Log configmap and secret changes in all other namespaces at the Metadata level.
- level: Metadata
resources:
- group: "" # core API group
resources: ["secrets", "configmaps"] # Log all other resources in core and extensions at the Request level.
- level: Request
resources:
- group: "" # core API group
- group: "extensions" # Version of group should NOT be included. # A catch-all rule to log all other requests at the Metadata level.
- level: Metadata
# Long-running requests like watches that fall under this rule will not
# generate an audit event in RequestReceived.
omitStages:
- "RequestReceived"
ステップ2：監査ポリシーとログファイルパスの定義
kube-apiserverはマスターノードにホストされているクラスタコントロールプレーンの一部であるため、マスターノードでは監査ログのみ有効化されます。/etc/kubernetes/manifests/kube-apiserver.yamlファイル内の次のフラグを設定します。
--audit-log-path=/var/log/kubernetes/audit/audit.log
設定ファイル内のvolumeMountsとvolumes項目を次のように更新します。
- mountPath: /etc/kubernetes/audit-policy.yaml
name: audit
readOnly: true
- mountPath: /var/log/kubernetes/audit/audit.log
name: audit-log
readOnly: false
- hostPath:
path: /etc/kubernetes/audit-policy.yaml
type: File
name: audit
- hostPath:
path: /var/log/kubernetes/audit/
type: DirectoryOrCreate
name: audit-log
ステップ3：Site24x7アプリケーションログでのログプロファイルの作成
- Site24x7にログインします。
- Site24x7サーバー監視エージェントを(Linux)Kubernetesクラスタマスターノードにインストールします。
- 管理 > アプリケーションログ > ログプロファイル > ログプロファイルの追加に移動します。
- ログタイプの選択からKubernetes監査ログを選択します。
- /var/log/kubernetes/audit/audit.log をログの検索のためのファイルリストに記載します。
これによりオンプレミス環境の監査ログをSite24x7で監視できます。
クラウド
監査ログのロギングを行えるのは次のとおりです。
- Azure Kubernetes Service (AKS)
- Amazon Elastic Kubernetes Service (EKS)
Azure Kubernetes Serviceロギング
次の手順で、Azure Kubernetes Service (AKS)のロギングを有効および無効化できます。
手順1：ログプロファイルの作成
Site24x7で、管理 > アプリケーションログ > ログプロファイル > ログプロファイルの追加に移動し、次の項目を入力します。
- プロファイル名にログプロファイルの名前を入力します。
- ログタイプの選択からKubernetes監査ログを選択します。
- ログソースからAzure Functionsを選択します。
- ログタイムゾーンでUTCを選択します。
- 保存をクリックします。
手順2：Azure Resource Manager (ARM)テンプレートを用いたAzureリソース設定
Azure監査ログドキュメントの手順を参照し、ARMテンプレートを用いたAzureリソースを設定します。上記ドキュメントのデプロイ部分（ステップ7、8）で情報を入力する際、Kubernetes監査ログ特有の次の項目を編集してください。
- リソースグループ：Site24x7-AKS-Audit-Logsという名前のリソースグループを作成します。
- LogTypeConfig：Site24x7で作成したログプロファイルページ(管理 > アプリケーションログ > ログプロファイルe > <Kubernetes監査ログプロファイル名>)から値をコピーします。
手順3：監査ログの有効化とSite24x7への転送
- Azureポータルにログインします。
- Kubernetes servicesに移動後、Kubernetesクラスタを選択し、監査設定をクリックします。
- ログ配下のKubernetes Audit、宛先詳細配下のStream to an event hubを選択し、Event hub namespaceをクリックします。
その後、Azure Kubernetes Service環境の監査ログをSite24x7アプリケーションログで監視できます。
Amazon Elastic Kubernetes Serviceロギング
Amazon Elastic Kubernetes Service (EKS)のロギングを次の手順で有効および無効化できます。
ステップ1：Amazon EKS監査ログの有効化
Amazon EKS監査ログの有効化と無効化を参照してください。
手順2：CloudWatchログの収集
- Site24x7で、管理 > アプリケーションログ > ログプロファイル > ログプロファイルの追加に移動します。
- プロファイル名で、ログプロファイルの名前を入力します。
- ログタイプの選択からKubernetes監査ログを選択します。
- ログソースからAmazon Lambdaを選択します。
- 保存をクリックします。
- こちらのドキュメントAWS設定項目の手順を参照し、収集したCloudWatchログをSite24x7に表示します。今回の場合、logtypeconfigにKubernetes監査ログ、ロググループに/aws/eks/<my-cluster>/cluster/と指定して、ドキュメント内の設定を行ってください。
これにより、Amazon Elastic Kubernetes Service環境の監査ログをSite24x7アプリケーションログで監視できます。
Webhookバックエンド設定
Webhookバックエンド設定方法は次のとおりです。
設定手順
- ログバックエンド設定で記述した監査ポリシーを作成し定義します。
- ログタイプ を作成します。
- ログタイプで、Kubernetes監査ログを選択します。これによりその後の項目が自動入力されます。
- APIアップロードを有効にします。
- HTTPSエンドポイントURLをコピーします。
- 保存をクリックします。
- ファイルパス/etc/kubernetes/pki/audit-webhook.yamlに新規ファイルを作成し、次のコンテンツをコピーします。上記ステップでコピーしたHTTPSエンドポイントURLをサーバーキーのYAMLファイルに入力します。
apiVersion: v1
kind: Config
preferences: {}
clusters:
- name: kubernetes
cluster:
server: "https://logc.site24x7.com/event/receiver/M3NjE4ODc234242342wfwew3zMDhmMTZkYTVmM2I2N2MxOGZiZC9rdWJlY="
contexts:
- context:
cluster: kubernetes
user: kubernetes-admin
name: kubernetes-admin@kubernetes
current-context: kubernetes-admin@kubernetes
preferences: {}
users: [] - バックエンドWebhook監査を設定するには次のフラグを設定してください。
--audit-webhook-config-file=/etc/kubernetes/pki/audit-webhook.yaml flagin /etc/kubernetes/manifests/kube-apiserver.yaml file.
これにより、Amazon Elastic Kubernetes Service環境の監査ログをSite24x7アプリケーションログで監視できます。
監査ログのユースケース
サンプル監査イベントは次のとおりです。
上記サンプル監査ログには、次の重要なキーがあります。監査イベントで使用できる項目についての詳細はこちら
| キー | 説明 |
| user | リクエストを開始するユーザーまたはサービスアカウントです。 |
| sourceIP | 開始するIPです。 |
| verb | どのアクション(get、post、list、watch、patch、delete)を行うか指定します。 |
| requestURI | クライアントから送信されるサーバーへのリクエストIDです。 |
| objectRef | リクエストに関連付いているKubernetesオブジェクトの情報を表示します。 |
| responseStatus | 開始されたリクエストの応答です。 |
| requestReceivedTimestamp | APIサーバーが最初のリクエストを受信した時間です。 |
| responseObject | ユーザーやサービスアカウントにより開始されたリクエストに対する応答を分析します。 |
| annotations | 認証判別とその理由の情報を表示します。 |
- user、sourceIP、verb、requestURI、objectRef、requestReceivedTimestampといったキーは誰がいつどこで行ったかを表示するキーです。
- responseStatus、responseObject、annotationsは認証や受信応答についての情報を表示し、権限や条件関連の問題のトラブルシュートに役立ちます。
ダッシュボードのデコーディング
ダッシュボードのステータスコード統計ウィジェットで、400以上のステータスコードを表示できます。
詳細に調査するには、エラーコード4XXをクリックしエラーが発生したイベントを表示します。次のクエリ言語を使用して根本原因を判別できます。
logtype="Kubernetes Audit Logs" and responsestatus_code=403 and verb="list" and username="system:serviceaccount:default:demo"
でもユーザーはポッド、エラー結果にアクセスしません。それに応じたアクションを行えます。
Troubleshooting
設定中に発生した問題のトラブルシューティングは次のとおりです。
監査ログが取得できているかの確認方法
ログバックエンド設定
- ログバックエンド設定項目で記載した手順を行い、Kube-apiserver configファイルの変更が反映されるまでしばらくお待ちください。
- 次のコマンドを実行し、APIサーバーが稼働しているかを確認します。
kubectl get pods -n kube-system -w
- 次の下記のコマンドを実行し、ログプロファイルを開いて、監査エントリが作成されているかを確認します。
sudo cat /var/log/kubernetes/audit/audit.log
- 上記のサンプル ログのようなログが表示された場合、監査エントリが作成されていることが確認されます。
Webhookバックエンド設定
- Webhookバックエンド設定項目で記載した手順を行い、Kube-apiserver configファイルの変更が反映されるまでお待ちください。
- 次のコマンドを実行し、APIサーバーが稼働しているかを確認します。
kubectl get pods -n kube-system -w
- Webhookバックエンドがイベントを外部HTTP APIに送信するため、数秒お待ちください。その後、クライアントに歳ログインし監査エントリを確認してください。
監査ポリシーのガイドライン
Kubernetes API要求には、RequestReceived、ResponseStarted、ResponseComplete、Panicといった段階があります。ログはポリシーに定義されているルールおよびNone、Metadata、Request、RequestResponseといった監査レベルごとに記録されます。
- Request、RequestResponseレベルでは、API要求の分析が表示されますが、メモリ消費と監査ログストレージが増加します。
- メタデータを使用して、認証トークンといった重要なデータを除外します。