Zugriff auf Anmeldedaten: Secrets, auf die im Kubernetes-Namespace zugegriffen wurde

In diesem Dokument wird ein bestimmter Typ von Bedrohungsergebnissen in Security Command Center beschrieben. Bedrohungsergebnisse werden von Bedrohungsdetektoren generiert, wenn sie eine potenzielle Bedrohung in Ihren Cloud-Ressourcen erkennen. Eine vollständige Liste der verfügbaren Bedrohungsergebnisse finden Sie im Index der Bedrohungsergebnisse.

Übersicht

Das default Kubernetes-Dienstkonto eines Pods wurde verwendet, um auf Secret-Objekte im Cluster zuzugreifen. Das default-Kubernetes-Dienstkonto sollte keinen Zugriff auf Secret-Objekte haben, es sei denn, Sie haben diesen Zugriff explizit mit einem Role- oder ClusterRole-Objekt gewährt.

Die Quelle dieses Ergebnisses ist Event Threat Detection.

Der folgende Reaktionplan ist möglicherweise für dieses Ergebnis geeignet, kann sich jedoch auch auf Abläufe auswirken. Prüfen Sie die Informationen, die Sie im Rahmen Ihrer Untersuchung erfasst haben, sorgfältig, um die beste Lösung für die Behebung der Ergebnisse zu finden.

Maßnahmen

So reagieren Sie auf dieses Ergebnis:

  1. Umfang des Zugriffs ermitteln:

    • Notieren Sie sich in der JSON-Datei für den Befund den Wert von finding.resourceName. Dies gibt den Kubernetes-Namespace oder die Ressource an, auf die zugegriffen wurde.
    • Notieren Sie sich den Wert von resource.sourceProperties.affectedResources.gcpResourceName. Dies ist der vollständige Ressourcenname des Kubernetes-Secrets, auf das zugegriffen wurde.

  2. Cloud-Audit-Logs untersuchen:

    • Rufen Sie in der Google Cloud Console den Log-Explorer auf.

    • Filtern Sie die Logs, um die spezifischen Aktionen zu finden, die für Kubernetes-Secrets ausgeführt wurden. Verwenden Sie den folgenden Filter:

      resource.type="k8s_cluster"
protoPayload.methodName=~"io\.k8s\.core\.v1\.secrets\..*"

    • Suchen Sie nach Einträgen mit protoPayload.methodName-Werten wie io.k8s.core.v1.secrets.get und io.k8s.core.v1.secrets.list um den Zeitpunkt, zu dem der Befund generiert wurde. Diese Logs können mehr Kontext dazu liefern, wer oder was auf das Secret zugegriffen hat und welche Aktionen ausgeführt wurden.

    • Prüfen Sie mit dem folgenden Logfilter, ob Änderungen an der rollenbasierten Zugriffssteuerung (Role-Based Access Control, RBAC) vorgenommen wurden, die erforderlich sind, damit ein Pod auf das Secret zugreifen kann:

      resource.type="k8s_cluster"
protoPayload.methodName:"io\.k8s\.authorization\.rbac\.v1\..*"

      Suchen Sie insbesondere nach Logs mit methodName von io.k8s.authorization.rbac.v1.roles.create/update oder io.k8s.authorization.rbac.v1.rolebindings.create/update.

  3. Google Kubernetes Engine RBAC-Konfiguration prüfen:

    • Rufen Sie in der Google Cloud Console den Bereich Kubernetes Engine auf.
    • Rufen Sie Ihren Cluster auf und wählen Sie Objektbrowser aus.
    • Maximieren Sie die Gruppe rbac.authorization.k8s.io.
    • Sehen Sie sich die Objekte Role und RoleBinding (und ggf. ClusterRole / ClusterRoleBinding) im Namespace an, der in finding.resourceName angegeben ist.
    • Suchen Sie nach Rollen, die get- oder list-Berechtigungen für secrets gewähren.
    • Ermitteln Sie die RoleBinding, die das default-Dienstkonto (oder andere Dienstkonten) im Namespace mit dem Secret für die Rollenzuweisung verknüpft.

  4. Zu viele Berechtigungen korrigieren: