Revisión de registros de servicio, de servidor de API y de nodo trabajador

Con los registros de auditoría, puede comprender mejor las operaciones iniciadas por los usuarios del clúster, lo que puede ayudarle a resolver problemas o a notificar la conformidad con los estándares internos y del sector.

Registros de auditoría del servidor de API de Kubernetes

Para supervisar la actividad administrativa de Kubernetes iniciada por el usuario que tiene lugar en el clúster, puede recopilar y reenviar sucesos de auditoría que se pasan a través del servidor de API de Kubernetes a IBM Cloud Logs o a un servidor externo.

Consideraciones y requisitos previos

Antes de configurar una configuración de auditoría de API de Kubernetes, revise la información siguiente.

  • Clusters VPC versiones 4.15 y posteriores: Los registros de auditoría utilizan el perfil de política de auditoría Red Hat OpenShift default (para predeterminado) y WriteRequestBodies(para detallado). Para obtener más información, consulte la Política de registro de auditoría.

  • Todas las demás versiones de clúster: los registros de auditoría utilizan la política openshift-audit en el kube-samples repositorio.

No puede modificar la política predeterminada ni aplicar su propia política personalizada.

Para empezar, siga las instrucciones para enviar los registros de auditoría de la API Kubernetes a un recurso de la red privada IBM Cloud.

Reenvío de los registros de auditoría de la API Kubernetes a Cloud Logs

Para reenviar registros de auditoría a IBM Cloud Logs, puede crear un sistema de auditoría de Kubernetes utilizando la imagen y el despliegue proporcionados.

El siguiente ejemplo utiliza la icr.io/ibm/ibmcloud-kube-audit-to-ibm-cloud-logs imagen para reenviar registros a IBM Cloud Logs. Si solo necesita una prueba de concepto, puede omitir el paso de configuración segura. Para obtener una solución más automatizada, configure y mantenga su propia imagen de reenvío de registros.

Anteriormente, se utilizaba icr.io/ibm/ibmcloud-kube-audit-to-logdna para reenviar registros. Esta imagen está obsoleta y el soporte finaliza pronto. Actualice la configuración de reenvío de registro para utilizar icr.io/ibm/ibmcloud-kube-audit-to-ibm-cloud-logs en su lugar.

El sistema de auditoría de Kubernetes en el clúster consta de un webhook de auditoría, un servicio de recopilación de registros, una aplicación de servidor web y un agente de registro. El webhook recopila los sucesos del servidor de API de Kubernetes del nodo maestro del clúster. El servicio de recopilación de registros es un servicio ClusterIP de Kubernetes que se crea an partir de una imagen del registro público de IBM Cloud. Este servicio expone una sencilla aplicación de servidor web HTTP que sólo está expuesta en la red del clúster. La aplicación de servidor web analiza los datos de registro del webhook de auditoría y crea cada registro como una línea JSON exclusiva. Por último, el agente de registro reenvía los registros de la aplicación de servidor web a IBM Cloud Logs, donde puede ver los registros.

Antes de comenzar: Asegúrese de que ha revisado las consideraciones y los requisitos previos y de que dispone del rol de acceso a la plataforma Administrador IBM Cloud IAM para IBM Cloud Logs.

  1. Elija como destino el registro de contenedores global para las imágenes públicas de IBM Cloud.

    ibmcloud cr region-set global

  2. Opcional: Para más información sobre la imagen kube-audit, inspeccione 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. Configure su kubeconfig para acceder a su clúster con

    ibmcloud ks cluster config -c <cluster>

  4. Cree un archivo de configuración denominado ibmcloud-kube-audit.yaml. Este archivo de configuración crea un servicio de recopilación de registros y un despliegue que extrae la imagen icr.io/ibm/ibmcloud-kube-audit-to-ibm-cloud-logs para crear un contenedor de recopilación de registros.

    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

  5. Cree la implantación en el espacio de nombres ibm-kube-audit de su clúster.

    kubectl apply -f ibmcloud-kube-audit.yaml

  6. Espere a que ibmcloud-kube-audit la implementación alcance el estado Disponible.

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

    Salida de ejemplo

    deployment.apps/ibmcloud-kube-audit condition met

  7. Verifique que el servicio ibmcloud-kube-audit-service esté desplegado en el clúster.

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

    Salida de ejemplo

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

  8. Cifre el tráfico en tránsito con HTTPS. Si solo necesita un reenviador de registros de auditoría de prueba de concepto, omita este paso.

  9. Compruebe el estado de la autoridad de certificación. Si sus certificados están a punto de caducar, siga los pasos para rotarlos.

    ibmcloud oc cluster ca status -c <cluster>

  10. Guarde el certificate-authority del clúster en el archivo cluster-ca.pem.

