Service-, API-Server- und Workerknotenprotokolle prüfen

Anhand von Prüfprotokollen wird deutlich, welche Operationen von den Benutzern in Ihrem Cluster ausgeführt werden. Dies kann Ihnen bei der Fehlerbehebung und bei der Einhaltung von Branchen- und Unternehmensstandards helfen.

Prüfprotokolle des Kubernetes-API-Servers

Um die von Benutzern initiierten Kubernetes-Verwaltungsaktivitäten in Ihrem Cluster zu überwachen, können Sie Prüfereignisse erfassen und weiterleiten, die über Ihren Kubernetes-API-Server an IBM Cloud Logs oder einen externen Server übergeben werden.

Hinweise und Voraussetzungen

Bevor Sie eine Kubernetes-API-Prüfkonfiguration einrichten, überprüfen Sie die folgenden Informationen.

VPC-Cluster Versionen 4.15 und höher: Audit-Protokolle verwenden das Red Hat OpenShift Audit-Richtlinienprofil default (für Standard) und WriteRequestBodies(für ausführlich). Weitere Informationen finden Sie unter Prüfprotokollrichtlinie.
Alle anderen Clusterversionen: Prüfprotokolle verwenden die Richtlinie openshift-audit im kube-samples-Repository.

Sie können die Standardrichtlinie nicht ändern oder Ihre eigene angepasste Richtlinie anwenden.

Informationen zu den Audit-Protokollen und zur Ausführlichkeit von Kubernetes finden Sie in der Dokumentation zu Kubernetes.
In einem Cluster kann nur ein Prüfwebhook erstellt werden.
Sie müssen die Berechtigung Administrator für den IBM CloudIAM-Plattformzugriffrolle für den Red Hat OpenShift on IBM Cloud-Cluster besitzen.

Befolgen Sie zunächst die Anweisungen, um API-Prüfprotokolle v Kubernetes an eine Ressource im privaten Netzwerk IBM Cloud zu senden.

Weiterleitung von API-Prüfprotokollen der Kubernetes an Cloud Logs

Wenn Sie Prüfprotokolle an IBM Cloud Logsweiterleiten möchten, können Sie ein Kubernetes-Audit-System mit dem bereitgestellten Image und der bereitgestellten Implementierung erstellen.

Das folgende Beispiel verwendet das icr.io/ibm/ibmcloud-kube-audit-to-ibm-cloud-logs Image, um Protokolle an IBM Cloud Logs weiterzuleiten. Wenn Sie nur einen Proof of Concept benötigen, können Sie den Schritt zur sicheren Einrichtung überspringen. Für eine stärker automatisierte Lösung konfigurieren und verwalten Sie Ihr eigenes Log-Forwarding-Image.

Zuvor wurde icr.io/ibm/ibmcloud-kube-audit-to-logdna für die Weiterleitung von Protokollen verwendet. Dieses Bild ist veraltet und wird bald nicht mehr unterstützt. Aktualisieren Sie Ihre Einstellungen für die Protokollweiterleitung, um stattdessen icr.io/ibm/ibmcloud-kube-audit-to-ibm-cloud-logs zu verwenden.

Das Kubernetes-Prüfsystem in Ihrem Cluster besteht aus einem Audit-Webhook, einem Protokollerfassungsservice und einer Web-Server-App sowie einem Protokollierungsagenten. Der Webhook sammelt die Ereignisse des Kubernetes-API-Servers von Ihrem Cluster-Master. Bei dem Protokollerfassungsservice handelt es sich um einen ClusterIP-Service von Kubernetes, der anhand eines Image aus der öffentlichen IBM Cloud-Registry erstellt wird. Dieser Dienst stellt eine einfache Webserver-Anwendung unter HTTP bereit, die ausschließlich im Netzwerk des Clusters erreichbar ist. Die Web-Server-App analysiert die Protokolldaten aus dem Audit-Webhook und erstellt jedes Protokoll als eindeutige JSON-Zeile. Schließlich leitet der Logging-Agent die Protokolle von der Webserver-Anwendung an IBM Cloud Logs weiter, wo Sie die Protokolle einsehen können.

Vorbereitende Schritte: Stellen Sie sicher, dass Sie die Hinweise und Voraussetzungen geprüft haben und dass Sie über die IAM-Plattformzugriffsrolle AdministratorIBM Cloud für IBM Cloud Logsverfügen.

