考慮事項と前提条件

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 監査システムを作成します。

次の例では、image 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 サービスです。 このサービスは、クラスタのネットワーク内でのみ公開される、シンプルな HTTP Webサーバーアプリケーションを提供します。 Web サーバー・アプリケーションは、監査 Web フックからのログ・データを解析し、各ログを固有の JSON 行として作成します。 最後に、ロギングエージェントはWebサーバーアプリからのログを 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. クラスタにアクセスするために kubeconfig を設定してください

   ibmcloud ks cluster config -c CLUSTER
   

4. 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
                   - containerPort: 4443
                 securityContext:
                   allowPrivilegeEscalation: false
                   runAsNonRoot: true
                   capabilities:
                     drop:
                     - ALL
                   seccompProfile:
                     type: RuntimeDefault
                 volumeMounts:
                   - mountPath: /certificates
                     name: certificates
                     readOnly: true
             volumes:
               - name: certificates
                 secret:
                   secretName: audit-webhook
                   optional: true
     - 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:
           - name: http
             protocol: TCP
             port: 80
             targetPort: 3000
           - name: https
             protocol: TCP
             port: 443
             targetPort: 4443
         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
           - protocol: TCP
             port: 4443
           from:
           - namespaceSelector:
               matchLabels:
                 kubernetes.io/metadata.name: kube-system
             podSelector:
               matchLabels:
                 k8s-app: konnectivity-agent
   

5. クラスタの「 ibm-kube-audit 」ネームスペースにデプロイメントを作成します。

   kubectl apply -f ibmcloud-kube-audit.yaml
   

6. デプロイメント ibmcloud-kube-audit が利用可能になるまでお待ちください。

   kubectl wait --for condition=Available --namespace ibm-kube-audit --timeout 5m deploy/ibmcloud-kube-audit
   

   出力例

   deployment.apps/ibmcloud-kube-audit condition met
   

7. クラスター内に 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
   

8. HTTPS で通信中のトラフィックを暗号化します。 概念実証用の監査ログ転送ツールのみが必要な場合は、この手順をスキップしてください。

9. 認証局のステータスを確認する。 証明書の有効期限が迫っている場合は、手順に従って 証明書をローテーションして ください。

   ibmcloud ks cluster ca status -c CLUSTER
   

10. クラスタの certificate-authority をファイルに保存 cluster-ca.pem する。

    ibmcloud ks cluster ca get -c CLUSTER --output json | jq -r .caCert | base64 -D > cluster-ca.pem
    

11. アカウントにログインします。 該当する場合は、適切なリソース・グループをターゲットにします。 クラスターのコンテキストを設定します。 証明書ベースのkubeconfigを準備し、. kubeconfig.json に保存する。 オプション --admin を指定して、データ client-key``client-certificate とデータをローカルマシンにダウンロードしてください。 このデータは後で監査ウェブフックの設定に使用されます。

    ibmcloud ks cluster config --cluster CLUSTER --admin --output json > kubeconfig.json
    

    kubeconfig の所有者が削除されたり、その権限が取り消されたりすると、Kubernetes API サーバーは監査ログを送信できなくなります。 このような事態を防ぐため、この操作にはサービスIDを使用することをお勧めします。サービスIDは特定のユーザーではなく、 アカウントに直接紐づいているためです。

12. kubeconfigのクライアント証明書をファイルに抽出 kubeconfig-cert.pem する。

    jq -r '.users[].user."client-certificate-data"' kubeconfig.json | base64 -D > kubeconfig-cert.pem
    

13. kubeconfigのクライアントキーをファイルに抽出 kubeconfig-key.pem する。

    jq -r '.users[].user."client-key-data"' kubeconfig.json | base64 -D > kubeconfig-key.pem
    

14. 監査 Webhook を構成し、certificate-authority、client-certificate、および client-key を指定します。 ステップ10 でが取得 certificate-authority され、前の2つのステップでと client-certificate が取得 client-key された。 必要に応じて、を別の policy 値に設定してください。

    ibmcloud ks cluster master audit-webhook set \
        --cluster CLUSTER \
        --remote-server https://127.0.0.1:2040/api/v1/namespaces/ibm-kube-audit/services/http:ibmcloud-kube-audit-service:http/proxy/post \
        --ca-cert cluster-ca.pem \
        --client-cert kubeconfig-cert.pem \
        --client-key kubeconfig-key.pem \
        --policy default
    

    ステップ8 で HTTPS を設定した場合、代わりにこの httpsURL を設定 remote-server してください：

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

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

    ibmcloud ks cluster master audit-webhook get --cluster CLUSTER
    

    出力例

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

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

    ibmcloud ks cluster master refresh --cluster CLUSTER
    

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

18. クラスタの状態を確認し、が Master State を示すまで待機し、 updating その後状態を待機 deployed する。 完了するまで数分かかる場合があります。

    ibmcloud ks cluster get -c CLUSTER
    

    出力例

    ...
    Master
    Status:     Refresh in progress. (2 seconds ago)
    State:      updating
    ...
    Master
    Status:     Ready (2 seconds ago)
    State:      deployed
    

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