ibmcloud oc cluster ca get -c <cluster> --output json | jq -r .caCert | base64 -D > cluster-ca.pem
  1. Inicie una sesión en la cuenta. If applicable, target the appropriate resource group. Establezca el contexto para el clúster. Prepare un kubeconfig basado en certificados y guárdelo en kubeconfig.json. Asegúrese de especificar la --admin opción para descargar los datos client-certificate y los client-key datos a su equipo local. Estos datos se utilizan posteriormente para configurar el webhook de auditoría.
ibmcloud oc cluster config --cluster <cluster> --admin --output json > kubeconfig.json
  1. Extraiga el certificado de cliente de kubeconfig al archivo kubeconfig-cert.pem.
jq -r '.users[].user."client-certificate-data"' kubeconfig.json | base64 -D > kubeconfig-cert.pem
  1. Extraiga la clave de cliente de kubeconfig al archivo kubeconfig-key.pem.
jq -r '.users[].user."client-key-data"' kubeconfig.json | base64 -D > kubeconfig-key.pem
  1. Configure el webhook de auditoría y especifique certificate-authority, client-certificatey client-key. El certificate-authority se recuperó en el paso 10 y el client-certificate y client-key se recuperaron en los dos pasos anteriores. Opcionalmente, configure el policy con un valor diferente.
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

Si ha configurado HTTPS en el paso 8, establezca remote-server en su lugar https URL:

https://127.0.0.1:2040/api/v1/namespaces/ibm-kube-audit/services/https:ibmcloud-kube-audit-service:https/proxy/post
  1. Verifique que el webhook de auditoría se ha creado en el clúster.
ibmcloud oc cluster master audit-webhook get --cluster <cluster>

Salida de ejemplo

Server:   https://127.0.0.1:2040/api/v1/namespaces/ibm-kube-audit/services/http:ibmcloud-kube-audit-service:http/proxy/post
Policy:   default
  1. Aplique el webhook a su servidor de API de Kubernetes renovando el nodo maestro del clúster. El nodo maestro puede tardar unos minutos en renovarse.
ibmcloud oc cluster master refresh --cluster <cluster>

  1. Mientras se renueva el nodo maestro, suministre una instancia de IBM Cloud Logs y despliegue un agente de registro en cada nodo trabajador del clúster. El agente de registro se necesita para reenviar registros internos del clúster al servicio IBM Cloud Logs. Si ya ha configurado agentes de registro en el clúster, puede saltarse este paso.

  2. Ver el estado del clúster y esperar a que Master State indique updating, luego esperar al estado deployed. Puede tardar varios minutos en completarse.

ibmcloud ks cluster get -c <cluster>

Salida de ejemplo

...
Master
Status:     Refresh in progress. (2 seconds ago)
State:      updating
...
Master
Status:     Ready (2 seconds ago)
State:      deployed
  1. Cuando finalice la renovación del nodo maestro y los agentes de registro se ejecuten en los nodos trabajadores, puede ver los registros de auditoría de API de Kubernetes en IBM Cloud Logs.

Después de configurar el webhook de auditoría en su clúster, puede supervisar las actualizaciones de versión de la imagen ibmcloud-kube-audit-to-ibm-cloud-logs ejecutando ibmcloud cr image-list --include-ibm | grep ibmcloud-kube-audit-to-ibm-cloud-logs. Para ver la versión de la imagen que se ejecuta actualmente en el clúster, ejecute oc get pods | grep ibmcloud-kube-audit-to-ibm-cloud-logs para buscar el nombre del pod de auditoría y ejecute kubectl describe pod <pod_name> para ver la versión de la imagen. Actualiza el pod a la última versión disponible en la etiqueta actual con kubectl rollout restart --namespace ibm-kube-audit deploy/ibmcloud-kube-audit y espera a que los nuevos pods estén disponibles con kubectl rollout status --timeout 1m --namespace ibm-kube-audit deploy/ibmcloud-kube-audit.

