サービス、API サーバー、およびワーカー・ノードのログの確認

監査ログを使用すると、クラスター内のユーザーによって開始された操作の理解を深めることができます。これは、問題のトラブルシューティングや、業界標準および内部標準への準拠の報告に役立ちます。

Kubernetes API サーバーの監査ログ

ユーザーによって開始された、クラスター内で作成された Kubernetes 管理アクティビティーをモニターするには、Kubernetes API サーバーから渡される監査イベントを収集して IBM Cloud Logs または外部サーバーに転送します。

考慮事項と前提条件

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

VPCクラスタのバージョン 4.15 以降 ：監査ログは、 Red Hat OpenShift 監査ポリシープロファイル default (デフォルト) および WriteRequestBodies(詳細) を使用します。詳しくは、監査ログ・ポリシーを参照してください。
その他のすべてのクラスター・バージョン: 監査ログは、 kube-samples repoの openshift-audit ポリシーを使用します。

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

Kubernetes の監査ログおよび詳細レベルについては、『 Kubernetes 』のドキュメントを参照してください。
1 つのクラスターに作成できる監査 Web フックは 1 つだけです。
Red Hat OpenShift on IBM Cloud クラスターの 管理者 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プラットフォームの 「管理者」 アクセスロールが割り当てられていることを確認してください。

パブリック IBM Cloud イメージのグローバル・コンテナー・レジストリーをターゲットとして設定します。
```
ibmcloud cr region-set global
```
（参考）： 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
```
クラスタにアクセスするために kubeconfig を設定してください
```
ibmcloud ks cluster config -c CLUSTER
```

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
        security.openshift.io/scc.podSecurityLabelSync: "false"
  - 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:
              app: konnectivity-agent
        - namespaceSelector:
            matchLabels:
              kubernetes.io/metadata.name: kube-system
          podSelector:
            matchLabels:
              app: vpn

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

デプロイメント 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

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

HTTPS で通信中のトラフィックを暗号化します。概念実証用の監査ログ転送ツールのみが必要な場合は、この手順をスキップしてください。
認証局のステータスを確認する。証明書の有効期限が迫っている場合は、手順に従って証明書をローテーションしてください。
```
ibmcloud oc cluster ca status -c CLUSTER
```

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

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

アカウントにログインします。該当する場合は、適切なリソース・グループをターゲットにします。クラスターのコンテキストを設定します。証明書ベースのkubeconfigを準備し、. kubeconfig.json に保存します。オプション --admin を指定して、データ client-key``client-certificate とデータをローカルマシンにダウンロードしてください。このデータは後で監査ウェブフックの設定に使用されます。
```
ibmcloud oc cluster config --cluster CLUSTER --admin --output json > kubeconfig.json
```
kubeconfig の所有者が削除されたり、その権限が取り消されたりすると、Kubernetes API サーバーは監査ログを送信できなくなります。このような事態を防ぐため、この操作にはサービスIDを使用することをお勧めします。サービスIDは特定のユーザーではなく、アカウントに直接紐づいているためです。

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

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

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

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

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

ibmcloud oc 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

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

ibmcloud oc 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

クラスター・マスターをリフレッシュして、Web フックを Kubernetes API サーバーに適用します。マスターがリフレッシュされるまで数分かかることがあります。
```
ibmcloud oc cluster master refresh --cluster CLUSTER
```
マスターがリフレッシュされている間に、IBM Cloud Logs のインスタンスをプロビジョンし、クラスター内のすべてのワーカー・ノードにロギング・エージェントをデプロイします。ロギング・エージェントは、クラスター内部から IBM Cloud Logs サービスにログを転送するために必要です。クラスター内に既にロギング・エージェントをセットアップしている場合は、この手順をスキップできます。
クラスタの状態を確認し、が 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
```
マスターのリフレッシュが完了し、ワーカー・ノードでロギング・エージェントが実行されていれば、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 イメージのバージョン更新状況を監視できます。クラスター内で現在実行されているイメージのバージョンを確認するには、oc 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 による更新管理、証明書のローテーション、転送中の暗号化

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

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

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

ステップ 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
)

秘密鍵を生成し、保存する server.key
```
openssl genrsa -out server.key 4096
```

証明書署名要求（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