クラスターで監査 Webhook を設定した後、 ibmcloud cr image-list --include-ibm | grep ibmcloud-kube-audit-to-ibm-cloud-logs を実行することで、 ibmcloud-kube-audit-to-ibm-cloud-logs イメージのバージョン更新状況を監視できます。 クラスター内で現在実行されているイメージのバージョンを確認するには、kubectl get pods | grep ibmcloud-kube-audit-to-ibm-cloud-logs を実行して監査ポッド名を見つけ、kubectl describe pod <pod_name> を実行してイメージのバージョンを確認します。 現在のタグで利用可能な最新バージョンにポッドを更新し kubectl rollout restart --namespace ibm-kube-audit deploy/ibmcloud-kube-audit 、新しいポッドが利用可能になるまで待機します。 kubectl rollout status --timeout 1m --namespace ibm-kube-audit deploy/ibmcloud-kube-audit

HTTPS による更新管理、証明書のローテーション、転送中の暗号化

ログ転送の準備前に留意すべき重要な事項：

1. 画像タグは脆弱性およびバグ修正 icr.io/ibm/ibmcloud-kube-audit-to-ibm-cloud-logs:latest の更新を受け取ります。 ただし、それらの変更を反映させるには、デプロイを手動で再実行する必要があります。 最新のイメージを取得し、正常に再起動するために kubectl rollout restart -n ibm-kube-audit deploy/ibmcloud-kube-audit 使用します。
2. このデプロイは手動でインストールおよび管理されます。 このデプロイメントから別のデプロイメントへの切り替えにより、監査ログのダウンタイムが発生する可能性があります。
3. 以下の手順で生成された証明書は、更新することができます。 ローテーションには、シークレットの置換とデプロイの再起動という手動手順が必要です。

転送中の暗号化でデプロイメントを保護するには、kube-apiserverによって署名された秘密鍵と TLS 証明書が必要です。

1. ステップ 4でYAMLファイルを適用した後、サービスリソースがクラスターIPを割り当てるまで待機してください。 それをシェル変数に保存してください $cluster_ip。

   cluster_ip=$(
       kubectl wait \
           --for jsonpath='{.spec.clusterIP}' \
           --namespace ibm-kube-audit \
           --output jsonpath='{.spec.clusterIP}' \
           --timeout 5m \
           svc/ibmcloud-kube-audit-service
   )
   

2. 秘密鍵を生成し、保存する server.key

   openssl genrsa -out server.key 4096
   

3. 証明書署名要求（CSR）設定ファイルを生成します server-csr.conf。 これは、 Kubernetes が署名する証明書を生成するために使用されます。

   cat <<EOF > server-csr.conf
   [ req ]
   default_bits = 2048
   prompt = no
   default_md = sha256
   req_extensions = req_ext
   distinguished_name = dn
   [ dn ]
   CN = system:node:ibmcloud-kube-audit-service.ibm-kube-audit.svc
   O = system:nodes
   [ req_ext ]
   subjectAltName = @alt_names
   [ alt_names ]
   DNS.1 = ibmcloud-kube-audit-service.ibm-kube-audit.svc.cluster.local
   DNS.2 = ibmcloud-kube-audit-service.ibm-kube-audit.svc
   IP.1 = ${cluster_ip}
   EOF
   

4. Kubernetes が署名するための証明書署名要求ペイロードを生成します。

   openssl req -new -config server-csr.conf -key server.key -out server.csr
   

5. ペイロードを KubernetesCertificateSigningRequest （CSR）リソースに挿入する

   kubectl apply -f - <<EOF
   apiVersion: certificates.k8s.io/v1
   kind: CertificateSigningRequest
   metadata:
     name: ibmcloud-kube-audit-service.ibm-kube-audit
   spec:
     request: $(base64 < server.csr | tr -d '\n')
     signerName: kubernetes.io/kubelet-serving
     usages:
     - digital signature
     - key encipherment
     - server auth
   EOF
   

6. リクエストを承認する

   kubectl certificate approve ibmcloud-kube-audit-service.ibm-kube-audit
   

7. 証明書が署名されるまでお待ちください

   kubectl wait \
       --for jsonpath='{.status.certificate}' \
       --output go-template='{{.status.certificate | base64decode}}' \
       --timeout 5m \
       csr/ibmcloud-kube-audit-service.ibm-kube-audit > server.crt
   

8. 証明書と秘密鍵から秘密鍵を作成する

   kubectl create secret tls \
       --cert server.crt \
       --key server.key \
       --namespace ibm-kube-audit \
       audit-webhook
   

9. 新しいシークレットを取得するためにデプロイを再起動してください。

   kubectl rollout restart --namespace ibm-kube-audit deploy/ibmcloud-kube-audit
   

10. 新しいポッドが利用可能になるまでお待ちください

    kubectl rollout status --timeout 1m --namespace ibm-kube-audit deploy/ibmcloud-kube-audit
    

11. 監査ウェブフックは、暗号化された接続を介してイベントを受信する準備が整いました。 「 Kubernetes API の監査ログを Cloud Logs に転送する 」セクションで監査 Webhook を設定する際は、 --remote-server URL の「 https 」バージョンを使用する必要があります：

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

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

   ibmcloud ks cluster config --cluster CLUSTER --admin
   

7. 認証局のステータスを確認する。 証明書の有効期限が迫っている場合は、手順に従って 証明書をローテーションして ください。

   ibmcloud ks cluster ca status -c CLUSTER
   

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 を構成し、ステップ 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]
    

11. クラスター内に監査 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
    

12. クラスター・マスターをリフレッシュして、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 マスターを再始動して、構成の更新を適用します。
   
   ```sh {: pre}
       ibmcloud ks cluster master refresh --cluster CLUSTER_NAME_OR_ID
       ```
   

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

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

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