Legen Sie die globale Container-Registry für öffentliche IBM Cloud-Images als Ziel fest.
```
ibmcloud cr region-set global
```
Optional: Weitere Informationen zum Image kube-audit finden Sie unter icr.io/ibm/ibmcloud-kube-audit-to-ibm-cloud-logs.
```
ibmcloud cr image-inspect icr.io/ibm/ibmcloud-kube-audit-to-ibm-cloud-logs
```
Richten Sie Ihre kubeconfig ein, um auf Ihren Cluster zuzugreifen, mit
```
ibmcloud ks cluster config -c CLUSTER
```

Erstellen Sie eine Konfigurationsdatei namens ibmcloud-kube-audit.yaml. Diese Konfigurationsdatei erstellt einen Protokollsammeldienst und eine Bereitstellung, die das Image icr.io/ibm/ibmcloud-kube-audit-to-ibm-cloud-logs abruft, um einen Protokollsammelcontainer zu erstellen.

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

Erstellen Sie die Bereitstellung im Namespace ibm-kube-audit Ihres Clusters.
```
kubectl apply -f ibmcloud-kube-audit.yaml
```

Warten Sie, bis der ibmcloud-kube-audit Deployment den Status „Verfügbar“ erreicht hat.

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

Beispielausgabe

deployment.apps/ibmcloud-kube-audit condition met

Stellen Sie sicher, dass der Service ibmcloud-kube-audit-service in Ihrem Cluster bereitgestellt worden ist.

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

Beispielausgabe

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

Verschlüsseln Sie den Datenverkehr während der Übertragung mit „ HTTPS “. Wenn Sie nur einen Proof-of-Concept-Audit-Log-Forwarder benötigen, überspringen Sie diesen Schritt.
Überprüfen Sie den Status der Zertifizierungsstelle. Wenn Ihre Zertifikate bald ablaufen, befolgen Sie die Schritte, um Ihre Zertifikate zu erneuern.
```
ibmcloud oc cluster ca status -c CLUSTER
```

Speichern Sie die certificate-authority des Clusters in der Datei cluster-ca.pem.

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

Melden Sie sich an Ihrem Konto an. If applicable, target the appropriate resource group. Legen Sie den Kontext für den Cluster fest. Bereiten Sie eine zertifikatsbasierte kubeconfig vor und speichern Sie sie unter kubeconfig.json. Stellen Sie sicher, dass Sie die --admin Option zum Herunterladen der client-key``client-certificate Daten auf Ihren lokalen Rechner angeben. Diese Daten werden später zur Konfiguration des Audit-Webhooks verwendet.
```
ibmcloud oc cluster config --cluster CLUSTER --admin --output json > kubeconfig.json
```
Wenn der Eigentümer der „kubeconfig“-Datei entfernt oder dessen Berechtigungen widerrufen werden, kann der Kubernetes-API-Server keine Audit-Protokolle mehr senden. Um dieses Szenario zu vermeiden, empfehlen wir, für diesen Vorgang eine Service-ID zu verwenden, da diese direkt mit dem Konto und nicht mit einem bestimmten Benutzer verknüpft ist.

Extrahieren Sie das Client-Zertifikat von kubeconfig in die Datei kubeconfig-cert.pem.

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

Extrahieren Sie den Client-Schlüssel von kubeconfig in die Datei kubeconfig-key.pem.

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

Konfigurieren Sie den Audit-Webhook und geben Sie certificate-authority, client-certificate und client-key an. Das certificate-authority wurde in Schritt 10 abgerufen, und das client-certificate und client-key wurden in den beiden vorherigen Schritten abgerufen. Optional können Sie den Wert policy auf einen anderen Wert konfigurieren.

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

Wenn Sie in Schritt 8 „ HTTPS ” konfiguriert haben, setzen Sie stattdessen „ URLremote-server ” auf https diesen Wert:

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

Stellen Sie sicher, dass der Audit-Webhook in Ihrem Cluster erstellt worden ist.

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

Beispielausgabe

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

Wenden Sie den Webhook auf Ihren Kubernetes API-Server an, indem Sie den Cluster-Master aktualisieren. Die Aktualisierung des Masters kann mehrere Minuten dauern.
```
ibmcloud oc cluster master refresh --cluster CLUSTER
```
Während der Master aktualisiert wird, sollten Sie eine Instanz von IBM Cloud Logs bereitstellen und einen Protokollierungsagenten auf jedem Workerknoten in Ihrem Cluster bereitstellen. Der Protokollierungsagent ist verpflichtet, Protokolle aus Ihrem Cluster an den IBM Cloud Logs-Service weiterzuleiten. Wenn Sie bereits Protokollierungsagenten in Ihrem Cluster eingerichtet haben, können Sie diesen Schritt überspringen.

