IBM Cloud Docs
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

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. Ambos conjuntos de políticas pueden consultarse a continuación.

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

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

Reenvío de registros de auditoría de 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 imagen icr.io/ibm/ibmcloud-kube-audit-to-ibm-cloud-logs para reenviar registros a IBM Cloud Logs. Esta imagen es solo para fines de demostración. Para una solución de producción, configure y mantenga su propia imagen de reenvío de registro.

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 aplicación de servidor web de node.js HTTP simple que solo está expuesta en la red privada. 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 puede ver los registros.

Antes de comenzar: Asegúrese de que ha revisado las consideraciones y los requisitos previos y de que tiene el rol de acceso a la plataforma IAM de Administrador IBM Cloud 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 obtener más información sobre la imagen de la marca registrada ( kube-audit ), visite 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. 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
  - 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
              securityContext:
                allowPrivilegeEscalation: false
                runAsNonRoot: true
                capabilities:
                  drop:
                  - ALL
                seccompProfile:
                  type: RuntimeDefault
  - 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:
        - protocol: TCP
          port: 80
          targetPort: 3000
      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
        from:
        - namespaceSelector:
            matchLabels:
              kubernetes.io/metadata.name: kube-system
          podSelector:
            matchLabels:
              k8s-app: konnectivity-agent

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

    kubectl create -f ibmcloud-kube-audit.yaml

  5. Verifique que el pod ibmcloud-kube-audit-service tenga el STATUS Running.

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

    Salida de ejemplo

    NAME                                             READY   STATUS             RESTARTS   AGE
ibmcloud-kube-audit-c75cb84c5-qtzqd              1/1     Running   0          21s

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

  7. 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 en su equipo local. Estos archivos se utilizan más tarde para configurar el webhook de auditoría.

    ibmcloud ks cluster config --cluster <cluster> --admin

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

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

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

    kubectl 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 certificate-authority, client-certificatey client-key. certificate-authority se ha recuperado en el paso 8, y client-certificate y client-key se han recuperado en el paso anterior.

ibmcloud ks cluster master audit-webhook set --cluster CLUSTER --remote-server https://127.0.0.1:2040/api/v1/namespaces/ibm-kube-audit/services/ibmcloud-kube-audit-service/proxy/post --ca-cert CERTIFICATE-AUTHORITY --client-cert CLIENT-CERT --client-key CLIENT-KEY [--policy default|verbose]
  1. 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_ID>

Salida de ejemplo

Server:   https://127.0.0.1:2040/api/v1/namespaces/ibm-kube-audit/services/ibmcloud-kube-audit-service/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 ks cluster master refresh --cluster <cluster_name_or_ID>

  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. 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 kube-audit-to-logdna 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.

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 el servidor de consumidor de registros está aplicando una conexión segura (TLS), puede añadir los archivos de certificado a este directorio y cambiar la sección de programa de fondo en haproxy.cfg para utilizar estos archivos. Para obtener más información, consulte la documentación deHAProxy.

  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 que se llame 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. Crear la implementación y el servicio.

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

  5. Verifique que la implementación y el servicio de kube-audit-forwarder estén implementados en su 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

  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 en su equipo local. Estos archivos se utilizan más tarde para configurar el webhook de auditoría.

    ibmcloud ks cluster config --cluster <cluster> --admin

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

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

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

    kubectl 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

  9. 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 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]

  10. 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_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 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.

  1. Configure el webhook. Si no proporciona ninguna información en las opciones, se utilizará 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_ID> El nombre o ID del clúster.
    <server_URL> Un 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_path> La vía de acceso de archivo del certificado de CA que se utiliza para verificar el servicio de registro remoto.
    <client_cert_path> La vía de acceso de archivo del certificado de cliente que se utiliza para autenticarse en el servicio de registro remoto.
    <client_key_path> La vía de acceso de archivo de la clave de cliente correspondiente que se utiliza para conectarse al servicio de registro remoto.

  2. 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_ID>

    Salida de ejemplo

    OK
Server:            https://8.8.8.8

  3. Aplique la actualización de configuración reiniciando el maestro de Kubernetes.

    ibmcloud ks cluster master refresh --cluster <cluster_name_or_ID>

  4. Opcional: si desea detener el reenvío de registros de auditoría, puede inhabilitar su configuración.

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

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

      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, puedes buscar la métrica Kubernetes llamada apiserver_audit_error_total{plugin="webhook"} que indica si tu 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.