考慮事項と前提条件

Kubernetes API の監査構成をセットアップする前に、以下の情報を確認してください。

監査ログは、'IBM-Cloud/kube-samples GitHubリポジトリの以下のポリシーを使用する。 バージョン1.30から、ポリシーはRed Hatが OpenShiftで使用しているものに忠実になるように更新された。 両ポリシーの詳細は以下を参照されたい。

• default ポリシー。
• verbose ポリシー。

デフォルト・ポリシーを変更したり、独自のカスタム・ポリシーを適用したりすることはできません。

• Kubernetes 監査ログおよび詳細度については、 Kubernetes のドキュメントを参照してください。
• 1 つのクラスターに作成できる監査 Web フックは 1 つだけです。
• IBM Cloud Kubernetes Service クラスターの 管理者 IBM Cloud IAM プラットフォーム・アクセス役割 が必要です。

まず、 Kubernetes API監査ログ を IBM Cloud プライベートネットワーク内のリソース、または 外部サーバーに 送信する手順に従ってください。

Kubernetes のAPI監査ログをCloud Logsに転送

監査ログを IBM Cloud Logs に転送するには、提供されているイメージとデプロイメントを使用して Kubernetes 監査システムを作成します。

次の例では、 icr.io/ibm/ibmcloud-kube-audit-to-ibm-cloud-logs の画像を使用して、ログを IBM Cloud Logs に転送します。 この画像はデモンストレーションのみを目的としています。 実動ソリューションの場合は、独自のログ転送イメージを構成して保守します。

以前は、 icr.io/ibm/ibmcloud-kube-audit-to-logdna がログの転送に使用されていました。 この画像は非推奨となっており、まもなくサポートが終了します。 代わりに icr.io/ibm/ibmcloud-kube-audit-to-ibm-cloud-logs を使用するように、ログ転送設定を更新してください。

クラスター内の Kubernetes 監査システムは、監査 Web フック、ログ収集サービスと Web サーバー・アプリ、およびロギング・エージェントで構成されます。 Web フックが、クラスター・マスターから Kubernetes API サーバーのイベントを収集します。 ログ収集サービスは、パブリック IBM Cloud レジストリーにあるイメージから作成される Kubernetes ClusterIP サービスです。 このサービスは、プライベート・ネットワーク上でのみ公開される単純な node.js HTTP Web サーバー・アプリを公開します。 Web サーバー・アプリケーションは、監査 Web フックからのログ・データを解析し、各ログを固有の JSON 行として作成します。 最後に、ロギングエージェントがウェブサーバーアプリからのログを IBM Cloud Logs に転送し、そこでログを表示することができます。

作業を開始する前に ： 考慮事項と前提条件 を確認し、 IBM Cloud Logs のための 管理者 IBM Cloud IAMプラットフォームアクセス権限 を持っていることを確認してください。

1. パブリック IBM Cloud イメージのグローバル・コンテナー・レジストリーをターゲットとして設定します。

   ibmcloud cr region-set global
   

2. オプション： kube-audit の画像についての詳細は、 icr.io/ibm/ibmcloud-kube-audit-to-ibm-cloud-logs をご覧ください。

   ibmcloud cr image-inspect icr.io/ibm/ibmcloud-kube-audit-to-ibm-cloud-logs
   