Den Status des Clusters anzeigen und warten, bis angezeigt Master State wird updating, dann auf den Status warten deployed. Der Vorgang kann einige Minuten dauern.

ibmcloud ks cluster get -c CLUSTER

Beispielausgabe

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

Nachdem der Aktualisierungsvorgang des Masters abgeschlossen ist und die Protokollierungsagenten auf Ihren Workerknoten ausgeführt werden, können Sie Ihre Prüfprotokolle der Kubernetes-API in IBM Cloud Logs anzeigen.

Nachdem Sie den Audit-Webhook in Ihrem Cluster eingerichtet haben, können Sie Versionsaktualisierungen des Images ibmcloud-kube-audit-to-ibm-cloud-logs überwachen, indem Sie den folgenden Befehl ausführen: ibmcloud cr image-list --include-ibm | grep ibmcloud-kube-audit-to-ibm-cloud-logs. Um die Version des Image anzuzeigen, das derzeit in Ihrem Cluster ausgeführt wird, führen Sie oc get pods | grep ibmcloud-kube-audit-to-ibm-cloud-logs aus, um den Namen des Audit-Pods zu suchen, und führen Sie kubectl describe pod <pod_name> aus, um die Imageversion anzuzeigen. Aktualisieren Sie den Pod auf die neueste verfügbare Version des aktuellen Tags mit kubectl rollout restart --namespace ibm-kube-audit deploy/ibmcloud-kube-audit und warten Sie, bis die neuen Pods mit verfügbar kubectl rollout status --timeout 1m --namespace ibm-kube-audit deploy/ibmcloud-kube-audit sind.

Verwalten Sie Updates, rotieren Sie Zertifikate und verschlüsseln Sie Daten während der Übertragung mit HTTPS

Einige wichtige Hinweise, die Sie vor der Weiterleitung von Protokollen beachten sollten:

Das Bild-Tag icr.io/ibm/ibmcloud-kube-audit-to-ibm-cloud-logs:latest erhält Updates zur Behebung von Sicherheitslücken und Fehlern. Die Bereitstellung muss jedoch manuell neu gestartet werden, damit diese Änderungen übernommen werden. Verwenden Sie kubectl rollout restart -n ibm-kube-audit deploy/ibmcloud-kube-audit, um das neueste Image abzurufen und einen ordnungsgemäßen Neustart durchzuführen.
Diese Bereitstellung wird manuell installiert und verwaltet. Der Wechsel von dieser Bereitstellung zu einer anderen kann zu Ausfallzeiten des Audit-Protokolls führen.
Das in den folgenden Schritten generierte Zertifikat kann rotiert werden. Die Rotation erfordert manuelle Schritte, um das Geheimnis zu ersetzen und die Bereitstellung neu zu starten.

Um die Bereitstellung mit Verschlüsselung bei der Übertragung zu sichern, sind ein privater Schlüssel und ein vom kube-apiserver signiertes TLS Zertifikat erforderlich.

Nachdem Sie die YAML-Datei in Schritt 4 angewendet haben, warten Sie, bis die Service-Ressource die Cluster-IP ausfüllt. Speichern Sie das in der Shell-Variablen $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
)

Erzeugen Sie einen privaten Schlüssel und speichern Sie ihn unter server.key
```
openssl genrsa -out server.key 4096
```

Erstellen Sie eine Konfigurationsdatei für die server-csr.conf Zertifikatssignierungsanforderung. Dies wird verwendet, um das Zertifikat zu generieren, das Kubernetes signieren wird.

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

Generieren Sie die Nutzlast der Zertifikatssignierungsanforderung für die Signatur durch „ Kubernetes “.
```
openssl req -new -config server-csr.conf -key server.key -out server.csr
```

Fügen Sie die Nutzlast in eine CSR-Ressource ( KubernetesCertificateSigningRequest ) ein

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

Den Antrag genehmigen

kubectl certificate approve ibmcloud-kube-audit-service.ibm-kube-audit

Warten Sie, bis das Zertifikat signiert ist

kubectl wait \
    --for jsonpath='{.status.certificate}' \
    --output go-template='{{.status.certificate | base64decode}}' \
    --timeout 5m \
    csr/ibmcloud-kube-audit-service.ibm-kube-audit > server.crt

Erstellen Sie ein Geheimnis aus dem Zertifikat und dem privaten Schlüssel

