Audit-Logs für GKE ansehen

Auf dieser Seite wird gezeigt, wie Sie Informationen zum Bereitstellungsstatus und zur Richtlinienerzwingung in Cloud-Audit-Logs aufrufen.

Weitere Informationen zur Terminologie für die Benutzeroberfläche von Cloud-Audit-Logs, die auf dieser Seite verwendet wird, finden Sie unter Logs ansehen.

Sie können den Sicherheitsstatus Ihrer Anwendung einschließlich der Durchsetzung von Richtlinien für die Binärautorisierung über mehrere abhängige Google Cloud-Produkte hinweg in einem einzigen Dashboard bewerten. Weitere Informationen finden Sie unter Sicherheitsmonitoring.

Übersicht

Wenn Sie mit der Binärautorisierung ein Container-Image in Google Kubernetes Engine (GKE) bereitstellen, schreibt GKE Details zum Deployment in die Audit-Logs in Google Cloud Observability. Diese Audit-Logeinträge enthalten Nachrichten zum Erzwingungsstatus. Sie können diese Logeinträge in der Google Cloud Console oder in der Befehlszeile mit dem Befehl gcloud logging read aufrufen.

Für die Suchvorgänge später in dieser Anleitung greifen Sie auf Cloud-Audit-Logs zu und wählen das Projekt mit den Ereignissen aus, die Sie aufrufen möchten.

Gehen Sie so vor, um allgemeinen Zugriff auf Cloud-Audit-Logs zu erhalten:

  1. Rufen Sie in der Google Cloud Console die Seite Google Cloud Observability-Logging > Logs (Log-Explorer) auf:

    Zum Log-Explorer

  2. Wählen Sie das Google Cloud-Projekt aus, für das Sie Cloud-Audit-Logs aufrufen möchten.

Statusmeldungen zur Durchsetzung

GKE schreibt Nachrichten für die folgenden Erzwingungsbedingungen in das Audit-Log:

  • Blockiertes Deployment: Das Deployment wurde aufgrund einer Richtlinie der Binärautorisierung blockiert.
  • Break-Glass-Ereignis: Beim Deployment wurde die Richtlinienprüfung mit dem Break-Glass-Mechanismus umgangen. Weitere Informationen finden Sie unter Break-Glass verwenden.
  • Fail-Open: Das Deployment wurde zugelassen, da das Backend für die Binärautorisierung nicht verfügbar war.
  • Probelauf: Das Deployment wurde mit Richtlinienverstößen zugelassen, da in der Binärautorisierungsrichtlinie der Probelaufmodus festgelegt wurde.

Blockierte Bereitstellungsereignisse in Cloud-Audit-Logs

Wenn ein Container-Image aufgrund eines Verstoßes gegen eine Binärautorisierungsrichtlinie blockiert wird, finden Sie die Ereignisse der blockierten Bereitstellung in Cloud-Audit-Logs.

Cloud-Audit-Logs für blockierte Bereitstellungsereignisse abfragen

In diesem Abschnitt wird beschrieben, wie Cloud-Audit-Logs nach blockierten Bereitstellungsereignissen abgefragt werden.

Log-Explorer

So rufen Sie blockierte Bereitstellungsereignisse im Log-Explorer von Cloud-Audit-Logs auf:

  1. Zur Seite „Log-Explorer“

  2. Geben Sie die folgende Abfrage in das Feld search-query ein:

    resource.type="k8s_cluster"
logName:"cloudaudit.googleapis.com%2Factivity"
(protoPayload.methodName="io.k8s.core.v1.pods.create" OR
 protoPayload.methodName="io.k8s.core.v1.pods.update")
protoPayload.response.status="Failure"
(protoPayload.response.reason="VIOLATES_POLICY" OR
protoPayload.response.reason="Forbidden")
NOT "kube-system"
NOT "istio-system"

  3. Wählen Sie den Zeitraum unter time-range selector aus.

gcloud

Führen Sie den folgenden Befehl aus, um mithilfe der Google Cloud CLI Ereignisse von Richtlinienverstößen der letzten Woche in Cloud-Audit-Logs aufzurufen:

gcloud logging read --order="desc" --freshness=7d \
  'resource.type="k8s_cluster"
   logName:"cloudaudit.googleapis.com%2Factivity"
   (protoPayload.methodName="io.k8s.core.v1.pods.create" OR
    protoPayload.methodName="io.k8s.core.v1.pods.update")
   protoPayload.response.status="Failure"
   (protoPayload.response.reason="VIOLATES_POLICY" OR
   protoPayload.response.reason="Forbidden")
   NOT "kube-system"
   NOT "istio-system"'

Break-Glass-Ereignisse in Cloud-Audit-Logs

Mit der Binärautorisierung können Sie die Richtlinie mit einem Break-Glass-Label in der Pod-Spezifikation überschreiben. Wenn Images mit Break-Glass bereitgestellt werden, werden Binärautorisierungsereignisse von Binärautorisierungslogs in Cloud-Audit-Logs protokolliert. Im folgenden Abschnitt wird beschrieben, wie Sie diese Ereignisse abfragen können.