3. ibmcloud-kube-audit.yaml という名前の構成ファイルを作成します。 この構成ファイルは、ログ収集サービスと、 icr.io/ibm/ibmcloud-kube-audit-to-ibm-cloud-logs イメージをプルしてログ収集コンテナを作成するデプロイメントを作成します。

   apiVersion: v1
   kind: List
   metadata:
     name: ibmcloud-kube-audit
   items:
     - apiVersion: v1
       kind: Namespace
       metadata:
         name: ibm-kube-audit
         labels:
           pod-security.kubernetes.io/enforce: restricted
           pod-security.kubernetes.io/enforce-version: latest
           pod-security.kubernetes.io/audit: restricted
           pod-security.kubernetes.io/audit-version: latest
           pod-security.kubernetes.io/warn: restricted
           pod-security.kubernetes.io/warn-version: latest
     - apiVersion: apps/v1
       kind: Deployment
       metadata:
         name: ibmcloud-kube-audit
         namespace: ibm-kube-audit
         labels:
           app: ibmcloud-kube-audit
       spec:
         replicas: 1
         selector:
           matchLabels:
             app: ibmcloud-kube-audit
         template:
           metadata:
             labels:
               app: ibmcloud-kube-audit
           spec:
             containers:
               - name: ibmcloud-kube-audit
                 image: 'icr.io/ibm/ibmcloud-kube-audit-to-ibm-cloud-logs:latest'
                 imagePullPolicy: Always
                 ports:
                   - containerPort: 3000
                 securityContext:
                   allowPrivilegeEscalation: false
                   runAsNonRoot: true
                   capabilities:
                     drop:
                     - ALL
                   seccompProfile:
                     type: RuntimeDefault
     - apiVersion: v1
       kind: Service
       metadata:
         name: ibmcloud-kube-audit-service
         namespace: ibm-kube-audit
         labels:
           app: ibmcloud-kube-audit
       spec:
         selector:
           app: ibmcloud-kube-audit
         ports:
           - protocol: TCP
             port: 80
             targetPort: 3000
         type: ClusterIP
     - kind: NetworkPolicy
       apiVersion: networking.k8s.io/v1
       metadata:
         name: ibmcloud-kube-audit
         namespace: ibm-kube-audit
       spec:
         podSelector:
           matchLabels:
             app: ibmcloud-kube-audit
         policyTypes:
         - Ingress
         ingress:
         - ports:
           - protocol: TCP
             port: 3000
           from:
           - namespaceSelector:
               matchLabels:
                 kubernetes.io/metadata.name: kube-system
             podSelector:
               matchLabels:
                 k8s-app: konnectivity-agent
   

4. クラスタの ibm-kube-audit 名前空間にデプロイメントを作成します。

   kubectl create -f ibmcloud-kube-audit.yaml
   

5. ibmcloud-kube-audit-service ポッドの**「STATUS」**がRunningになっていることを確認します。

   kubectl get pods -n ibm-kube-audit -l app=ibmcloud-kube-audit
   

   出力例

   NAME                                             READY   STATUS             RESTARTS   AGE
   ibmcloud-kube-audit-c75cb84c5-qtzqd              1/1     Running   0          21s
   

6. クラスター内に ibmcloud-kube-audit-service サービスがデプロイされたことを確認します。

   kubectl get svc -n ibm-kube-audit -l app=ibmcloud-kube-audit
   

   出力例

   NAME                          TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)          AGE
   ibmcloud-kube-audit-service   ClusterIP   172.21.xxx.xxx   <none>        80/TCP           1m
   

7. アカウントにログインします。 該当する場合は、適切なリソース・グループをターゲットにします。 クラスターのコンテキストを設定します。 client-certificate と client-key ファイルをローカルマシンにダウンロードするには、 --admin オプションを指定してください。 これらのファイルは、後で監査 Web フックを構成するために使用されます。

   ibmcloud ks cluster config --cluster <cluster> --admin
   

8. クラスタの certificate-authority を問い合わせ、ファイルに保存します。

   ibmcloud ks cluster ca get -c <cluster> --output json | jq -r .caCert | base64 -D > <certificate-authority>
   

9. kubectl config view コマンドを実行して現在の構成を表示し、client-certificate および client-key の出力を確認します。

   kubectl config view --minify
   

   出力例

   clusters:
   - cluster:
       ...
       ...
       client-certificate: /Users/user/.bluemix/plugins/container-service/clusters/cluster-name-a111a11a11aa1aa11a11-admin/admin.pem
       client-key: /Users/user/.bluemix/plugins/container-service/clusters/cluster-name-a111a11a11aa1aa11a11-admin/admin-key.pem
   

10. 監査 Webhook を構成し、certificate-authority、client-certificate、および client-key を指定します。 certificate-authority は ステップ 8 で取得され、client-certificate および client-key は前のステップで取得されました。

