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 -Konsole 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:
Rufen Sie in derGoogle Cloud Console die Seite Google Cloud Observability-Logging > Logs (Log-Explorer) auf:
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:
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")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")'
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:
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"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:
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")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:
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"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"'