Gestione las actualizaciones, rote los certificados y cifre los datos en tránsito con HTTPS

Algunas cosas importantes que hay que tener en cuenta antes de preparar el reenvío de registros:

  1. La etiqueta de imagen icr.io/ibm/ibmcloud-kube-audit-to-ibm-cloud-logs:latest recibe actualizaciones de vulnerabilidad y corrección de errores. Sin embargo, la implementación debe reiniciarse manualmente para que se apliquen esos cambios. Utilice kubectl rollout restart -n ibm-kube-audit deploy/ibmcloud-kube-audit para descargar la última imagen y reiniciar correctamente.
  2. Esta implementación se instala y gestiona manualmente. Cambiar de esta implementación a otra puede provocar un tiempo de inactividad en el registro de auditoría.
  3. El certificado generado a continuación se puede rotar. La rotación requiere pasos manuales para reemplazar el secreto y reiniciar la implementación.

Para asegurar el despliegue con encriptación en tránsito, se requiere una clave privada y un certificado TLS firmado por el kube-apiserver.

  1. Después de aplicar el archivo YAML en el paso 4, espere a que el recurso de servicio rellene la IP del clúster. Guárdalo en la variable de shell $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. Genera una clave privada y guárdala en server.key
    openssl genrsa -out server.key 4096
  3. Genera un archivo de configuración de server-csr.conf solicitud de firma de certificado. Esto se utiliza para generar el certificado que firmará 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. Genere la carga útil de la solicitud de firma de certificado para que Kubernetes la firme.
    openssl req -new -config server-csr.conf -key server.key -out server.csr
  5. Inserte la carga útil en un recurso CSR (solicitud de certificado) de KubernetesCertificateSigningRequest
    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. Aprobar la solicitud
    kubectl certificate approve ibmcloud-kube-audit-service.ibm-kube-audit
  7. Espere a que se firme el certificado
    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. Crear un secreto a partir del certificado y la clave privada
    kubectl create secret tls \
    --cert server.crt \
    --key server.key \
    --namespace ibm-kube-audit \
    audit-webhook
  9. Reinicie la implementación para recoger el nuevo secreto.
    kubectl rollout restart --namespace ibm-kube-audit deploy/ibmcloud-kube-audit
  10. Espera a que los nuevos pods estén disponibles
kubectl rollout status --timeout 1m --namespace ibm-kube-audit deploy/ibmcloud-kube-audit
  1. El webhook de auditoría ya está listo para recibir eventos a través de una conexión cifrada. Al configurar el webhook de auditoría en la guía completa anterior, debe utilizar la https versión de --remote-server URL en su lugar:
https://127.0.0.1:2040/api/v1/namespaces/ibm-kube-audit/services/https:ibmcloud-kube-audit-service:https/proxy/post`

Reenvío de registros de auditoría de API de Kubernetes a un recurso de la red privada de IBM Cloud

Reenvíe registros de auditoría a un recurso distinto de IBM Cloud Logs que está fuera de su clúster y accesible en la red privada de IBM Cloud.

El ejemplo siguiente utiliza la imagen haproxytech/haproxy-alpine:2.6 para reenviar registros. Esta imagen es sólo para fines de demostración y no debe utilizarse en entornos de producción. Para una solución de producción, configure y mantenga su propia imagen de reenvío de registro.