ibmcloud ks cluster master audit-webhook set --cluster CLUSTER --remote-server https://127.0.0.1:2040/api/v1/namespaces/ibm-kube-audit/services/ibmcloud-kube-audit-service/proxy/post --ca-cert CERTIFICATE-AUTHORITY --client-cert CLIENT-CERT --client-key CLIENT-KEY [--policy default|verbose]

11. クラスター内に監査 Web フックが作成されたことを確認します。

ibmcloud ks cluster master audit-webhook get --cluster <cluster_name_or_ID>

出力例

Server:   https://127.0.0.1:2040/api/v1/namespaces/ibm-kube-audit/services/ibmcloud-kube-audit-service/proxy/post   
Policy:   default

12. クラスター・マスターをリフレッシュして、Web フックを Kubernetes API サーバーに適用します。 マスターがリフレッシュされるまで数分かかることがあります。

ibmcloud ks cluster master refresh --cluster <cluster_name_or_ID>

13. マスターがリフレッシュされている間に、IBM Cloud Logs のインスタンスをプロビジョンし、クラスター内のすべてのワーカー・ノードにロギング・エージェントをデプロイします。 ロギング・エージェントは、クラスター内部から IBM Cloud Logs サービスにログを転送するために必要です。 クラスター内に既にロギング・エージェントをセットアップしている場合は、この手順をスキップできます。

14. マスターのリフレッシュが完了し、ワーカー・ノードでロギング・エージェントが実行されていれば、IBM Cloud Logs で Kubernetes API 監査ログを表示できます。

クラスタで監査ウェブフックを設定した後、 ibmcloud cr image-list --include-ibm | grep ibmcloud-kube-audit-to-ibm-cloud-logs を実行することで、 kube-audit-to-logdna イメージのバージョン更新を監視することができます。 クラスター内で現在実行されているイメージのバージョンを確認するには、kubectl get pods | grep ibmcloud-kube-audit-to-ibm-cloud-logs を実行して監査ポッド名を見つけ、kubectl describe pod <pod_name> を実行してイメージのバージョンを確認します。

IBM Cloud プライベート・ネットワーク内のリソースへの Kubernetes API 監査ログの転送

クラスターの外部にあり、IBM Cloud Logs プライベート・ネットワークでアクセス可能な IBM Cloud 以外のリソースに監査ログを転送します。

以下の例では、 haproxytech/haproxy-alpine:2.6 イメージを使用してログを転送します。 このイメージはデモンストレーション専用であり、実稼働環境では使用しないでください。 実動ソリューションの場合は、独自のログ転送イメージを構成して保守します。

始める前に、考慮事項および前提条件を確認してください。

1. 新規ディレクトリー kube-audit-forwarder を作成し、その中に以下の内容のファイル haproxy.cfg を作成します。 ファイル内の <REMOTE-IP>:<REMOTE-PORT> をリモート・ログ・コンシューマーの IP アドレスおよびポートに置き換えることを忘れないでください。

   global
     log stdout format raw local0 info
   defaults
     mode http
     timeout client 10s
     timeout connect 5s
     timeout server 10s
     timeout http-request 10s
     log global
   frontend myfrontend
     bind :3000
     default_backend remotelogstash
   # Use remote log consumer IP and port here
   backend remotelogstash
     server s1 <REMOTE-IP>:<REMOTE-PORT> check
   

   ログ・コンシューマー・サーバーがセキュア接続 (TLS) を適用している場合は、証明書ファイルをこのディレクトリーに追加し、これらのファイルを使用するように haproxy.cfg のバックエンド・セクションを変更できます。 詳しくは、 HAProxy の資料を参照してください。

2. kube-audit-forwarder ディレクトリーの内容から configmap を作成します。

   kubectl create namespace ibm-kube-audit; kubectl create configmap -n ibm-kube-audit kube-audit-forwarder-cm --from-file=kube-audit-forwarder
   