Kubernetes が署名するための証明書署名要求ペイロードを生成します。
```
openssl req -new -config server-csr.conf -key server.key -out server.csr
```

ペイロードを 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

リクエストを承認する

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

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

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

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

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

新しいシークレットを取得するためにデプロイを再起動してください。
```
kubectl rollout restart --namespace ibm-kube-audit deploy/ibmcloud-kube-audit
```

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

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

監査ウェブフックは、暗号化された接続を介してイベントを受信する準備が整いました。「 Kubernetes API の監査ログを Cloud Logs に転送する」セクションで監査 Webhook を設定する際は、代わりに https バージョンの --remote-server URL を使用する必要があります：
```
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 イメージを使用してログを転送します。このイメージはデモンストレーション専用であり、実稼働環境では使用しないでください。実動ソリューションの場合は、独自のログ転送イメージを構成して保守します。

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

新規ディレクトリー 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 のドキュメントを参照。

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

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 セクションにリストすることを忘れないでください。

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

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

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

アカウントにログインします。該当する場合は、適切なリソース・グループをターゲットにします。クラスターのコンテキストを設定します。 --admin オプションを必ず指定して、 client-certificate および client-key ファイルをローカルマシンにダウンロードしてください。これらのファイルは、後で監査 Web フックを構成するために使用されます。
```
ibmcloud oc cluster config --cluster CLUSTER --admin
```
認証局のステータスを確認する。証明書の有効期限が迫っている場合は、手順に従って証明書をローテーションしてください。
```
ibmcloud oc cluster ca status -c CLUSTER
```

クラスタの certificate-authority を取得し、ファイルに保存します。

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

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

oc 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

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

ibmcloud oc 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]

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

ibmcloud oc 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

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

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

ワーカー・ノードの監査ログ

Red Hat OpenShift on IBM Cloud は、Linux 監査システム・コンポーネント auditd を使用して、ワーカー・ノードのアクティビティーをモニターし、ログに記録します。ワーカーノードの監査機能はデフォルトで有効になっていますが、 IBM Cloud Logs インスタンスまたは外部サーバーへのログ転送を設定するまでは、監査データは利用できません。

ワーカー・ノードの監査構成について

ログは、ワーカー・ノードの /var/log/audit ディレクトリーに保管されます。ログ転送をセットアップしたら、IBM Cloud Logs または外部サーバーでログを表示できます。

Auditd は、以下のようなさまざまなイベントに関するログを収集します。

Linux システム・コール (syscalls)
SELinux の拒否
SELinux ポリシーの変更
yum パッケージ・インストーラーによるソフトウェアの変更
Systemd オペレーション
Linux ユーザーおよびグループの変更
Netfilter 変更
SSH ログイン

ワーカー・ノードのログ転送のセットアップ

Forwarding logs to an IBM Cloud Logs instance を参照してください。

サービスの監査ログ

デフォルトでは、Red Hat OpenShift on IBM Cloud でイベントが生成されて IBM Cloud Logs に送信されます。これらのイベントを表示するには、IBM Cloud Logs インスタンスを作成する必要があります。詳しくは、IBM Cloud Logs イベントを参照してください。

監査対応クラスターでの `AuditWebhookError` アラートの表示

Red Hat OpenShift on IBM Cloud Clusters バージョンには、監査 Webhook がクラッシュしたり削除されたりした際に発動する「 AuditWebhookError 」アラートがあります。

アラートを表示するには以下のようにします。

アカウントにログインします。該当する場合は、適切なリソース・グループをターゲットにします。クラスターのコンテキストを設定します。

Red Hat OpenShift on IBM Cloudから、**「管理者」**ビューを選択します。
「監視」>「アラート」>**「AuditWebhookError」**をクリックします。
このアラートの通知を作成するには、外部システムへの通知の送信を参照してください。

サービス、API サーバー、およびワーカー・ノードのログの確認

サービス、API サーバー、およびワーカー・ノードのログの確認

Kubernetes API サーバーの監査ログ

考慮事項と前提条件

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

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

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

ワーカー・ノードの監査ログ

ワーカー・ノードの監査構成について

ワーカー・ノードのログ転送のセットアップ

サービスの監査ログ

監査対応クラスターでの AuditWebhookError アラートの表示

監査対応クラスターでの `AuditWebhookError` アラートの表示