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 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 de Administrador IBM Cloud IAM para el clúster Red Hat OpenShift on IBM Cloud.

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.

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, consulta icr.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 la icr.io/ibm/ibmcloud-kube-audit-to-ibm-cloud-logs imagen 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

Crea la implementación en el espacio ibm-kube-audit de nombres de tu clúster.
```
kubectl apply -f ibmcloud-kube-audit.yaml
```

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

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

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 oc cluster ca status -c CLUSTER
```

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

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
```
Si se elimina al propietario del archivo kubeconfig o 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-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

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

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
```
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 State indique updating, luego esperar al estado deployed. Puede que tardes varios minutos en completarlo.

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

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 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:

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.
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.key
```
openssl genrsa -out server.key 4096
```

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

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, debes utilizar la versión https del URL--remote-server 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.

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.

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: 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.

Crea la implementación y el servicio.

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

Comprueba que la implementación kube-audit-forwarder y el servicio estén implementados en tu clúster.

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

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 --admin para descargar los archivos client-key y client-certificate en tu equipo local. Estos archivos se utilizan más tarde para configurar el webhook de auditoría.
```
ibmcloud oc 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 oc cluster ca status -c CLUSTER
```

Consulta el certificate-authority del clúster y guárdalo en un archivo.

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

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

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]

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

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 de los nodos de trabajo está habilitada de forma predeterminada, no hay datos de auditoría disponibles hasta que se configure 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 de clústeres cuenta con una alerta AuditWebhookError que se activa cuando el webhook de auditoría falla 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.

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

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

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

Registros de auditoría del servidor de API de Kubernetes

Consideraciones y requisitos previos

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

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

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

Registros de auditoría de nodo trabajador

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

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

Registros de auditoría de servicio

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

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