3. kube-audit-forwarder-remote-private-ip.yaml という名前の構成ファイルを作成します。 この構成ファイルは、 IBM Cloud プライベート・ネットワークを介して、クラスターからリモート・リソースの IP アドレスに監査ログを転送するデプロイメントとサービスを作成します。

   kind: Deployment
   apiVersion: apps/v1
   metadata:
     labels:
       app: kube-audit-forwarder
     name: kube-audit-forwarder
     namespace: ibm-kube-audit
   spec:
     revisionHistoryLimit: 2
     selector:
       matchLabels:
         app: kube-audit-forwarder
     strategy:
       rollingUpdate:
         maxUnavailable: 1
       type: RollingUpdate
     template:
       metadata:
         labels:
           app: kube-audit-forwarder
       spec:
         containers:
         - image: haproxytech/haproxy-alpine:2.6
           imagePullPolicy: IfNotPresent
           name: haproxy
           volumeMounts:
           - name: config-volume
             mountPath: /usr/local/etc/haproxy/haproxy.cfg
             subPath: haproxy.cfg
         volumes:
         - name: config-volume
           configMap:
             name: kube-audit-forwarder-cm
   ---
   apiVersion: v1
   kind: Service
   metadata:
     name: kube-audit-forwarder
     namespace: ibm-kube-audit
   spec:
     selector:
       app: kube-audit-forwarder
     ports:
       - protocol: TCP
         port: 80
         targetPort: 3000
   ---
   kind: NetworkPolicy
   apiVersion: networking.k8s.io/v1
   metadata:
     name: kube-audit-forwarder
     namespace: ibm-kube-audit
   spec:
     podSelector:
       matchLabels:
         app: kube-audit-forwarder
     policyTypes:
     - Ingress
     ingress:
     - ports:
       - protocol: TCP
         port: 3000
       from:
       - namespaceSelector:
           matchLabels:
             kubernetes.io/metadata.name: kube-system
         podSelector:
           matchLabels:
             k8s-app: konnectivity-agent
       - namespaceSelector:
           matchLabels:
             kubernetes.io/metadata.name: kube-system
         podSelector:
           matchLabels:
             app: konnectivity-agent
       - namespaceSelector:
           matchLabels:
             kubernetes.io/metadata.name: kube-system
         podSelector:
           matchLabels:
             app: vpn
   

   前のステップで証明書ファイルを kube-audit-forwarder に追加した場合は、それらのファイルを subPath として volumeMounts セクションにリストすることを忘れないでください。

4. デプロイメントとサービスを作成します。

   kubectl create -f kube-audit-forwarder-remote-private-ip.yaml
   

5. kube-audit-forwarder の展開とサービスがクラスタに展開されていることを確認してください。

   kubectl get svc -n ibm-kube-audit
   

   出力例

   NAME                          TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)          AGE
   ...
   kube-audit-forwarder  ClusterIP   10.xxx.xx.xxx   <none>        80/TCP           1m
   

   kubectl get deployment -n ibm-kube-audit
   

   出力例

   NAME                   READY   UP-TO-DATE   AVAILABLE   AGE
   ...
   kube-audit-forwarder   1/1     1            1           6m27s
   

6. アカウントにログインします。 該当する場合は、適切なリソース・グループをターゲットにします。 クラスターのコンテキストを設定します。 client-certificate と client-key ファイルをローカルマシンにダウンロードするには、 --admin オプションを指定してください。 これらのファイルは、後で監査 Web フックを構成するために使用されます。

   ibmcloud ks cluster config --cluster <cluster> --admin
   

7. クラスタの certificate-authority を問い合わせ、ファイルに保存します。

    ibmcloud ks cluster ca get -c <cluster> --output json | jq -r .caCert | base64 -D > <certificate-authority>
   

8. kubectl config view コマンドを実行して現在の構成を表示し、client-certificate および client-key の出力を確認します。

   kubectl config view --minify
   

   出力例

   clusters:
   - cluster:
       ...
       ...
       client-certificate: /Users/user/.bluemix/plugins/container-service/clusters/cluster-name-a111a11a11aa1aa11a11-admin/admin.pem
       client-key: /Users/user/.bluemix/plugins/container-service/clusters/cluster-name-a111a11a11aa1aa11a11-admin/admin-key.pem
   

