.
Auf dieser Seite erfahren Sie, wie Sie mithilfe von Logs die Ausstellung und Verwendung von Kubernetes-Identitäten in Form von Zertifikaten und Dienstkontotokens durch die Cluster-Kontrollebene der Google Kubernetes Engine (GKE) prüfen. Diese Bestätigung ist völlig optional und nicht erforderlich, um Ihre Steuerungsebene zu schützen.
Dieser Leitfaden richtet sich an Sicherheitsadministratoren und Plattforminhaber, die spezifische Compliance- oder Richtlinienanforderungen für die Kontrolle der Ausstellung und Signatur von Anmeldedaten haben. Sie sollten bereits selbstverwaltete Schlüssel und Zertifizierungsstellen mit der GKE Control Plane Authority eingerichtet haben.
Sie sollten mit den folgenden Konzepten vertraut sein:
Auf dieser Seite wird ein Teil der optionalen Funktionen der Steuerungsebene in GKE beschrieben, mit denen Sie Aufgaben wie die Überprüfung des Sicherheitsstatus der Steuerungsebene oder die Konfiguration der Verschlüsselung und Anmeldedatensignatur in der Steuerungsebene mit von Ihnen verwalteten Schlüsseln ausführen können. Weitere Informationen finden Sie unter GKE Control Plane Authority.
Standardmäßig werden von Google Cloud verschiedene Sicherheitsmaßnahmen auf die verwaltete Steuerungsebene angewendet. Auf dieser Seite werden optionale Funktionen beschrieben, mit denen Sie die GKE-Steuerungsebene besser im Blick behalten oder steuern können.
Protokolle zur Identitätsausstellung
Die GKE-Logs zur Identitätsausstellung sind Audit-Logs der Steuerungsebene, in denen erfasst wird, wann die Steuerungsebene Anmeldedaten ausstellt und wann diese Anmeldedaten im Cluster verwendet werden. Sie können diese Protokolle verwenden, um die Lebensdauer einer Anmeldedaten, einschließlich Ausstellung und Verwendung, zu verfolgen, indem Sie die Protokolle zur Identitätsausstellung mit den Protokollen von Cloud KMS, Certificate Authority Service und Kubernetes API in Beziehung setzen. Logs zur GKE-Identitätsausgabe werden aktiviert, wenn Sie die GKE Control Plane Authority verwenden. In diesen Protokollen werden die Ausstellung und Verwendung der folgenden Anmeldedatentypen erfasst:
- X.509-Zertifikate
- Cluster-JSON-Web-Tokens (JWTs)
X.509-Zertifikate
Kubernetes verwendet X.509-Zertifikate für die Clientzertifikatauthentifizierung. Zum Ausstellen von Zertifikaten sendet die Kubernetes-Kontrollebene eine genehmigte CertificateSigningRequest an eine Zertifizierungsstelle (Certificate Authority, CA) im CA Service. Die Zertifizierungsstelle stellt dann ein Zertifikat aus und verwendet dazu den entsprechenden Schlüssel in Cloud KMS, um den Zertifikats-Digest zu signieren.
Die Kubernetes API-Server-Protokolle enthalten Details zur Zertifikatsignatur für jeden Kubernetes API-Aufruf, der mit einem Zertifikat authentifiziert wurde. Der Eintrag für die Anmeldedaten-ID im Protokoll hat das folgende Format:
"authentication.k8s.io/credential-id": "X509SHA256=CERTIFICATE_HASH"
Der Wert CERTIFICATE_HASH
ist der SHA256-Hash für das Zertifikat, mit dem Sie den Lebenszyklus des Zertifikats nachvollziehen können.
Sie können die Zertifikatslogs des Kubernetes API-Servers verwenden, um den Lebenszyklus des Zertifikats zu verfolgen, indem Sie Logs aus den folgenden Diensten korrelieren:
- GKE-Logs zur Identitätsausstellung: Mit der Abfrage
protoPayload.metadata.credentialId
können Sie anhand der Anmeldedaten-ID aus den Kubernetes API-Server-Logs nach bestimmten GKE-Logs zur Identitätsausstellung suchen. Verwenden Sie dann das FeldprotoPayload.metadata.certificateFingerprint
aus dem GKE-Log zur Identitätsausstellung, um die Logs zur Identitätsausstellung mit den Logs des CA-Dienstes zu verknüpfen. - CA Service-Protokolle: Suchen Sie den Logeintrag zur Zertifikatausstellung, der die folgenden IDs enthält:
cert_fingerprint.sha256_hash
: SHA256-Hash des signierten Zertifikats. Verwenden Sie diese ID, um Protokolle mit GKE- und Kubernetes API-Ereignissen abzugleichen.tbs_certificate_digest
: Ein Hash des Zertifikatsinhalts, der zur Signatur mit einem Cloud KMS-Schlüssel gesendet wurde. Verwenden Sie diese ID, um Protokolle mit Cloud KMS-Protokollen abzugleichen.
- Cloud KMS-Signaturprotokolle: Verwenden Sie den Wert
tbs_certificate_digest
aus dem CA Service-Protokoll, um zu bestätigen, dass das Zertifikat mit dem erwarteten Cloud KMS-Schlüssel signiert wurde.
JSON Web Tokens (JWTs)
Signierte JWTs (JSON Web Tokens) werden als Trägertoken für Entitäten im Cluster, z. B. Kubernetes-Dienstkonten, bei der Authentifizierung von Anfragen an die Kubernetes API verwendet. Wenn ein Pod erstellt wird, der ein bestimmtes Dienstkonto verwendet, erstellt Kubernetes ein JWT und bindet es im Pod ein. Wenn Sie die GKE-Kontrollebene verwenden, um Ihre eigenen Schlüssel und Zertifizierungsstellen auszuführen, wird dieses JWT signiert und später mit dem Signaturschlüssel des Dienstkontos in Cloud KMS verifiziert.
Die Logs des Kubernetes API-Servers enthalten Details zur Tokensignatur für jeden Kubernetes API-Aufruf, der mit einem JWT authentifiziert wurde. Der Eintrag für die Tokensignatur im Protokoll hat folgendes Format:
"authentication.kubernetes.io/credential-id":"JTI=JWT_ID"
Der Wert JWT_ID
ist ein String, der das JWT identifiziert, das im Kubernetes API-Aufruf verwendet wurde.
Sie können die JWT-ID aus den Serverlogs der Kubernetes API verwenden, um den Lebenszyklus eines JWT zu verfolgen. Dazu müssen Sie die folgenden Logs in Beziehung setzen:
- GKE-Logs zur Identitätsausstellung: Verwenden Sie die JWT-ID aus den Kubernetes API-Server-Logs, um bestimmte JWT-Ausstellungseinträge zu finden. Jeder Eintrag enthält außerdem das Feld
toBeSignedDigest
, dessen Wert mit Cloud KMS-Protokollen übereinstimmen kann. - Cloud KMS-Signaturprotokolle: Verwenden Sie den Wert des Felds
toBeSignedDigest
aus den GKE-Protokollen zur Identitätsausgabe, um zu bestätigen, dass das JWT mit dem erwarteten Cloud KMS-Schlüssel signiert wurde.
Preise
In diesem Dokument verwenden Sie die folgenden kostenpflichtigen Komponenten von Google Cloud:
Mit dem Preisrechner können Sie eine Kostenschätzung für Ihre voraussichtliche Nutzung vornehmen.
Hinweis
Aktivieren Sie die folgenden APIs für den Cloud-Audit-Logging-Dienst:
- Aktivieren Sie für Cloud KMS Audit-Logs für den Datenzugriff vom Typ Daten lesen.
- Aktivieren Sie für den CA-Dienst die Audit-Logs vom Typ Lesen durch Administrator und Daten schreiben.
Erforderliche Rollen
Bitten Sie Ihren Administrator, Ihnen die folgenden IAM-Rollen für Ihr Projekt zuzuweisen, um die Berechtigungen zu erhalten, die Sie zum Zugriff auf Protokolle zur Identitätsausstellung benötigen:
-
Alle Aktionen in Logging ausführen:
Logging-Administrator (
roles/logging.admin
). -
Logs ansehen:
Betrachter privater Logs (
roles/logging.privateLogViewer
).
Weitere Informationen zum Zuweisen von Rollen finden Sie unter Zugriff auf Projekte, Ordner und Organisationen verwalten.
Sie können die erforderlichen Berechtigungen auch über benutzerdefinierte Rollen oder andere vordefinierte Rollen erhalten.
Anforderungen und Einschränkungen
Es gelten die folgenden Anforderungen und Einschränkungen:
- Sie müssen mindestens die GKE-Version 1.31.1-gke.1846000 verwenden.
- Logs zur Identitätsausstellung werden als Cloud-Audit-Logs aufgezeichnet und haben eine Aufbewahrungsdauer von 400 Tagen. Die Aufbewahrungsdauer ist nicht konfigurierbar. Sie können Ihre Audit-Logs zu Systemereignissen jedoch an andere Ziele weiterleiten, um eine längere Aufbewahrungsdauer zu erreichen.
Zertifikate prüfen
Mit den GKE-Logs zur Ausstellung von Identitäten der Steuerungsebene können Sie prüfen, ob ein Zertifikat erfolgreich ausgestellt oder verwendet wurde. Sie können einen der folgenden Protokolle oder eine Kombination aus Protokollen verwenden, um Informationen zur Ausstellung und Verwendung von Zertifikaten zu bestätigen:
Zertifikatsprotokolle |
|
---|---|
Kubernetes API-Protokoll zur Verwendung von Zertifikaten |
Protokolliert die Details der Zertifikatsignatur, wenn das Zertifikat für die Kubernetes API verwendet wird. |
GKE-Protokoll für Zertifikatsausstellungsvorgänge |
Hier werden alle Vorgänge zur Ausstellung von Zertifikaten als Audit-Log zu Systemereignissen protokolliert. Diese Protokolle sind standardmäßig in allen Clustern aktiviert, in denen von Nutzern verwaltete Schlüssel oder Zertifizierungsstellen der GKE-Steuerungsebene verwendet werden. |
CA Service-Audit-Log |
Es wird ein Eintrag protokolliert, wenn ein Zertifikat ausgestellt wird. |
Cloud KMS-Audit-Log |
Es wird ein Eintrag protokolliert, wenn ein Digest als Antwort auf eine Signaturanfrage vom CA-Dienst signiert wird. |
Zertifikatsnutzung mit Kubernetes API-Logs prüfen
So rufen Sie Logeinträge für API-Aufrufe ab, die mithilfe von Zertifikaten authentifiziert wurden:
Rufen Sie in der Google Cloud Console die Seite Log-Explorer auf.
Fügen Sie den folgenden Ausdruck in das Feld des Abfrageeditors ein:
log_id("cloudaudit.googleapis.com/activity") resource.type="k8s_cluster" labels."authentication.kubernetes.io/credential-id":"X509SHA256="
Klicken Sie auf Abfrage ausführen.
Mit dieser Abfrage werden alle Kubernetes API-Server-Logs zurückgegeben, die mit einem X.509-Zertifikat verknüpft sind. Suchen Sie mithilfe Ihrer Sicherheitstools oder manuell nach bestimmten Logeinträgen, die Sie untersuchen möchten.
Wenn Sie diese Protokolle mit anderen Protokolltypen in Beziehung setzen möchten, suchen Sie nach dem folgenden Feld:
"authentication.k8s.io/credential-id":"CREDENTIAL_ID"
Der Wert CREDENTIAL_ID
ist die Kennung, mit der Sie Logs aus GKE, CA Service und Cloud KMS in Beziehung setzen können. Der CREDENTIAL_ID
hat das Format "X509SHA256=CERTIFICATE_HASH"
.
Zertifikatsausstellung mit GKE-Logs prüfen
So rufen Sie GKE-Logeinträge für Ereignisse zur Zertifikatsausstellung auf:
Rufen Sie in der Google Cloud Console die Seite Log-Explorer auf.
Fügen Sie den folgenden Ausdruck in das Feld des Abfrageeditors ein:
logName="projects/PROJECT_ID/logs/cloudaudit.googleapis.com%2Fsystem_event" resource.type="gke_cluster" protoPayload.serviceName="container.googleapis.com" protoPayload.metadata.credentialId="CREDENTIAL_ID"
Ersetzen Sie Folgendes:
PROJECT_ID
: Ihre Projekt-ID.CREDENTIAL_ID
:CREDENTIAL_ID
aus dem Abschnitt Zertifikatnutzung mit Kubernetes API-Logs überprüfen.
Klicken Sie auf Abfrage ausführen.
Zertifikatsausstellung mit CA Service-Protokollen prüfen
So finden Sie CA Service-Protokolle, die mit den GKE-Ereignissen zur Zertifikatausstellung übereinstimmen:
Rufen Sie in der Google Cloud Console die Seite Log-Explorer auf.
Fügen Sie den folgenden Ausdruck in das Feld des Abfrageeditors ein:
resource.type="audited_resource" protoPayload.serviceName="privateca.googleapis.com" protoPayload.methodName="google.cloud.security.privateca.v1.CertificateAuthorityService.CreateCertificate" protoPayload.response.certificate_description.cert_fingerprint.sha256_hash="CERTIFICATE_HASH"
Ersetzen Sie
CERTIFICATE_HASH
durch dasCERTIFICATE_HASH
aus dem Abschnitt Zertifikatnutzung mit Kubernetes API-Logs überprüfen. Das PräfixX509SHA256=
darf nicht im Hash enthalten sein.Klicken Sie auf Abfrage ausführen.
Diese Abfrage gibt ein Protokoll zurück, das im Antwortabschnitt der Zertifikatsbeschreibung ein
tbs_certificate_digest: DIGEST_VALUE
-Feld enthält.
Mit DIGEST_VALUE
können Sie Cloud KMS-Signaturprotokolle für das Zertifikat abgleichen.
Zertifikatsausstellung mit Cloud KMS-Signaturprotokollen prüfen
So rufen Sie Cloud KMS-Signaturereignisse für die Ereignisse zur Zertifikatsausstellung des CA-Dienstes auf:
Rufen Sie in der Google Cloud Console die Seite Log-Explorer auf.
Fügen Sie den folgenden Ausdruck in das Feld des Abfrageeditors ein:
protoPayload.request.digest.sha256="DIGEST_VALUE" protoPayload.@type="type.googleapis.com/google.cloud.audit.AuditLog" protoPayload.methodName="AsymmetricSign" protoPayload.serviceName="cloudkms.googleapis.com"
Ersetzen Sie
DIGEST_VALUE
durch den Hashwert aus dem Abschnitt Zertifikatsausstellung mit CA Service-Protokollen überprüfen.Klicken Sie auf Abfrage ausführen.
Diese Abfrage gibt die Protokolle für Ereignisse zur Zertifikatsausstellung zurück. Cloud KMS-Logs unterscheiden nicht zwischen Zertifikaten und JWTs. Daher sind die Logeinträge für beide identisch.
Tokens prüfen
Mithilfe von GKE-Kontrollbereichsprotokollen zur Ausstellun von Identitäten von Zertifizierungsstellen und Cloud KMS-Signaturprotokollen können Sie prüfen, ob ein JSON Web Token (JWT) erfolgreich ausgestellt wurde.
Die Rückverfolgung des Ereignisses zur Tokenausgabe beginnt in der Regel mit der Überwachung des Kubernetes API-Logs auf Dienstkontoaktivitäten. Wenn Sie ein Aktivitätsprotokoll gefunden haben, das einer weiteren Untersuchung bedarf, können Sie anhand der folgenden Protokolle Informationen zur Ausstellung und Verwendung von Anmeldedaten bestätigen:
JWT-Protokolle |
|
---|---|
Kubernetes API-Log für die Verwendung von JWT |
Hier werden die Details der JWT-Signatur protokolliert, wenn ein JWT für die Kubernetes API verwendet wird. |
GKE-Protokoll für JWT-Ausstellungsvorgänge |
Alle Vorgänge zur Tokenausgabe werden als Audit-Log zu Systemereignissen protokolliert. Diese Protokolle sind standardmäßig in allen Clustern aktiviert, in denen von Nutzern verwaltete Schlüssel oder Zertifizierungsstellen der GKE-Steuerungsebene verwendet werden. |
Cloud KMS-Audit-Log |
Es wird ein Eintrag protokolliert, wenn ein Token signiert und ausgestellt wird. |
Tokennutzung mit Kubernetes API-Server-Logs prüfen
So rufen Sie Logeinträge für Ereignisse zur Tokennutzung auf:
Rufen Sie in der Google Cloud Console die Seite Log-Explorer auf.
Fügen Sie den folgenden Ausdruck in das Feld des Abfrageeditors ein:
log_id("cloudaudit.googleapis.com/activity") resource.type="k8s_cluster" labels."authentication.kubernetes.io/credential-id":"JTI="
Klicken Sie auf Abfrage ausführen.
Mit dieser Abfrage werden alle Kubernetes API-Server-Logs zurückgegeben, die einem JWT zugeordnet sind. Suchen Sie mithilfe Ihrer Sicherheitstools oder manuell nach bestimmten Logeinträgen, die Sie untersuchen möchten.
Wenn Sie diese Protokolle mit anderen Protokolltypen in Beziehung setzen möchten, suchen Sie nach dem folgenden Feld:
"authentication.k8s.io/credential-id": "JTI=JWT_ID"
Die JWT_ID
ist die Token-ID, mit der Sie Logs aus GKE und Cloud KMS in Beziehung setzen können.
Tokenausgabe mit GKE-Logs prüfen
So rufen Sie Logeinträge für Ereignisse zur Tokenausgabe auf:
Rufen Sie in der Google Cloud Console die Seite Log-Explorer auf.
Fügen Sie den folgenden Ausdruck in das Feld des Abfrageeditors ein:
resource.type="gke_cluster" logName="projects/PROJECT_ID/logs/cloudaudit.googleapis.com%2Fsystem_event" protoPayload.methodName="google.cloud.gkeauth.v1.Auth.SignServiceAccountJWT" protoPayload.metadata.credentialId="JTI=JWT_ID"
Ersetzen Sie Folgendes:
PROJECT_ID
: Ihre Projekt-ID.JWT_ID
: die JWT-ID aus dem Abschnitt Tokennutzung mit Kubernetes API-Server-Logs überprüfen.
Klicken Sie auf Abfrage ausführen.
Diese Abfrage gibt Protokolle zurück, die ein
toBeSignedDigest
-Feld enthalten.
Mit dem Wert toBeSignedDigest
können Sie nach Cloud KMS-Signaturereignissen suchen.
Tokenausgabe mit Cloud KMS-Signaturprotokollen prüfen
So finden Sie Logeinträge für signierte Digests:
Rufen Sie in der Google Cloud Console die Seite Log-Explorer auf.
Fügen Sie den folgenden Ausdruck in das Feld des Abfrageeditors ein:
protoPayload.request.digest.sha256="DIGEST_VALUE" protoPayload.@type="type.googleapis.com/google.cloud.audit.AuditLog" protoPayload.methodName="AsymmetricSign" protoPayload.serviceName="cloudkms.googleapis.com"
Ersetzen Sie
DIGEST_VALUE
durch den Wert im FeldtoBeSignedDigest
aus dem Abschnitt Tokenausgabe mit GKE-Logs überprüfen.Klicken Sie auf Abfrage ausführen.
Diese Abfrage gibt die Protokolle für Ereignisse zur Zertifikatsausstellung zurück. Cloud KMS-Logs unterscheiden nicht zwischen Zertifikaten und JWTs. Daher sind die Logeinträge für beide identisch.
Nächste Schritte
- Sicherheit der Steuerungsebene
- Weitere Informationen zum Administratorzugriff für Google-Mitarbeiter
- Weitere Informationen zum Konfigurieren von Logging und Monitoring für GKE
- Weitere Informationen zum Konfigurieren des Zugriffs auf Protokolle auf Feldebene
- Weitere Informationen zu Nutzungslimits für Logging