kubectl create secret tls \
    --cert server.crt \
    --key server.key \
    --namespace ibm-kube-audit \
    audit-webhook

Starten Sie die Bereitstellung neu, um das neue Geheimnis zu übernehmen.

kubectl rollout restart --namespace ibm-kube-audit deploy/ibmcloud-kube-audit

Warten Sie, bis die neuen Pods verfügbar sind

kubectl rollout status --timeout 1m --namespace ibm-kube-audit deploy/ibmcloud-kube-audit

Der Audit-Webhook ist nun bereit, Ereignisse über eine verschlüsselte Verbindung zu empfangen. Bei der Konfiguration des Audit-Webhooks im Abschnitt Weiterleitung von Audit-Protokollen der API Kubernetes an Cloud Logs müssen Sie stattdessen die Version https der URL--remote-server verwenden:
```
https://127.0.0.1:2040/api/v1/namespaces/ibm-kube-audit/services/https:ibmcloud-kube-audit-service:https/proxy/post`
```

Kubernetes-API-Prüfprotokolle an eine Ressource im IBM Cloud privaten Netz weiterleiten

Weiterleiten von Prüfprotokollen an eine andere Ressource als IBM Cloud Logs, die sich außerhalb Ihres Clusters befindet und über das IBM Cloud private Netz zugänglich ist.

Im folgenden Beispiel wird das Image haproxytech/haproxy-alpine:2.6 zum Weiterleiten von Protokollen verwendet. Dieses Image dient nur zu Demonstrationszwecken und sollte nicht in Produktionsumgebungen verwendet werden. Konfigurieren und verwalten Sie für eine Produktionslösung Ihr eigenes Image für die Protokollweiterleitung.

Stellen Sie vor Beginn sicher, dass Sie die Hinweise und Voraussetzungen geprüft haben.

Erstellen Sie ein neues Verzeichnis kube-audit-forwarder und erstellen Sie darin eine Datei haproxy.cfg mit dem folgenden Inhalt. Vergessen Sie nicht, <REMOTE-IP>:<REMOTE-PORT> in der Datei durch die IP-Adresse und den Port Ihres fernen Protokollkonsumenten zu ersetzen.
```
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
```
Wenn Ihr Log-Consumer-Server eine sichere Verbindung erzwingt ( TLS ), können Sie Ihre Zertifikatsdateien zu diesem Verzeichnis hinzufügen und den Backend-Abschnitt in haproxy.cfg ändern, um diese Dateien zu verwenden. Weitere Informationen finden Sie in der Dokumentation HAProxy.

Erstellen Sie aus dem Inhalt des Verzeichnisses kube-audit-forwarder eine Konfigurationszuordnung.

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

Erstellen Sie eine Konfigurationsdatei mit dem Namen kube-audit-forwarder-remote-private-ip.yaml. Diese Konfigurationsdatei erstellt eine Bereitstellung und einen Service, der Prüfprotokolle vom Cluster über das private Netz IBM Cloud an die IP-Adresse der fernen Ressource weiterleitet.

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

Wenn Sie im vorherigen Schritt Zertifikatsdateien zu kube-audit-forwarder hinzugefügt haben, vergessen Sie nicht, diese Dateien im Abschnitt volumeMounts als subPath aufzulisten.

Erstellen Sie die Bereitstellung und den Dienst.

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

Stellen Sie sicher, dass die Bereitstellung kube-audit-forwarder und der Dienst in Ihrem Cluster bereitgestellt sind.

kubectl get svc -n ibm-kube-audit

Beispielausgabe

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

Beispielausgabe

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

Melden Sie sich an Ihrem Konto an. If applicable, target the appropriate resource group. Legen Sie den Kontext für den Cluster fest. Stellen Sie sicher, dass Sie die Option --admin angeben, um die Dateien client-key und client-certificate auf Ihren lokalen Rechner herunterzuladen. Diese Dateien werden später zum Konfigurieren des Audit-Webhooks verwendet.
```
ibmcloud oc cluster config --cluster CLUSTER --admin
```
Überprüfen Sie den Status der Zertifizierungsstelle. Wenn Ihre Zertifikate bald ablaufen, befolgen Sie die Schritte, um Ihre Zertifikate zu erneuern.
```
ibmcloud oc cluster ca status -c CLUSTER
```

Rufen Sie die des certificate-authority Clusters ab und speichern Sie sie in einer Datei.

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

Zeigen Sie Ihre aktuelle Konfiguration an, indem Sie den Befehl oc config view ausführen und die Ausgabe für client-certificate und client-key überprüfen.

oc config view --minify

Beispielausgabe

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

Konfigurieren Sie den Audit-Webhook und geben Sie die certificate-authority, client-certificate und client-key an, die Sie in den Schritten 5-7 abgerufen haben.

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]

Stellen Sie sicher, dass der Audit-Webhook in Ihrem Cluster erstellt worden ist.

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

Beispielausgabe

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

Wenden Sie den Webhook auf Ihren Kubernetes API-Server an, indem Sie den Cluster-Master aktualisieren. Der Master kann mehrere Minuten dauern, bis er aktualisiert wird.
```
ibmcloud oc cluster master refresh --cluster CLUSTER_NAME_OR_ID
```

Nachdem die Masteraktualisierung abgeschlossen ist, werden Ihre Protokolle an die private IP-Adresse Ihrer Protokollierungsressource gesendet.

Auditprotokolle für Workerknoten

Red Hat OpenShift on IBM Cloud verwendet die Linux Auditing System-Komponente auditd, um die Aktivität auf den Workerknoten zu überwachen und zu protokollieren. Obwohl die Protokollierung für Worker-Knoten standardmäßig aktiviert ist, stehen keine Protokolldaten zur Verfügung, bis Sie die Protokollweiterleitung an eine IBM Cloud Logs-Instanz oder einen externen Server eingerichtet haben.

Erläuterung der Auditkonfiguration für Workerknoten

Die Protokolle werden im Verzeichnis /var/log/audit auf den Workerknoten gespeichert. Sie können die Protokolle in der IBM Cloud Logs-Instanz oder auf Ihrem externen Server anzeigen, nachdem Sie die Protokollweiterleitung eingerichtet haben.

Auditd erfasst Protokolle zu verschiedenen Ereignissen, einschließlich der folgenden:

Linux-Systemaufrufe (syscalls)
SELinux-Zurückweisungen (denials)
SELinux-Richtlinienänderungen
Softwareänderungen durch das Installationsprogramm für yum-Pakete
Systemd-Operationen
Änderungen für Linux-Benutzer und -Gruppen
Netfilter ändert Modifikationen
SSH-Anmeldungen

Protokollweiterleitung für Workerknoten einrichten

Weitere Informationen hierzu finden Sie im Abschnitt Protokolle an eine IBM Cloud Logs-Instanz weiterleiten.

Serviceprüfprotokolle

Standardmäßig generiert und sendet Red Hat OpenShift on IBM Cloud Ereignisse an IBM Cloud Logs. Um diese Ereignisse anzuzeigen, müssen Sie eine IBM Cloud Logs-Instanz erstellen. Weitere Informationen finden Sie unter IBM Cloud Logs-Ereignisse.

`AuditWebhookError`-Alerts in prüffähigen Clustern anzeigen

Red Hat OpenShift on IBM Cloud Die Cluster-Version verfügt über eine Warnmeldung AuditWebhookError, die ausgelöst wird, wenn der Audit-Webhook abstürzt oder gelöscht wird.

So zeigen Sie den Alert an:

Melden Sie sich an Ihrem Konto an. If applicable, target the appropriate resource group. Legen Sie den Kontext für den Cluster fest.

Wählen Sie in der Red Hat OpenShift on IBM Cloud die Ansicht Administrator aus.
Klicken Sie auf Beobachten > Alerts > Fehler im AuditWebhook.
Informationen zum Erstellen einer Benachrichtigung für diesen Alert finden Sie unter Benachrichtigungen an externe Systeme senden.

Service-, API-Server- und Workerknotenprotokolle prüfen

Service-, API-Server- und Workerknotenprotokolle prüfen

Prüfprotokolle des Kubernetes-API-Servers

Hinweise und Voraussetzungen

Weiterleitung von API-Prüfprotokollen der Kubernetes an Cloud Logs

Verwalten Sie Updates, rotieren Sie Zertifikate und verschlüsseln Sie Daten während der Übertragung mit HTTPS

Kubernetes-API-Prüfprotokolle an eine Ressource im IBM Cloud privaten Netz weiterleiten

Auditprotokolle für Workerknoten

Erläuterung der Auditkonfiguration für Workerknoten

Protokollweiterleitung für Workerknoten einrichten

Serviceprüfprotokolle

AuditWebhookError-Alerts in prüffähigen Clustern anzeigen

`AuditWebhookError`-Alerts in prüffähigen Clustern anzeigen