Revisione dei log di servizio, server API e nodo di lavoro

Con i log di controllo, sei in grado di comprendere meglio quali operazioni vengono avviate dagli utenti nel tuo cluster, che possono aiutarti a risolvere i problemi o a segnalare la conformità agli standard di settore e interni.

Kubernetes Log di controllo del server API

Per monitorare le attività amministrative avviate dall'utente Kubernetes all'interno del cluster, è possibile raccogliere e inoltrare gli eventi di audit che vengono trasmessi attraverso il server Kubernetes API a un IBM Cloud Logs server esterno.

Considerazioni e prerequisiti

Prima di configurare una configurazione di controllo API Kubernetes, esamina le seguenti informazioni.

  • Cluster VPC versioni 4.15 e successive: I registri di audit utilizzano il profilo dei criteri di audit Red Hat OpenShift default (per default) e WriteRequestBodies(per verbose). Per ulteriori informazioni, consultare la Politica del log di verifica.

  • Tutte le altre versioni di cluster: i log di verifica utilizzano la politica openshift-audit nel Repository kube-samples.

Non è possibile modificare la politica predefinita né applicare una politica personalizzata.

Per iniziare, segui le istruzioni per inviare i Kubernetes a una risorsa nella rete privata IBM Cloud.

Inoltro dei log di audit dell'API di " Kubernetes " a Cloud Logs

Per inoltrare i log di audit a IBM Cloud Logs, è possibile creare un sistema di audit Kubernetes utilizzando l'immagine e la configurazione fornite.

L'esempio seguente utilizza l'immagine icr.io/ibm/ibmcloud-kube-audit-to-ibm-cloud-logs per inoltrare i log a IBM Cloud Logs. Se hai solo bisogno di una prova di concetto, puoi saltare la fase di configurazione sicura. Per una soluzione più automatizzata, configura e mantieni la tua immagine di inoltro dei log.

In precedenza, per inoltrare i registri veniva utilizzato l' icr.io/ibm/ibmcloud-kube-audit-to-logdna. Questa immagine è obsoleta e il supporto terminerà presto. Aggiorna la configurazione dell'inoltro dei log per utilizzare invece l' icr.io/ibm/ibmcloud-kube-audit-to-ibm-cloud-logs.

Il sistema di audit di Kubernetes nel tuo cluster è costituito da un webhook di audit, un servizio di raccolta dei log e un'applicazione server web, oltre a un agente di registrazione. Il webhook raccoglie gli eventi server API Kubernetes dal tuo master cluster. Il servizio di raccolta dei log è un servizio ClusterIP Kubernetes creato da un'immagine dal registro IBM Cloud pubblico. Questo servizio mette a disposizione una semplice applicazione web HTTP, accessibile esclusivamente dalla rete del cluster. L'applicazione del server web analizza i dati di log provenienti dal webhook di audit e crea ogni voce di log come una riga JSON univoca. Infine, l'agente di registrazione inoltra i log dall'applicazione del server web all'indirizzo IBM Cloud Logs, dove è possibile visualizzarli.