9. 監査 Webhook を構成し、ステップ 5 から 7 で取得した certificate-authority、 client-certificate、および client-key を指定します。

   ibmcloud ks cluster master audit-webhook set --cluster <cluster> --remote-server https://127.0.0.1:2040/api/v1/namespaces/ibm-kube-audit/services/kube-audit-forwarder/proxy/post --ca-cert <certificate-authority> --client-cert <client-certificate> --client-key <client-key> [--policy default|verbose]
   

10. クラスター内に監査 Web フックが作成されたことを確認します。

ibmcloud ks cluster master audit-webhook get --cluster <cluster_name_or_ID>

出力例

OK
Server:            https://127.0.0.1:2040/api/v1/namespaces/ibm-kube-audit/services/kube-audit-forwarder/proxy/post
Policy:            default

11. クラスター・マスターをリフレッシュして、Web フックを Kubernetes API サーバーに適用します。 マスターがリフレッシュされるまでに数分かかる場合があります。

ibmcloud ks cluster master refresh --cluster <cluster_name_or_ID>

マスターのリフレッシュが完了したら、ログがロギング・リソースのプライベート IP アドレスに送信されます。

パブリック・インターネット上の外部サーバーへの Kubernetes API 監査ログの転送

Kubernetes API サーバーを介して渡されるすべてのイベントを監査するには、Fluentd を使用してイベントを外部サーバーに転送する構成を作成できます。

始める前に、考慮事項および前提条件を確認してください。 ログ・フィルターはサポートされていないことに注意してください。

1. Webhook をセットアップします。 オプションに何も情報を入力しない場合、デフォルト設定が使用されます。

   ibmcloud ks cluster master audit-webhook set --cluster <cluster_name_or_ID> --remote-server <server_URL_or_IP> --ca-cert <CA_cert_path> --client-cert <client_cert_path> --client-key <client_key_path> [--policy default|verbose]
   

   このコマンドの構成要素について

   オプション	説明
   <cluster_name_or_ID>	クラスターの名前または ID。
   <server_URL>	ログの送信先となるリモート・ロギング・サービスの、パブリックからアクセス可能な URL または IP アドレス。 非セキュアなサーバー URL を指定すると、証明書は無視されます。
   <CA_cert_path>	リモート・ロギング・サービスの検証に使用される CA 証明書のファイル・パス。
   <client_cert_path>	リモート・ロギング・サービスに対する認証に使用されるクライアント証明書のファイル・パス。
   <client_key_path>	リモート・ロギング・サービスへの接続に使用される、対応するクライアント・キーのファイル・パス。

2. リモート・ロギング・サービスの URL を参照して、ログ転送が有効化されていることを確認します。

   ibmcloud ks cluster master audit-webhook get --cluster <cluster_name_or_ID>
   

   出力例

   OK
   Server:            https://8.8.8.8
   

3. Kubernetes マスターを再始動して、構成の更新を適用します。

   ibmcloud ks cluster master refresh --cluster <cluster_name_or_ID>
   

4. オプション: 監査ログの転送を停止するには、構成を無効にします。

   1. API サーバー監査ログの収集を停止する対象のクラスター: アカウントにログインします。 該当する場合は、適切なリソース・グループをターゲットにします。 クラスターのコンテキストを設定します。

   2. クラスターの API サーバーの Web フック・バックエンド構成を無効にします。

      ibmcloud ks cluster master audit-webhook unset --cluster <cluster_name_or_ID>
      

   3. Kubernetes マスターを再始動して、構成の更新を適用します。

      ibmcloud ks cluster master refresh --cluster <cluster_name_or_ID>
      

API サーバー・ログの転送の管理

ログ転送構成の確認、更新、および削除を参照してください。

監査ログが以前は機能していたにもかかわらず、監査ログを取得する際にエラーが発生する場合は、監査ログに使用されている認証局が期限切れまたはローテーションされたことが原因である可能性があります。 Webhookをセットアップし、証明書を更新するには、前の手順を繰り返します。 また、apiserver_audit_error_total{plugin="webhook"} というKubernetes メトリックを探すこともできます。