Antes de empezar, asegúrese de revisar las consideraciones y los requisitos previos.

  1. Cree un nuevo directorio kube-audit-forwarder y cree un archivo haproxy.cfg en él con el contenido siguiente. No olvide sustituir <REMOTE-IP>:<REMOTE-PORT> en el archivo por la dirección IP y el puerto del consumidor de registro remoto.

    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

    Si tu servidor de consumo de logs impone una conexión segura ( TLS ), puedes añadir tus archivos de certificado a este directorio y cambiar la sección backend en haproxy.cfg para usar estos archivos. Para más información, consulte la documentación de HAProxy.

  2. Cree un configmap a partir del contenido del directorio kube-audit-forwarder.

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

  3. Cree un archivo de configuración llamado kube-audit-forwarder-remote-private-ip.yaml. Este archivo de configuración crea un despliegue y un servicio que reenvía registros de auditoría del clúster a la dirección IP del recurso remoto a través de la red privada IBM Cloud.

    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

    Si ha añadido archivos de certificado a kube-audit-forwarder en el paso anterior, no olvide listar estos archivos en la sección volumeMounts como subPath.

  4. Cree el despliegue y el servicio.

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

  5. Verifique que el despliegue y el servicio kube-audit-forwarder están desplegados en su cluster.

    kubectl get svc -n ibm-kube-audit

    Salida de ejemplo

    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

    Salida de ejemplo

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

  6. Inicie una sesión en la cuenta. If applicable, target the appropriate resource group. Establezca el contexto para el clúster. Asegúrese de especificar la opción --admin para descargar los archivos client-certificate y client-key a su máquina local. Estos archivos se utilizan más tarde para configurar el webhook de auditoría.

    ibmcloud oc cluster config --cluster <cluster> --admin

  7. Compruebe el estado de la autoridad de certificación. Si sus certificados están a punto de caducar, siga los pasos para rotarlos.

    ibmcloud oc cluster ca status -c CLUSTER

  8. Consulta la certificate-authority del clúster y la guarda en un archivo.

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

  9. Visualice la configuración actual ejecutando el mandato oc config view y revise la salida de client-certificate y client-key.

    oc config view --minify

    Salida de ejemplo

    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. Configure el webhook de auditoría y especifique los certificate-authority, client-certificate y client-key que ha recuperado en los pasos 5-7.

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]
  1. Verifique que el webhook de auditoría se ha creado en el clúster.
ibmcloud oc cluster master audit-webhook get --cluster <cluster_name_or_ID>

Salida de ejemplo

OK
Server:            https://127.0.0.1:2040/api/v1/namespaces/ibm-kube-audit/services/kube-audit-forwarder/proxy/post
Policy:            default
  1. Aplique el webhook a su servidor de API de Kubernetes renovando el nodo maestro del clúster. El maestro puede tardar varios minutos en renovarse.
ibmcloud oc cluster master refresh --cluster <cluster_name_or_ID>

Una vez finalizada la renovación del maestro, los registros se envían a la dirección IP privada del recurso de registro.

Registros de auditoría de nodo trabajador

Red Hat OpenShift on IBM Cloud utiliza el componente de Linux Auditing System, auditd, para supervisar y registrar la actividad en los nodos de trabajador. Aunque la auditoría del nodo trabajador está activada por defecto, no se dispone de datos de auditoría hasta que se configura el reenvío de registros a una instancia de IBM Cloud Logs o a un servidor externo.

Visión general de la configuración de auditoría de nodo trabajador

Los registros se almacenan en el directorio /var/log/audit en los nodos trabajadores. Puede ver los registros en IBM Cloud Logs o en el servidor externo después de configurar el reenvío de registros.

Auditd recopila registros en varios sucesos, incluidos los siguientes:

  • Llamadas al sistema Linux (syscalls)
  • Denegaciones de SELinux
  • Modificaciones de política de SELinux
  • Modificaciones de software mediante el instalador del paquete yum
  • Operaciones de Systemd
  • Modificaciones de grupo y de usuario de Linux
  • Modificaciones de cambios de Netfilter
  • Inicios de sesión de SSH

Configuración del reenvío de registros para nodos trabajadores

Consulte Reenvío de registros a una instancia de IBM Cloud Logs..

Registros de auditoría de servicio

De forma predeterminada, Red Hat OpenShift on IBM Cloud genera y envía sucesos a IBM Cloud Logs. Para ver estos sucesos, debe crear una instancia de IBM Cloud Logs. Para obtener más información, consulte Sucesos de IBM Cloud Logs.

Visualización de alertas de AuditWebhookError en clústeres habilitados para auditoría

Red Hat OpenShift on IBM Cloud la versión clusters tiene una alerta AuditWebhookError que se dispara cuando el webhook de auditoría se bloquea o se elimina.

Para ver la alerta:

Inicie una sesión en la cuenta. If applicable, target the appropriate resource group. Establezca el contexto para el clúster.

  1. En Red Hat OpenShift on IBM Cloud, seleccione la vista Administrador.
  2. Pulse Observar > Alerta > AuditWebhookError.
  3. Para crear una notificación para esta alerta, consulte Envío de notificaciones a sistemas externos.