Cloud-Audit-Logs für Pods mit angegebenen Break-Glass abfragen

Log-Explorer

So rufen Sie Break-Glass-Ereignisse im Log-Explorer von Cloud-Audit-Logs auf:

  1. Zur Seite „Log-Explorer“

  2. Geben Sie die folgende Abfrage in das Feld search-query ein:

    resource.type="k8s_cluster"
logName:"cloudaudit.googleapis.com%2Factivity"
(protoPayload.methodName="io.k8s.core.v1.pods.create" OR
protoPayload.methodName="io.k8s.core.v1.pods.update")
"image-policy.k8s.io/break-glass"

  3. Wählen Sie den Zeitraum unter time-range selector aus.

gcloud

Führen Sie den folgenden Befehl aus, um Break-Glass-Ereignisse aus der letzten Woche in Cloud-Audit-Logs mit der glcoud CLI aufzurufen:

gcloud logging read --order="desc" --freshness=7d \
  'resource.type="k8s_cluster" AND
  logName:"cloudaudit.googleapis.com%2Factivity" AND
  (protoPayload.methodName="io.k8s.core.v1.pods.create" OR
    protoPayload.methodName="io.k8s.core.v1.pods.update") AND
  "image-policy.k8s.io/break-glass"'

Fail-Open-Ereignisse in Cloud-Audit-Logs

Fail-Open tritt auf, wenn das Deployment des Container-Images versucht wird, die Binärautorisierungserzwingung aber nicht verfügbar ist bzw. die Zeit überschreitet und das Deployment des Container-Images zugelassen wird.

In diesem Fall wird das Bestätigungsergebnis nicht erkannt und ein Logeintrag wird gespeichert.

Fail-Open-Ereignisse von Cloud-Audit-Logs abfragen

Log-Explorer

So rufen Sie Fail-Open-Ereignisse im Log-Explorer von Cloud-Audit-Logs auf:

  1. Zur Seite „Log-Explorer“

  2. Geben Sie die folgende Abfrage in das Feld search-query ein:

    resource.type="k8s_cluster"
logName:"cloudaudit.googleapis.com%2Factivity"
(protoPayload.methodName="io.k8s.core.v1.pods.create" OR
 protoPayload.methodName="io.k8s.core.v1.pods.update")
("image-policy.k8s.io/failed-open" OR
 "imagepolicywebhook.image-policy.k8s.io/failed-open" OR
 "failed-open.validating.webhook.admission.k8s.io")

  3. Wählen Sie den Zeitraum unter time-range selector aus.

gcloud

Führen Sie den folgenden Befehl aus, um Fail-Open-Ereignisse der letzten Woche in Cloud-Audit-Logs mit der gcloud CLI aufzurufen:

gcloud logging read --order="desc" --freshness=7d \
  'resource.type="k8s_cluster"
   logName:"cloudaudit.googleapis.com%2Factivity"
   (protoPayload.methodName="io.k8s.core.v1.pods.create" OR
    protoPayload.methodName="io.k8s.core.v1.pods.update")
   ("image-policy.k8s.io/failed-open" OR
    "imagepolicywebhook.image-policy.k8s.io/failed-open" OR
    "failed-open.validating.webhook.admission.k8s.io")'

Probelaufereignisse in Cloud-Audit-Logs

Der Probelaufmodus ist ein Erzwingungsmodus einer Richtlinie, der die Bereitstellung von nicht konformen Images ermöglicht. Dabei werden Details zur Bereitstellung in das Audit-Log geschrieben. Im Probelaufmodus können Sie eine Richtlinie in Ihrer Produktionsumgebung testen, bevor sie wirksam wird.

Wenn ein Container-Image die erforderlichen Prüfungen in einer Richtlinie nicht besteht, aber im Probelaufmodus bereitgestellt werden kann, enthält Cloud-Audit-Logs imagepolicywebhook.image-policy.k8s.io/dry-run: "true".

Cloud-Audit-Logs für Probelaufereignisse abfragen

Log-Explorer

So rufen Sie Probelaufereignisse im Log-Explorer von Cloud-Audit-Logs auf:

  1. Zur Seite „Log-Explorer“

  2. Geben Sie die folgende Abfrage in das Feld search-query ein:

    resource.type="k8s_cluster"
logName:"cloudaudit.googleapis.com%2Factivity"
(protoPayload.methodName="io.k8s.core.v1.pods.create" OR
 protoPayload.methodName="io.k8s.core.v1.pods.update")
labels."imagepolicywebhook.image-policy.k8s.io/dry-run"="true"

  3. Wählen Sie den Zeitraum unter time-range selector aus.

gcloud

Führen Sie den folgenden Befehl aus, um mit der gcloud CLI Probelaufbereitstellungsereignisse der letzten Woche in Cloud-Audit-Logs aufzurufen:

gcloud logging read --order="desc" --freshness=7d \
  'labels."imagepolicywebhook.image-policy.k8s.io/dry-run"="true"'