Prima di iniziare: Assicurati di aver esaminato le considerazioni e i prerequisiti e di avere il ruolo di accesso alla piattaforma IAM di Administrator IBM Cloud per IBM Cloud Logs.

  1. Indica come destinazione il registro del contenitore globale per le immagini IBM Cloud pubbliche.

    ibmcloud cr region-set global

  2. Facoltativo: per ulteriori informazioni sull'immagine " kube-audit ", consultare 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. Configura il tuo kubeconfig per accedere al tuo cluster con

    ibmcloud ks cluster config -c CLUSTER

  4. Crea un file di configurazione denominato “ ibmcloud-kube-audit.yaml ”. Questo file di configurazione crea un servizio di raccolta dei log e una distribuzione che scarica l'immagine icr.io/ibm/ibmcloud-kube-audit-to-ibm-cloud-logs per creare un container di raccolta dei log.

    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. Crea la distribuzione nello spazio dei nomi " ibm-kube-audit " del tuo cluster.

    kubectl apply -f ibmcloud-kube-audit.yaml

  6. Attendere che la ibmcloud-kube-audit distribuzione raggiunga lo stato Disponibile.

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

    Output di esempio

    deployment.apps/ibmcloud-kube-audit condition met

  7. Verifica che il servizio ibmcloud-kube-audit-service sia distribuito nel tuo cluster.

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

    Output di esempio

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

  8. Crittografa il traffico in transito con HTTPS. Se hai solo bisogno di un forwarder di log di audit di prova, salta questo passaggio.

  9. Controllare lo stato dell'autorità di certificazione. Se i vostri certificati sono prossimi alla scadenza, seguite la procedura di rotazione dei certificati.

    ibmcloud oc cluster ca status -c CLUSTER

  10. Salva il certificate-authority del cluster nel file cluster-ca.pem.

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

  11. Accedi al tuo account. Se applicabile, specifica il gruppo di risorse appropriato. Imposta il contesto per il tuo cluster. Prepara un kubeconfig basato su certificato e salvalo in kubeconfig.json. Assicurati di specificare --admin l'opzione per scaricare i client-key dati client-certificate e sul tuo computer locale. Questi dati vengono utilizzati in seguito per configurare il webhook di audit.

    ibmcloud oc cluster config --cluster CLUSTER --admin --output json > kubeconfig.json

    Se il proprietario del file kubeconfig viene rimosso o se i suoi permessi vengono revocati, il server API di Kubernetes non sarà più in grado di inviare i log di audit. Per evitare che si verifichi questa situazione, consigliamo di utilizzare un ID servizio per questa operazione, poiché è direttamente associato all'account e non a un utente specifico.

  12. Estrai il certificato client di kubeconfig nel file kubeconfig-cert.pem.

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

  13. Estrai la chiave client di kubeconfig nel file kubeconfig-key.pem.

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

  14. Configurare il webhook di controllo e specificare certificate-authority, client-certificate e client-key. Il certificate-authority è stato recuperato nel passaggio 10 e il client-certificate e client-key il sono stati recuperati nei due passaggi precedenti. Se lo desideri, puoi impostare policy un valore diverso.

    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

    Se hai configurato HTTPS al punto 8, imposta invece remote-server su questo https URL:

    https://127.0.0.1:2040/api/v1/namespaces/ibm-kube-audit/services/https:ibmcloud-kube-audit-service:https/proxy/post

  15. verifica che il webhook di controllo sia creato nel tuo cluster.

    ibmcloud oc cluster master audit-webhook get --cluster CLUSTER

    Output di esempio

    Server:   https://127.0.0.1:2040/api/v1/namespaces/ibm-kube-audit/services/http:ibmcloud-kube-audit-service:http/proxy/post
Policy:   default

  16. Applica il webhook al tuo server API Kubernetes aggiornando il master cluster. L'aggiornamento del master potrebbe richiedere alcuni minuti.

    ibmcloud oc cluster master refresh --cluster CLUSTER

  17. Mentre viene eseguito l'aggiornamento del master, esegui il provisioning di un'istanza di IBM Cloud Logs e distribuisci un evento di registrazione a ogni nodo di lavoro nel tuo cluster. L'agent di registrazione è richiesto per inoltrare i log dall'interno del tuo cluster al servizio IBM Cloud Logs. Se già hai configurato gli agent di registrazione nel tuo cluster, puoi tralasciare questo passo.

  18. Visualizza lo stato del cluster e attendi che Master State indichi updating, quindi attendi lo stato deployed. Potrebbero essere necessari alcuni minuti per completare l'operazione.

    ibmcloud ks cluster get -c CLUSTER

    Output di esempio

    ...
Master
Status:     Refresh in progress. (2 seconds ago)
State:      updating
...
Master
Status:     Ready (2 seconds ago)
State:      deployed

  19. Dopo che l'aggiornamento del master è stato completato e gli agent di registrazione sono in esecuzione sui tuoi nodi di lavoro, puoi visualizzare i tuoi log di controllo API Kubernetes in IBM Cloud Logs.

Dopo aver configurato il webhook di controllo nel cluster, puoi monitorare gli aggiornamenti della versione all'immagine ibmcloud-kube-audit-to-ibm-cloud-logs eseguendo ibmcloud cr image-list --include-ibm | grep ibmcloud-kube-audit-to-ibm-cloud-logs. Per visualizzare la versione dell'immagine attualmente eseguita nel cluster, esegui oc get pods | grep ibmcloud-kube-audit-to-ibm-cloud-logs per trovare il nome del pod di verifica ed esegui kubectl describe pod <pod_name> per vedere la versione dell'immagine. Aggiorna il pod all'ultima versione disponibile sul tag corrente con kubectl rollout restart --namespace ibm-kube-audit deploy/ibmcloud-kube-audit e attendi che i nuovi pod siano disponibili con kubectl rollout status --timeout 1m --namespace ibm-kube-audit deploy/ibmcloud-kube-audit.

