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.
Los registros de auditoría utilizan las siguientes políticas en el repositorioGitHub' IBM-Cloud/kube-samples. A partir de la versión 1.30,
las políticas se actualizaron para seguir de cerca las utilizadas por Red Hat para OpenShift. Aquí se enumeran ambos conjuntos de políticas:
No puede modificar la política predeterminada ni aplicar su propia política personalizada.
- Para obtener información sobre los registros de auditoría y el nivel de detalle de Kubernetes, consulta la documentación de Kubernetes.
- Solo se puede crear un webhook de auditoría en un clúster.
- Debe tener el rol de acceso de plataforma Administrador IBM Cloud IAM para el clúster IBM Cloud Kubernetes Service.
Para empezar, sigue las instrucciones para enviar los registros de auditoría de la API de Kubernetes a un recurso de la red privada IBM Cloud o a un servidor externo.
Reenvío de los registros de auditoría de la API de 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 pone a disposición
una sencilla aplicación de servidor web HTTP que solo está accesible desde 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 del servidor web a IBM Cloud Logs, donde se pueden consultar.
Antes de empezar: Asegúrate de haber revisado las consideraciones y los requisitos previos, y de que dispones del rol de acceso Administrador(IBM Cloud) a la plataforma IAM de IBM Cloud Logs.
-
Elija como destino el registro de contenedores global para las imágenes públicas de IBM Cloud.
ibmcloud cr region-set global -
Opcional: Para obtener más información sobre la imagen
kube-audit, consultaicr.io/ibm/ibmcloud-kube-audit-to-ibm-cloud-logs.ibmcloud cr image-inspect icr.io/ibm/ibmcloud-kube-audit-to-ibm-cloud-logs -
Configure su kubeconfig para acceder a su clúster con
ibmcloud ks cluster config -c CLUSTER -
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 una implementación que descarga laicr.io/ibm/ibmcloud-kube-audit-to-ibm-cloud-logsimagen 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 - 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 -
Crea la implementación en el espacio
ibm-kube-auditde nombres de tu clúster.kubectl apply -f ibmcloud-kube-audit.yaml -
Espere a que
ibmcloud-kube-auditla implementación alcance el estado Disponible.kubectl wait --for condition=Available --namespace ibm-kube-audit --timeout 5m deploy/ibmcloud-kube-auditSalida de ejemplo
deployment.apps/ibmcloud-kube-audit condition met -
Verifique que el servicio
ibmcloud-kube-audit-serviceesté desplegado en el clúster.kubectl get svc -n ibm-kube-audit -l app=ibmcloud-kube-auditSalida de ejemplo
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE ibmcloud-kube-audit-service ClusterIP 172.21.xxx.xxx <none> 80/TCP 1m -
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.
-
Compruebe el estado de la autoridad de certificación. Si sus certificados están a punto de caducar, siga los pasos para rotarlos.
ibmcloud ks cluster ca status -c CLUSTER -
Guarde el
certificate-authoritydel clúster en el archivocluster-ca.pem.ibmcloud ks cluster ca get -c CLUSTER --output json | jq -r .caCert | base64 -D > cluster-ca.pem -
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--adminopción para descargar los datosclient-certificatey losclient-keydatos a su equipo local. Estos datos se utilizan posteriormente para configurar el webhook de auditoría.ibmcloud ks cluster config --cluster CLUSTER --admin --output json > kubeconfig.jsonSi se elimina al propietario del archivo
kubeconfigo se le retiran los permisos, el servidor de la API de Kubernetes ya no podrá enviar registros de auditoría. Para evitar esta situación, recomendamos utilizar un ID de servicio para esta operación, ya que está vinculado directamente a la cuenta y no a un usuario concreto. -
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 -
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 -
Configure el webhook de auditoría y especifique
certificate-authority,client-certificateyclient-key. Elcertificate-authorityse recuperó en el paso 10 y elclient-certificateyclient-keyse recuperaron en los dos pasos anteriores. Opcionalmente, configure elpolicycon un valor diferente.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 defaultSi ha configurado HTTPS en el paso 8, establezca
remote-serveren su lugarhttpsURL:https://127.0.0.1:2040/api/v1/namespaces/ibm-kube-audit/services/https:ibmcloud-kube-audit-service:https/proxy/post -
Verifique que el webhook de auditoría se ha creado en el clúster.
ibmcloud ks cluster master audit-webhook get --cluster CLUSTERSalida 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 -
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 ks cluster master refresh --cluster CLUSTER -
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.
-
Ver el estado del clúster y esperar a que
Master Stateindiqueupdating, luego esperar al estadodeployed. Puede que tardes varios minutos en completarlo.ibmcloud ks cluster get -c CLUSTERSalida de ejemplo
... Master Status: Refresh in progress. (2 seconds ago) State: updating ... Master Status: Ready (2 seconds ago) State: deployed -
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.
Una vez que hayas configurado el webhook de auditoría en tu clúster, podrás 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 kubectl 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:
- La etiqueta de imagen
icr.io/ibm/ibmcloud-kube-audit-to-ibm-cloud-logs:latestrecibe actualizaciones de vulnerabilidad y corrección de errores. Sin embargo, la implementación debe reiniciarse manualmente para que se apliquen esos cambios. Utilicekubectl rollout restart -n ibm-kube-audit deploy/ibmcloud-kube-auditpara obtener la última imagen y reiniciar correctamente. - 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.
- El certificado generado en los siguientes pasos 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.
- 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 ) - Genera una clave privada y guárdala en
server.keyopenssl genrsa -out server.key 4096 - Genera un archivo de configuración de
server-csr.confsolicitud 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 - 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 - 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 - Aprobar la solicitud
kubectl certificate approve ibmcloud-kube-audit-service.ibm-kube-audit - 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 - 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 - Reinicie la implementación para recoger el nuevo secreto.
kubectl rollout restart --namespace ibm-kube-audit deploy/ibmcloud-kube-audit - Espera a que los nuevos pods estén disponibles
kubectl rollout status --timeout 1m --namespace ibm-kube-audit deploy/ibmcloud-kube-audit - 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 sección Reenvío de registros de auditoría de la API de Kubernetes a Cloud Logs,
debe utilizar la versión
httpsdel URL--remote-serveren 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.
-
Cree un nuevo directorio
kube-audit-forwardery cree un archivohaproxy.cfgen é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> checkSi 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.cfgpara usar estos archivos. Para más información, consulte la documentación de HAProxy. -
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 -
Crea un archivo de configuración con el nombre
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: vpnSi ha añadido archivos de certificado a
kube-audit-forwarderen el paso anterior, no olvide listar estos archivos en la secciónvolumeMountscomosubPath. -
Crea la implementación y el servicio.
kubectl create -f kube-audit-forwarder-remote-private-ip.yaml -
Comprueba que la implementación
kube-audit-forwardery el servicio estén implementados en tu clúster.kubectl get svc -n ibm-kube-auditSalida de ejemplo
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE ... kube-audit-forwarder ClusterIP 10.xxx.xx.xxx <none> 80/TCP 1mkubectl get deployment -n ibm-kube-auditSalida de ejemplo
NAME READY UP-TO-DATE AVAILABLE AGE ... kube-audit-forwarder 1/1 1 1 6m27s -
Inicie una sesión en la cuenta. If applicable, target the appropriate resource group. Establezca el contexto para el clúster. Asegúrate de especificar la opción
--adminpara descargar los archivosclient-keyyclient-certificateen tu equipo local. Estos archivos se utilizan más tarde para configurar el webhook de auditoría.ibmcloud ks cluster config --cluster CLUSTER --admin -
Compruebe el estado de la autoridad de certificación. Si sus certificados están a punto de caducar, siga los pasos para rotarlos.
ibmcloud ks cluster ca status -c CLUSTER -
Consulta el
certificate-authoritydel clúster y guárdalo en un archivo.ibmcloud ks cluster ca get -c CLUSTER --output json | jq -r .caCert | base64 -D > CERTIFICATE_AUTHORITY -
Visualice la configuración actual ejecutando el mandato
kubectl config viewy revise la salida declient-certificateyclient-key.kubectl config view --minifySalida 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 -
Configure el webhook de auditoría y especifique los
certificate-authority,client-certificateyclient-keyque ha recuperado en los pasos 5-7.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] -
Verifique que el webhook de auditoría se ha creado en el clúster.
ibmcloud ks cluster master audit-webhook get --cluster CLUSTER_NAME_OR_IDSalida de ejemplo
OK Server: https://127.0.0.1:2040/api/v1/namespaces/ibm-kube-audit/services/kube-audit-forwarder/proxy/post Policy: default -
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 ks 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.
Reenvío de registros de auditoría de API de Kubernetes a un servidor externo en Internet público
Para auditar los sucesos que se pasan a través del servidor de API de Kubernetes, puede crear una configuración que utilice Fluentd para reenviar sucesos a un servidor externo.
Antes de empezar, asegúrese de revisar las consideraciones y los requisitos previos. Tenga en cuenta que los filtros de registro no están soportados.
-
Configure el webhook. Si no se proporciona ninguna información en las opciones, se utiliza una configuración predeterminada.
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]Descripción de los componentes de este mandato Opción Descripción CLUSTER_NAME_OR_IDEl nombre o ID del clúster. SERVER_URLUn URL accesible públicamente o una dirección IP para el servicio de registro remoto al que desea enviar registros. Los certificados se ignoran si se proporciona un URL de servidor no seguro. CA_CERT_PATHLa vía de acceso de archivo del certificado de CA que se utiliza para verificar el servicio de registro remoto. CLIENT_CERT_PATHLa vía de acceso de archivo del certificado de cliente que se utiliza para autenticarse en el servicio de registro remoto. CLIENT_KEY_PATHLa vía de acceso de archivo de la clave de cliente correspondiente que se utiliza para conectarse al servicio de registro remoto. -
Verifique que el reenvío de registros se ha habilitado consultando el URL del servicio de registro remoto.
ibmcloud ks cluster master audit-webhook get --cluster CLUSTER_NAME_OR_IDSalida de ejemplo
OK Server: https://8.8.8.8 -
Aplique la actualización de configuración reiniciando el maestro de Kubernetes.
ibmcloud ks cluster master refresh --cluster CLUSTER_NAME_OR_ID -
Opcional: si desea detener el reenvío de registros de auditoría, puede inhabilitar su configuración.
- Para el clúster del que desea dejar de recopilar registros de auditoría de servidor de API: inicie sesión en la cuenta. If applicable, target the appropriate resource group. Establezca el contexto para el clúster.
- Inhabilite la configuración del programa de fondo del webhook para el servidor de API del clúster.
ibmcloud ks cluster master audit-webhook unset --cluster CLUSTER_NAME_OR_ID ``` 3. Aplique la actualización de configuración reiniciando el maestro de Kubernetes. ```sh {: pre} ibmcloud ks cluster master refresh --cluster CLUSTER_NAME_OR_ID ```
Gestión del reenvío de registros del servidor de API
Consulte Verificación, actualización y supresión del reenvío de registros.
Si observa errores al recuperar los registros de auditoría cuando han estado funcionando previamente, puede deberse a que la autoridad de certificación utilizada para los registros de auditoría haya caducado o rotado. Repita los pasos anteriores
para configurar un webhook y renovar el certificado. Además, puede buscar la métrica Kubernetes denominada apiserver_audit_error_total{plugin="webhook"} que indica si su certificado webhook ha caducado.
Registros de auditoría de servicio
De forma predeterminada, IBM Cloud Kubernetes Service 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.