Anleitung zum Konfigurieren der Kubernetes-Überwachung auf Prisma SaaS.

• Siehe Kubernates Audting Dokumentation
• Navigieren Sie zu "Konfigurieren des Servers", um auf die bereitgestellten Schritte zum Konfigurieren des APIAudit-Webhook-Backends zu verweisen
• Navigieren Sie in der Compute Console zu Defend > Access > Kubernetes > Gehe zu Einstellungen
• Beachten Sie, dass in der Konsole nach dem Klicken auf die Option "Gehe zu den Einstellungen", um die für die Konfiguration erforderliche Webhook-URL zu finden, die Einstellungen leer sind und keine Webhook-URL vorhanden ist. Beziehen Sie sich auf das Bild unten, um sich auf die Erklärung zu beziehen:

• Prisma Cloud Compute (SaaS-Bereitstellung)
• Kubernetes (Google Kubernetes Engine)
• Kubernetes (Elastic Kubernetes Service und Azure Kubernetes Service)

• Gemäß den Versionshinweisen für Prisma Cloud Compute Version 21.08.514
• Entfernt die Unterstützung für die dynamische Kubernetes-Audit-Konfiguration, die in Kubernetes 1.19 veraltet war. Die dynamische Audit-Konfiguration wurde zuvor im Prisma Cloud Kubernetes-Auditing verwendet. Prisma Cloud Das Kubernetes-Auditing verwendet nun das reguläre Webhook-Backend.

• Pfad zur Konsole' URL (Compute / Manage / System / Utilities)
• export console= API Token (Compute / Manage / System / Utilities)
• export token= <API Token>
• Die folgenden Dienstprogramme müssen installiert werden:
  • locken
  • jq
  • Openssl
  • kubectl
  • Firefox
  • A Unterstützte Methode zum Aktualisieren von kube-apiserver-Manifesten. Dies geschieht normalerweise durch Bearbeiten von /etc/kubernetes/manifests/kube-apiserver.manifest auf Master-Knoten, kann aber von der Linux/K8s-Distribution abhängig sein.

TASK FLOW:

1. Überprüfen, ob Kubernetes Auditing in Prisma Cloud Compute aktiviert ist
2. Webhook generieren URL
3. Certificate Chain herunterladen und in base64 konvertieren
4. Audit-webhook.yaml generieren
5. Hinzufügen von Webhook und policy Konfiguration zu allen Masterknoten
6. Aktualisieren von kube-apiserver-Manifesten auf allen Masterknoten
7. Testen, um zu überprüfen, ob das Setup ordnungsgemäß funktioniert

Schritt 1: Überprüfen, ob die Kubernetes-Überwachung in Prisma Cloud Berechnen.
Navigieren Sie zu Compute / Access / Kubernetes und stellen Sie sicher, dass die Kubernetes-Überwachung aktiviert ist und über eine Regel verfügt, die Sie testen möchten (Exec oder An einen Pod anhängen ist am einfachsten).
 

 
Schritt 2: Webhook generieren URL

Um den Webhook zu generieren, müssen Sie ein Webhook-Suffix generieren und an den Endpunkt '/api/v1/kubernetes/webhook URL/' anhängen.

Führen Sie den folgenden Befehl aus, um eine Webhook-Variable zu erstellen:

 

Schritt 3: Zertifikatskette herunterladen und in base64 konvertieren

Zertifikatskette herunterladen und nach base64 exportieren

• Öffnen Sie Firefox und navigieren Sie zum "Pfad zur Konsole". URL
• Klicken Sie in der Symbolleiste auf das Symbol Zertifikat und anschließend auf den Pfeil Verbindungssicherheit:

• Klicken Sie auf Weitere Informationen

• Klicken Sie auf Zertifikat anzeigen

• Scrollen Sie nach unten zu Verschiedenes und laden Sie die PEM Kette herunter

• Legen Sie in Ihrem Terminal cd in den Ordner, in den die PEM Kette heruntergeladen wurde.
• Führen Sie den folgenden Befehl aus, um die PEM Kette als base64-codierte Variable zu speichern:

export cacerts=$(openssl base64 -in cloud-twistlock-com-chain.pem -A)

Schritt 4: Audit-webhook.yaml generieren

Generieren von audit-webhook.yaml- und audit-.yaml-Dateienpolicy, die zum Senden von Überwachungsereignissen an erforderlich sind Prisma Cloud

• Führen Sie den folgenden Befehl aus, um audit-webhook.yaml zu generieren:

cat <<EOF > audit-webhook.yaml

apiVersion: v1
kind: Config
preferences: {}
clusters:
- name: audit-cluster
  cluster:
    server: $webhookurl
    certificate-authority-data: $cacerts
contexts:
- name: webhook
  context:
    cluster: audit-cluster
    user: kube-apiserver
current-context: webhook
EOF

• Führen Sie den folgenden Befehl aus, um die Standardüberwachung policyzu generieren:

cat <<EOF > audit-policy.yaml

apiVersion: audit.k8s.io/v1 # This is required.
kind: Policy
# Generate audit events only for ResponseComplete or panic stages of a request.
omitStages:
  - "RequestReceived"
  - "ResponseStarted"
rules:
  # Audit on pod exec/attach events
  - level: Request
    resources:
    - group: ""
      resources: ["pods/exec", "pods/attach"]

  # Audit on pod creation events
  - level: Request
    resources:
    - group: ""
      resources: ["pods"]
    verbs: ["create"]

  # Audit on changes to the twistlock namespace (defender daemonset)
  - level: Request
    verbs: ["create", "update", "patch", "delete"]
    namespaces: ["twistlock"]

  # Default catch all rule
  - level: None