Gestisci gli aggiornamenti, ruota i certificati e crittografa i dati in transito con HTTPS

Alcune cose importanti da tenere presente prima di prepararsi a inoltrare i log:

  1. Il tag immagine icr.io/ibm/ibmcloud-kube-audit-to-ibm-cloud-logs:latest riceve aggiornamenti relativi a vulnerabilità e correzioni di bug. Tuttavia, l'implementazione deve essere riavviata manualmente per rilevare tali modifiche. Utilizzare kubectl rollout restart -n ibm-kube-audit deploy/ibmcloud-kube-audit per scaricare l'immagine più recente e riavviare correttamente.
  2. Questa distribuzione viene installata e gestita manualmente. Il passaggio da questa distribuzione a un'altra potrebbe causare un'interruzione del registro di controllo.
  3. Il certificato generato nei passaggi seguenti può essere sottoposto a rotazione. La rotazione richiede passaggi manuali per sostituire il segreto e riavviare la distribuzione.

Per proteggere la distribuzione con la crittografia in transito, sono necessari una chiave privata e un certificato TLS firmato da kube-apiserver.

  1. Dopo aver applicato il file YAML al punto 4, attendere che la risorsa Service popoli l'IP del cluster. Salva questo nella variabile 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 chiave privata e salvala su server.key
    openssl genrsa -out server.key 4096
  3. Genera un file di configurazione della server-csr.conf richiesta di firma del certificato. Questo viene utilizzato per generare il certificato che Kubernetes firmerà.
    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. Genera il payload della richiesta di firma del certificato per la firma da parte dell' Kubernetes.
    openssl req -new -config server-csr.conf -key server.key -out server.csr
  5. Inserisci il payload in una risorsa CSR ( Kubernetes ) CertificateSigningRequest
    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. Approvare la richiesta
    kubectl certificate approve ibmcloud-kube-audit-service.ibm-kube-audit
  7. Attendere che il certificato venga firmato
    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. Crea un segreto dal certificato e dalla chiave privata
    kubectl create secret tls \
    --cert server.crt \
    --key server.key \
    --namespace ibm-kube-audit \
    audit-webhook
  9. Riavvia la distribuzione per acquisire il nuovo segreto.
    kubectl rollout restart --namespace ibm-kube-audit deploy/ibmcloud-kube-audit
  10. Attendi che i nuovi pod siano disponibili
    kubectl rollout status --timeout 1m --namespace ibm-kube-audit deploy/ibmcloud-kube-audit
  11. Il webhook di audit è ora pronto a ricevere eventi tramite una connessione crittografata. Quando si configura il webhook di audit nella sezione “Inoltro dei log di audit dell’API Kubernetes a Cloud Logs”, è necessario utilizzare invece la versione https del file --remote-server URL:
    https://127.0.0.1:2040/api/v1/namespaces/ibm-kube-audit/services/https:ibmcloud-kube-audit-service:https/proxy/post`

Inoltro dei log di controllo API Kubernetes a una risorsa nella rete privata IBM Cloud

Inoltra i registri di audit a una risorsa diversa da IBM Cloud Logs che si trova all'esterno del cluster ed è accessibile nella rete IBM Cloud privata.

Il seguente esempio utilizza l'immagine haproxytech/haproxy-alpine:2.6 per inoltrare i log. Questa immagine è solo a scopo dimostrativo e non deve essere utilizzata in ambienti di produzione. Per una soluzione di produzione, configurare e gestire la propria immagine di inoltro dei log.