EOF

Schritt 5: Hinzufügen von Webhook und policy Konfiguration zu allen Masterknoten

Sie müssen dann die Überwachungsdateien allen Master-Knoten in einer Datei hinzufügen, auf die kube-apiserver zugreifen kann.

• Führen Sie den folgenden Befehl aus, um Hostvolumes anzuzeigen, auf die kube-apiserver zugreifen kann:

kubectl get pods -n kube-system kube-apiserver-<rest of pod name> -o jsonpath='{range .spec.volumes[*]}{.hostPath.path}{"\n"}{end}'

• Notieren Sie sich einen Pfad, der für Sie am sinnvollsten ist, um die YAML zuvor generierten Dateien zu platzieren. Dies hat beispielsweise die folgenden Pfade für mich zurückgegeben:

/var/log/kube-apiserver.log
/etc/ssl
/etc/pki/tls
/etc/pki/ca-trust
/usr/share/ssl
/usr/ssl
/usr/lib/ssl
/usr/local/openssl
/var/ssl
/etc/openssl
/etc/kubernetes/in-tree-cloud.config
/srv/kubernetes/ca.crt
/srv/kubernetes/kube-apiserver
/srv/sshproxy
/etc/kubernetes/kube-apiserver-healthcheck/secrets

I Festgestellt, dass der /srv/Kubernetes/Kube-APISERVER-Pfad für mich am sinnvollsten war.

• SCP audit-webhook.yaml und audit-.yaml zu jedem Master-Knoten in dem von Ihnen ausgewählten Pfad (in meinem Fall /srv/kubernetes/kube-apiserverpolicy).

Schritt 6: Aktualisieren von kube-apiserver-Manifesten auf allen Masterknoten

Dieser Schritt variiert je nach k8s-Distribution, also bestätigen Sie mit dem Hersteller / den Dokumenten, dass dies der richtige Weg ist, bevor Sie fortfahren.

• Suchen Sie die Datei kube-apiserver.manifest
• Öffnen Sie kube-apiserver.manifest in einem Texteditor, und suchen Sie einen Abschnitt, der etwa wie folgt aussieht:

spec:

  containers:
  - command:
    - kube-apiserver
    - --admission-control-config-file=/etc/kubernetes/extra-config/admission-control-config.yaml
    - --advertise-address=X.X.X.X
    - --allow-privileged=true
    - --audit-log-maxage=30
    - --audit-log-maxbackup=10
    - --audit-log-maxsize=100
    - --audit-log-path=/var/log/kubernetes/kube-apiserver.log

• Fügen Sie die folgenden Optionen zur Befehlsliste unter '- kube-apiserver' hinzu und stellen Sie sicher, dass der Pfad in Rot auf den zuvor ausgewählten Pfad aktualisiert wird.

--audit-policy-file=/srv/kubernetes/kube-apiserver/audit-policy.yaml
--audit-webhook-config-file=/srv/kubernetes/kube-apiserver/audit-webhook.yaml

• Das Update kube-apiserver.manifest sollte wie folgt aussehen, wenn Sie fertig sind:

spec:

  containers:
  - command:
    - kube-apiserver
    - --admission-control-config-file=/etc/kubernetes/extra-config/admission-control-config.yaml
    - --advertise-address=X.X.X.X
    - --allow-privileged=true
    - --audit-log-maxage=30
    - --audit-log-maxbackup=10
    - --audit-log-maxsize=100
    - --audit-policy-file=/srv/kubernetes/kube-apiserver/audit-policy.yaml
    - --audit-webhook-config-file=/srv/kubernetes/kube-apiserver/audit-webhook.yaml
    - --audit-log-path=/var/log/kubernetes/kube-apiserver.log

• Hinweis: In Ihrer kube-apiserver-Manifestdatei MUST ist die Option audit-log-path aktiviert, um die Überwachungsprotokollierung zu aktivieren.
• Sobald Sie die Manifestdatei speichern, sollte der kube-apiserver neu gestartet werden - dies kann etwa 30 Sekunden dauern und Sie können vorübergehend den Zugriff auf die API.

• Führen Sie einen Test anhand einer der Standardregeln durch, um sicherzustellen, dass sie funktioniert.

• Führen Sie einen exec in einem Container aus, um eine der Standardregeln zu testen:

kubectl exec <pod> -it -- /bin/sh

• Überprüfen Sie die Prisma Cloud Konsole unter Compute / Monitor / Events / Kubernetes Audits

Problembehandlung

Wenn der kube-apiserver-Pod nicht gesichert werden kann, bedeutet dies normalerweise, dass ein Problem mit Ihrer Manifestdatei vorliegt. Sie müssen dieses Problem beheben, aber der Prozess ist von der Verteilung von Kubernetes abhängig. A Einige mögliche Methoden sind:

• journalctl --unit kubelet
• Docker-Protokolle <Container>
• crictl logs <container>

Wenn die Konsole keine Überwachungsprotokolle anzeigt, geben die Prisma Cloud kube-apiserver-Protokolle in der Regel einen Hinweis:

• kubectl protokolliert kube-apiserver-<Rest des Pod-Namens>

• Kubernetes-Auditing
• https://kubernetes.io/docs/tasks/debug-application-cluster/audit/