Prima di cominciare, assicurati di aver esaminato le considerazioni e i prerequisiti.

  1. Creare una nuova directory kube-audit-forwarder e creare un file haproxy.cfg con il seguente contenuto. Non dimenticare di sostituire <REMOTE-IP>:<REMOTE-PORT> nel file con l'indirizzo IP e la porta del tuo consumer di log 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

    Se il server di log consumer impone una connessione sicura ( TLS ), è possibile aggiungere i file del certificato a questa cartella e modificare la sezione backend in haproxy.cfg per utilizzare questi file. Per ulteriori informazioni, consultare il sito HAProxy documentazione.

  2. Creare una configmap dal contenuto della directory 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. Creare un file di configurazione denominato kube-audit-forwarder-remote-private-ip.yaml. Questo file di configurazione crea una distribuzione e un servizio che inoltra i log di controllo dal cluster all'indirizzo IP della risorsa remota tramite la rete privata 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

    Se sono stati aggiunti file di certificato a kube-audit-forwarder nel passo precedente, non dimenticare di elencare tali file nella sezione volumeMounts come subPath.

  4. Creare la distribuzione e il servizio.

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

  5. Verificare che l'implementazione e il servizio " kube-audit-forwarder " siano presenti nel proprio cluster.

    kubectl get svc -n ibm-kube-audit

    Output di esempio

    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

    Output di esempio

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

  6. Accedi al tuo account. Se applicabile, specifica il gruppo di risorse appropriato. Imposta il contesto per il tuo cluster. Accertarsi di specificare l'opzione --admin per scaricare i file client-certificate e client-key sulla macchina locale. Questi file vengono utilizzati successivamente per configurare il webhook di controllo.

    ibmcloud oc cluster config --cluster CLUSTER --admin

  7. Controllare lo stato dell'autorità di certificazione. Se i vostri certificati sono prossimi alla scadenza, seguite la procedura di rotazione dei certificati.

    ibmcloud oc cluster ca status -c CLUSTER

  8. Interrogare il certificate-authority del cluster e salvarlo in un file.

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

  9. Visualizzare la configurazione corrente eseguendo il comando oc config view ed esaminare l'output per client-certificate e client-key.

    oc config view --minify

    Output di esempio

    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. Configura il webhook di verifica e specifica certificate-authority, client-certificate e client-key che hai richiamato nei passi da 5 a 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]

  11. verifica che il webhook di controllo sia creato nel tuo cluster.

    ibmcloud oc cluster master audit-webhook get --cluster CLUSTER_NAME_OR_ID

    Output di esempio

    OK
Server:            https://127.0.0.1:2040/api/v1/namespaces/ibm-kube-audit/services/kube-audit-forwarder/proxy/post
Policy:            default

  12. Applica il webhook al tuo server API Kubernetes aggiornando il master cluster. L'aggiornamento del master potrebbe richiedere alcuni minuti.

    ibmcloud oc cluster master refresh --cluster CLUSTER_NAME_OR_ID

Una volta completato l'aggiornamento master, i tuoi log vengono inviati all'indirizzo IP privato della tua risorsa di registrazione.

Log di controllo del nodo di lavoro

Red Hat OpenShift on IBM Cloud utilizza il componente Linux Auditing System per auditd monitorare e registrare l'attività sui nodi di lavoro. Sebbene il controllo dei nodi di lavoro sia abilitato per impostazione predefinita, nessun dato di controllo è disponibile finché non si imposta l'inoltro dei log a IBM Cloud Logs un'istanza o a un server esterno.

Descrizione della configurazione di controllo del nodo di lavoro

I log sono archiviati nella directory /var/log/audit sui nodi di lavoro. È possibile visualizzare i log in IBM Cloud Logs o sul server esterno dopo aver configurato l'inoltro dei log.

Auditd raccoglie i log su vari eventi, tra cui:

  • Chiamate di sistema Linux (syscalls)
  • Negazioni SELinux
  • Modifiche alle politiche SELinux
  • Modifiche software tramite il programma di installazione del pacchetto di yum
  • Systemdoperazioni
  • Modifiche utente e gruppo Linux
  • Modifiche di Netfilter
  • Login SSH

Configurazione dell'inoltro dei log per i nodi di lavoro

Vedi Inoltro dei log a IBM Cloud Logs un'istanza.

Log di verifica servizio

Per impostazione predefinita, Red Hat OpenShift on IBM Cloud genera e invia eventi a IBM Cloud Logs. Per vedere questi eventi, è necessario creare un'istanza di IBM Cloud Logs. Per ulteriori informazioni, consultare IBM Cloud Logs events.

Visualizzazione degli avvisi AuditWebhookError nei cluster abilitati al controllo

Red Hat OpenShift on IBM Cloud La versione cluster ha un AuditWebhookError avviso che si attiva quando il webhook di audit si blocca o viene eliminato.

Per visualizzare l'avviso:

Accedi al tuo account. Se applicabile, specifica il gruppo di risorse appropriato. Imposta il contesto per il tuo cluster.

  1. Da Red Hat OpenShift on IBM Cloud, seleziona la vista Amministratore.
  2. Fare clic su Osserva > Avviso > AuditWebhookError.
  3. Per creare una notifica per questo avviso, consultare Invio di notifiche a sistemi esterni.