Amazon-EKS-Sicherheit mit RBAC, sicherem IMDS und Audit-Protokollierung stärken

Fehlkonfigurationen in Infrastructure as Code (IaC) können genauso gefährlich sein wie Schwachstellen im Code. Schon kleine Konfigurationsfehler können dazu führen, dass vertrauliche Daten im Internet lesbar sind oder private Endpunkte und Dashboards für anonyme Nutzer zugänglich und als erster Angriffspunkt missbraucht werden. Aktuelle Erkenntnisse aus der Sicherheitsforschung zeigen, dass Malware zunehmend auf die Kubernetes-Plattform abzielt – ein weiterer Beleg dafür, wie wichtig sichere Konfigurationen sind.

In dieser Blogbeitragsreihe sehen wir uns die Standardeinstellungen von Amazon-Elastic-Kubernetes-Service-(EKS)-Deployments an. Anschließend zeigen wir, wie kleine Fehlkonfigurationen oder unerwünschte Nebeneffekte unsere Cluster gefährden und Sicherheitsprobleme in EKS verursachen können.

Was ist Amazon Elastic Kubernetes Service?

Amazon Elastic Kubernetes Service ist ein verwalteter Kubernetes-Service. AWS übernimmt die Verwaltung der Control-Plane-Komponenten des Clusters. Für die Verwaltung der Worker-Knoten und Cluster-Ressourcen ist der Kunde verantwortlich.

Neben den Vorteilen einer hohen Verfügbarkeit und Skalierbarkeit der Control Plane bietet Amazon EKS eine Integration mit Identity and Access Management zur Verwaltung von rollenbasierter Zugriffskontrolle, die Möglichkeit, Kubernetes-Service-Accounts IAM-Rollen zuzuordnen, verwaltete Knotengruppen zur automatischen Skalierung der Worker-Kapazität je nach Bedarf, zentralisierte Protokollierung und mehr. Eine vollständige Liste der Funktionen finden Sie in der offiziellen Amazon-EKS-Dokumentation.

Zu den Nachteilen eines verwalteten Service zählen neben den zusätzlichen Kosten die eingeschränkte granulare Kontrolle über die Control-Plane-Einstellungen sowie die Tatsache, dass die in der Control-Plane-Datenbank gespeicherten Daten in AWS-eigenen Konten liegen müssen.

Schnelles EKS-Deployment

Amazon EKS lässt sich auf verschiedene Arten bereitstellen, zum Beispiel über eine Webkonsole, das dedizierte Amazon-EKS-Befehlszeilentool oder IaC-Tools wie CloudFormation oder Terraform.

Für die Bereitstellung eines Clusters mit Standardwerten verwenden wir Terraform. Die Terraform-Konfigurationsdateien für diese Demo finden Sie in diesem Repository. Wir verwenden Terraform Cloud, um Terraform-Befehle auszuführen und Zustandsänderungen zu speichern.

Der EKS-Cluster muss innerhalb einer VPC ausgeführt werden. Mit Terraform können Sie eine VPC mithilfe dieses Moduls bereitstellen.

1module "vpc" {
2  source = "terraform-aws-modules/vpc/aws"
3
4  name = local.cluster_name
5  cidr = var.vpc_cidr
6
7  azs             = var.vpc_azs
8  private_subnets = var.private_subnet_cidrs
9  public_subnets  = var.public_subnet_cidrs
10
11  enable_nat_gateway     = var.enable_nat_gateway
12  single_nat_gateway     = var.single_nat_gateway
13  one_nat_gateway_per_az = var.one_nat_gateway_per_az
14}

In unserer Demo-Umgebung stellen wir drei private und drei öffentliche Subnetze bereit. Private Subnetze verfügen nicht über eine Standardroute zum Internet-Gateway. Ein NAT-Gateway ermöglicht den privaten Subnetzen den Internetzugriff. Hinweis: Für die Demo stellen wir nur ein einzelnes NAT-Gateway bereit. Die Netzwerkarchitektur unserer Demo-Umgebung ist unten auf hoher Ebene dargestellt.

Der EKS-Cluster benötigt die ID einer vorhandenen VPC sowie Subnetz-IDs, über die die Kommunikation mit den Knotenpools und die Bereitstellung von Load-Balancern für Services und Ingress-Controller erfolgt. Als Teil unserer Demo-Umgebung stellen wir eine selbstverwaltete Knotengruppe mit drei Instanzen bereit.

1module "cluster" {
2  source          = "terraform-aws-modules/eks/aws"
3  cluster_name    = local.cluster_name
4  cluster_version = var.cluster_version
5  subnets         = module.vpc.private_subnets
6  vpc_id          = module.vpc.vpc_id
7
8  worker_groups = [
9    {
10      instance_type = var.wg_instance_type
11      asg_max_size  = var.wg_asg_max_size
12    }
13  ]
14}

Mit Terraform Cloud können Sie Pläne über die Benutzeroberfläche oder per Remote-Operationen ausführen. Um Aktionen über die Benutzeroberfläche auszulösen, müssen Sie den Code in das Versionskontrollsystem committen. Mit Remote-Operationen erhalten Sie schnell Feedback zum Zustand lokaler Konfigurationsdateien. Im Hintergrund lädt Terraform ein Archiv der lokalen Konfigurationsdateien auf einen Remote-Server hoch, führt den Befehl dort aus und überträgt die Ergebnisse zurück an Ihr Terminal. Um eine von Terraform Cloud verwaltete Zustandsdatei zu verwenden, müssen wir eine backend-Konfiguration mit dem richtigen Workspace und der richtigen Organisation hinzufügen.

1terraform {
2  backend "remote" {
3    hostname = "app.terraform.io"
4    # TODO: update with your own organization
5    organization = "your-unique-organization-name"
6
7    workspaces {
8      name = "eks-demo-deployments"
9    }
10  }
11}

Dafür ist außerdem der API-Zugriff auf Terraform Cloud erforderlich. Einzelheiten zur Konfiguration finden Sie in der offiziellen Terraform-Cloud-Dokumentation.

Der erste Plan zeigt, dass unsere Konfigurationsdateien 44 neue Ressourcen erstellen werden.

1dev@pwnbox:adversarialengineering/eks-demo-deployments/terraform/default$ terraform plan
2Running plan in the remote backend. Output will stream here. Pressing Ctrl-C
3will stop streaming the logs, but will not stop the plan running remotely.
4
5Preparing the remote plan...
6
7The remote workspace is configured to work with configuration at
8terraform/default/ relative to the target repository.
9<OMITTED>
10     + tags                             = {
11          + "Name" = "eks-threat-modelling-5FZtd82l"
12        }
13      + tags_all                         = {
14          + "Name" = "eks-threat-modelling-5FZtd82l"
15        }
16    }
17
18Plan: 44 to add, 0 to change, 0 to destroy.

Nun können wir die Umgebung über die Terraform-Cloud-Benutzeroberfläche bereitstellen. Anschließend sollten sich auf der Übersichtsseite Ausgabedaten zu unserem neuen Cluster abrufen lassen.

Nach der Bereitstellung der Umgebung können wir anhand der offiziellen AWS-Dokumentation auf den Demo-Cluster zugreifen.

1dev@pwnbox:~$ aws eks --region eu-west-1 update-kubeconfig --name eks-threat-modelling-5FZtd82l
2Added new context arn:aws:eks:eu-west-1:123456789012:cluster/eks-threat-modelling-5FZtd82l to /home/dev/.kube/config
3dev@pwnbox:~$ kubectl get svc
4NAME         TYPE        CLUSTER-IP   EXTERNAL-IP   PORT(S)   AGE
5kubernetes   ClusterIP   172.20.0.1   <none>        443/TCP   15m
6dev@pwnbox:~$

Dieser Cluster dient als Grundlage für unsere Bewertung. Beginnen wir mit der ersten Beobachtung: Wie einfach konnten wir eine Verbindung zum Cluster herstellen?

Zugriff auf die Kubernetes-API einschränken

Der EKS-Service ermöglicht den Zugriff auf die Kubernetes-API über Service-Endpunkte. Standardmäßig ist der Endpunkt des Clusters öffentlich zugänglich. Das bedeutet, dass jeder im Internet versuchen kann, darauf zuzugreifen. Die Kubernetes-API akzeptiert standardmäßig anonyme Anfragen. Sowohl ABAC- als auch RBAC-Autorisierer verlangen jedoch eine ausdrückliche Autorisierung für anonyme bzw. nicht authentifizierte Nutzer. In EKS-Clustern ist RBAC standardmäßig aktiviert. Das können wir anhand der API-Server-Flags überprüfen.

1FLAG: --authentication-token-webhook-cache-ttl="7m0s"
2FLAG: --authentication-token-webhook-config-file="/etc/kubernetes/authenticator/apiserver-webhook-kubeconfig.yaml"
3FLAG: --authentication-token-webhook-version="v1beta1"
4FLAG: --authorization-mode="[Node,RBAC]"
5FLAG: --authorization-policy-file=""
6FLAG: --authorization-webhook-cache-authorized-ttl="5m0s"
7FLAG: --authorization-webhook-cache-unauthorized-ttl="30s"
8FLAG: --authorization-webhook-config-file=""
9FLAG: --authorization-webhook-version="v1beta1"

Die Protokolle zeigen außerdem, dass EKS eine Webhook-Token-Authentifizierungsmethode implementiert. Das bedeutet, dass Kubernetes-Nutzer das Authentifizierungstoken über die AWS-API abrufen müssen, die vom Kubernetes-API-Endpunkt des Clusters getrennt ist. Amazon EKS hat keinen Einfluss auf die Autorisierungsentscheidungen des Clusters.

Um noch sicherer zu sein, können wir versuchen, ohne authentifizierte Anmeldedaten eine Verbindung zum Cluster herzustellen. Um anonyme Nutzer zu simulieren, müssen wir eine Anfrage ohne Autorisierungsheader an die API senden. kubectl verfügt über eine sehr nützliche Debug-Option, die alle Anfragen als CURL-Befehle ausgibt, die wir wiederverwenden können.

1dev@pwnbox:$ kubectl get pod -v 9
2<OMITTED>
3I0620 13:50:56.340980      19 round_trippers.go:425] curl -k -v -XGET  -H "Accept: application/json;as=Table;v=v1;g=meta.k8s.io,application/json;as=Table;v=v1beta1;g=meta.k8s.io,application/json" -H "User-Agent: kubectl/v1.20.1 (linux/amd64) kubernetes/c4d7527" 'https://DC83F13246D9B2E468D2CAAD692EAF22.yl4.eu-west-1.eks.amazonaws.com/api/v1/namespaces/default/pods?limit=500'
4I0620 13:50:56.435282      19 round_trippers.go:445] GET https://DC83F13246D9B2E468D2CAAD692EAF22.yl4.eu-west-1.eks.amazonaws.com/api/v1/namespaces/default/pods?limit=500 200 OK in 94 milliseconds
5I0620 13:50:56.435317      19 round_trippers.go:451] Response Headers:
6I0620 13:50:56.435326      19 round_trippers.go:454]     Audit-Id: 4814a650-c35b-4c98-bc0c-ba22fb3d58ce
7I0620 13:50:56.435334      19 round_trippers.go:454]     Cache-Control: no-cache, private
8I0620 13:50:56.435342      19 round_trippers.go:454]     Content-Type: application/json
9I0620 13:50:56.435349      19 round_trippers.go:454]     Content-Length: 2926
10I0620 13:50:56.435356      19 round_trippers.go:454]     Date: Sun, 20 Jun 2021 13:50:56 GMT
11I0620 13:50:56.436467      19 request.go:1107] Response Body: {"kind":"Table","apiVersion":"meta.k8s.io/v1","metadata":{"selfLink":"/api/v1/namespaces/default/pods","resourceVersion":"12794"},"columnDefinitions"

Wenn wir dieselbe Anfrage ohne den korrekten Autorisierungsheader senden, sehen wir, dass sie nicht autorisiert wurde.

1dev@pwnbox:$ curl -k -v -XGET  https://DC83F13246D9B2E468D2CAAD692EAF22.yl4.eu-west-1.eks.amazonaws.com/api/v1/namespaces/default/pods?limit=500'
2<OMITTED>
3{
4  "kind": "Status",
5  "apiVersion": "v1",
6  "metadata": {
7
8  },
9  "status": "Failure",
10  "message": "pods is forbidden: User \"system:anonymous\" cannot list resource \"pods\" in API group \"\" in the namespace \"default\"",
11  "reason": "Forbidden",
12  "details": {
13    "kind": "pods"
14  },
15  "code": 403

Nachdem wir nun überprüft haben, dass der Zugriff auf unsere Ressourcen standardmäßig zumindest teilweise eingeschränkt ist, sollten wir das Prinzip der mehrschichtigen Verteidigung betrachten. Damit ist gemeint, verschiedene Arten von Sicherheitskontrollen zu schichten, um eineneinzelnen Ausfallpunkt in unserem Sicherheitssystem zu vermeiden. In unserem aktuellen Deployment sind RBAC-Berechtigungen die einzige Maßnahme, die verhindert, dass beliebige Personen aus dem Internet auf unseren Cluster zugreifen.

Diese Konfigurationsdatei zeigt, wie sich anonymer Zugriff einrichten ließe:

1apiVersion: rbac.authorization.k8s.io/v1
2kind: ClusterRoleBinding
3metadata:
4  name: read-only
5subjects:
6- kind: User
7  name: system:anonymous
8roleRef:
9  kind: ClusterRole
10  name: view
11  apiGroup: rbac.authorization.k8s.io

Nach dem Anwenden dieser Konfiguration sehen wir, dass die anonyme Anfrage erfolgreich ist:

1dev@pwnbox:$ curl -k -v -XGET https://DC83F13246D9B2E468D2CAAD692EAF22.yl4.eu-west-1.eks.amazonaws.com/api/v1/namespaces/default/pods?limit=500'
2<OMITTED>
3{
4  "kind": "PodList",
5  "apiVersion": "v1",
6  "metadata": {
7    "selfLink": "/api/v1/namespaces/default/pods",
8    "resourceVersion": "15018"
9  },
10  "items": []

Die Kubernetes-Entwickler haben Sicherheitsmaßnahmen eingeführt, um sicherzustellen, dass diese Art von Konfiguration ausdrücklich vorgenommen wird. Der Nutzer system:anonymous und die Gruppe system:unauthenticated müssen ausdrücklich im Attribut subjects aufgeführt sein. Platzhalter wie * gewähren diesen beiden Subjekten keinen Zugriff. Sie können das testen, indem Sie in unserem Beispiel den name des Subjekts durch das Zeichen * ersetzen.

Öffentlicher Zugriff auf den Kubernetes-API-Server erhöht außerdem die Auswirkungen eines kompromittierten Anmeldedatensatzes. Bei einer öffentlich zugänglichen API können die gestohlenen Anmeldedaten potenziell von überall auf der Welt verwendet werden. Eine weitere wichtige Begründung dafür, den Kreis der Systeme einzuschränken, die Pakete an den API-Server senden können, ist eine entdeckte Zero-Day-Schwachstelle im Autorisierungsablauf. In der Vergangenheit wurden beispielsweise die Schwachstellen CVE-2019-11253 und CVE-2020-8559 gemeldet.

Die Auswirkungen öffentlicher Endpunkte lassen sich reduzieren, indem Sie den Zugriff auf bestimmte IP-Adressen beschränken. In Terraform wird dies umgesetzt, indem Sie dem Modul die Eigenschaft cluster_endpoint_public_access_cidrs hinzufügen.

Die zweite Möglichkeit besteht darin, den öffentlichen Endpunkt vollständig zu deaktivieren und einen privaten VPC-Endpunkt zu aktivieren. Dazu können im Terraform-Modul die Eigenschaften cluster_endpoint_private_access und cluster_endpoint_public_access aktiviert bzw. deaktiviert werden. Dadurch ist sichergestellt, dass nur Nutzer mit Zugriff auf das VPC-Netzwerk auf den Cluster zugreifen können.

Beide Optionen haben jedoch erhebliche Auswirkungen auf die Betriebskosten. Ein fehlender öffentlicher Endpunkt kann bei der Verwendung eines öffentlichen Continuous-Deployment-Systems wie Terraform Cloud problematisch sein. In unserer Demo-Umgebung führte die Deaktivierung des öffentlichen Endpunkts dazu, dass das Deployment mit folgendem Fehler wegen verweigerten Zugriffs fehlschlug.

Dieser Fehler tritt auf, weil das Terraform-Modul intern versucht, die Config-Map aws-auth zu aktualisieren, was nur über die Kubernetes-API möglich ist. Wie Sie sehen, wurde der FQDN des API-Servers in eine private IP-Adresse aufgelöst, die vom Provider nicht erreicht werden kann. Wir können den Fehler beheben, indem wir die Verwaltung der Config-Map über unser Terraform-Modul deaktivieren. Das bedeutet, dass wir die Autorisierungs-Config-Map von diesem Zeitpunkt an mit einer anderen Methode verwalten müssen.

Um den öffentlichen Endpunkt vollständig zu deaktivieren, müssen Sie ein CD-System implementieren, das entweder innerhalb der VPC mit Zugriff auf den privaten Endpunkt ausgeführt wird oder die Verbindung über einen Proxy herstellt. Dieser Beitrag erklärt anschaulich, wie sich das mit AWS CodePipeline umsetzen lässt. Mit diesem Terraform-Modul können Sie Atlantis innerhalb des AWS-Fargate-Service ausführen.

Auch der Zugriff für Entwickler kann komplizierter werden, da Sie einen Bastion- oder VPN-Service einrichten müssen, um den Zugriff auf den privaten Endpunkt zu ermöglichen.

Zugriff auf den Instance-Metadata-Service einschränken

EKS nutzt Instance-Profile, um einem auf einem Knoten ausgeführten Kubelet AWS-Berechtigungen zu gewähren. Das Kubelet kann über den Instance-Metadata-Service (IMDS) auf diese Anmeldedaten zugreifen. Der IMDS ist über eine HTTP-Anfrage an eine link-lokale IP-Adresse erreichbar. Standardmäßig ist dieser Metadata-Service für alle Pods auf dem Knoten erreichbar. Das lässt sich testen, indem Sie einen Pod ausführen und ein STS-Token abrufen.

1apiVersion: v1
2kind: Pod
3metadata:
4  name: aws
5  namespace: default
6spec:
7  containers:
8  - name: aws
9    image: amazon/aws-cli:latest
10    command:
11      - sleep
12      - "3600"
13    imagePullPolicy: IfNotPresent
14  restartPolicy: Always
15
16dev@pwnbox:$ kubectl exec -it aws -- /bin/bash
17bash-4.2# aws sts get-caller-identity
18{
19    "UserId": "AROAYREY3WYOLQYZ5IGZJ:i-0f52c37fc0a7a4a44",
20    "Account": "123456789012",
21    "Arn": "arn:aws:sts::123456789012:assumed-role/eks-threat-modelling-5FZtd82l20210620220209389400000009/i-0f52c37fc0a7a4a44"
22}
23bash-4.2#

Im obigen Beispiel können wir alle dem Knoten zugewiesenen Berechtigungen nutzen. Dies ist ein eindeutiges Sicherheitsproblem durch eine Ausweitung von Berechtigungen, da Pods standardmäßig keinen AWS-Zugriff benötigen sollten.

Die einzige Möglichkeit, dieses Problem zu entschärfen, besteht darin, den Netzwerkzugriff der Pods auf den IMDS einzuschränken. Der IMDS liegt in zwei Versionen vor. Version 1 verwendet ein Anfrage-Antwort-Verfahren und kann von jedem Prozess abgefragt werden, der Pakete an die link-lokale Adresse senden kann. Version 2 basiert auf Sitzungen und ermöglicht es, eine beliebige Time-to-live-(TTL-)Dauer für Antwortnachrichten festzulegen. Laut der AWS-Dokumentation bleibt IMDSv1 neben IMDSv2 verfügbar.

Um das Ausmaß dieses Problems mit nativer AWS-Konfiguration einzuschränken, müssen wir IMDSv1 vollständig deaktivieren. Dazu setzen Sie das Attribut metadata_http_tokens der Worker-Knoten auf required. Als zweiten Schritt beschränken Sie die TTL der Antwortpakete auf 1 – dies entspricht bereits dem Standardverhalten des Service. Bei einer TTL von 1 kann die Kubernetes-Netzwerkschicht das Paket nicht an den Netzwerk-Namespace des Pods weiterleiten.

1dev@pwnbox:$ kubectl exec -it aws -- aws sts get-caller-identity
2
3Unable to locate credentials. You can configure credentials by running "aws configure".
4command terminated with exit code 253

Das Terraform-Modul für Amazon EKS verwendet Auto-Scaling-Gruppen und Launch-Vorlagen, um Knoten zu erstellen. Daher müssen die Instanzen aktualisiert werden, wenn Sie die Einstellungen des Metadata-Service ändern.

Die Einschränkung dieser Lösung besteht darin, dass jeder Pod, bei dem das Attribut hostNetworking auf true gesetzt ist, weiterhin auf die Anmeldedaten zugreifen kann.

1apiVersion: v1
2kind: Pod
3metadata:
4  name: aws-node
5  namespace: default
6spec:
7  hostNetwork: true
8  containers:
9  - name: aws-node
10    image: amazon/aws-cli:latest
11    command:
12      - sleep
13      - "3600"
14    imagePullPolicy: IfNotPresent
15  restartPolicy: Always
16
17dev@pwnbox:$ kubectl exec -it aws-node -- aws sts get-caller-identity
18{
19    "UserId": "AROAYREY3WYOLQYZ5IGZJ:i-0e0ecce7af113398b",
20    "Account": "123456789012",
21    "Arn": "arn:aws:sts::123456789012:assumed-role/eks-threat-modelling-5FZtd82l20210620220209389400000009/i-0e0ecce7af113398b"
22}
23

Mit nativen Kubernetes-Netzwerkrichtlinien lässt sich der Zugriff auf link-lokale IP-Adressen ebenfalls einschränken und damit der Zugriff auf den IMDS verhindern. Die AWS-Calico-Dokumentation enthält Anweisungen zur Installation des Calico-CNI-Plugins. Die folgende Netzwerkrichtlinie sollte den Zugriff auf den IMDS verhindern. Das Calico-Plugin isoliert keine Pods, bei denen hostNetwork auf true gesetzt ist. Daher gilt hier derselbe Nachteil wie bei der nativen Lösung, bei der IMDSv1 deaktiviert und die maximale TTL auf 1 gesetzt wird. Netzwerkrichtlinien erfordern allerdings keinen Austausch der Knoten und lassen sich auf bestimmte Pods anwenden, falls der IMDS innerhalb eines Pods benötigt wird.

1apiVersion: crd.projectcalico.org/v1
2kind: GlobalNetworkPolicy
3metadata:
4  name: block-metadata-egress-only
5spec:
6  selector: all()
7  egress:
8  - action: Deny
9    protocol: TCP
10    destination:
11      nets:
12      - 169.254.169.254/32
13  - action: Allow
14    destination:
15      nets:
16      - 0.0.0.0/0
17
18dev@pwnbox:$ kubectl exec -it aws -- aws sts get-caller-identity
19{
20    "UserId": "AROAYREY3WYOLQYZ5IGZJ:i-06a05d6ddfff5b2bd",
21    "Account": "123456789012",
22    "Arn": "arn:aws:sts::123456789012:assumed-role/eks-threat-modelling-5FZtd82l20210620220209389400000009/i-06a05d6ddfff5b2bd"
23}
24dev@pwnbox:$ kubectl apply -f tests/disable-imds-network-access/network-policy.yaml
25globalnetworkpolicy.crd.projectcalico.org/allow-all-egress-except-ec2-metadata created
26dev@pwnbox:$ kubectl exec -it aws -- aws sts get-caller-identity
27
28Unable to locate credentials. You can configure credentials by running "aws configure".
29command terminated with exit code 253
30dev@pwnbox:$

Protokollierung aktivieren

Nachdem wir uns nun einige Fehlkonfigurationen angesehen haben, die EKS-Cluster externen und internen Bedrohungen aussetzen können, wollen wir prüfen, ob sich diese Ereignisse auditieren lassen. Kubernetes stellt Audit-Logs bereit, mit denen Administratoren alle Aktionen von Cluster-Nutzern und -Diensten überwachen können. Leider sind diese Logs weder in EKS noch in der Standardkonfiguration des Terraform-Moduls standardmäßig aktiviert. Um sie zu aktivieren, müssen wir das Attribut cluster_enabled_log_types verwenden und die erforderlichen Log-Typen angeben.

In EKS lassen sich mehrere Log-Typen unabhängig voneinander aktivieren. Aus Sicherheitssicht interessieren uns vor allem audit- und authenticator-Logs.

Audit-Logs ermöglichen es uns, Kubernetes-Anfragen zu überwachen und den jeweiligen Entitäten zuzuordnen. Beachten Sie, dass Audit-Logs für jede im Cluster ausgeführte Aktion Ereignisse erzeugen und daher große Datenmengen an das konfigurierte Ziel streamen, standardmäßig an CloudWatch. Wenn wir uns auf audit und authenticator beschränken, bleibt das Datenvolumen geringer.

Zum Beispiel können wir nach Änderungen an der aws-config-Map suchen, um festzustellen, ob jemand sie manipuliert hat. Mit dem folgenden Filter lassen sich alle Patch-Ereignisse zu einem Objekt mit dem Namen aws-auth abrufen.

1{ ($.verb = "patch") && ($.objectRef.name = "aws-auth") }

Audit-Ereignisse enthalten sehr nützliche Informationen, die uns dabei helfen können, herauszufinden, wer die Änderung vorgenommen hat, von wo aus die Verbindung hergestellt wurde und vieles mehr.

1{
2    "kind": "Event",
3    "apiVersion": "audit.k8s.io/v1",
4    "level": "RequestResponse",
5    "auditID": "844b26da-3ce9-4062-b7aa-3c0a869d9e45",
6    "stage": "ResponseComplete",
7    "requestURI": "/api/v1/namespaces/kube-system/configmaps/aws-auth?fieldManager=kubectl-edit",
8    "verb": "patch",
9    "user": {
10        "username": "kubernetes-admin",
11        "uid": "heptio-authenticator-aws:123456789012:AROAYREY3WYOBFHU7VIRM",
12        "groups": [
13            "system:masters",
14            "system:authenticated"
15        ],
16        "extra": {
17            "accessKeyId": [
18                "ASIAYREY3WYOETXWXAOG"
19            ]
20        }
21    },
22    "sourceIPs": [
23        "12.34.256.27"
24    ],
25    "userAgent": "kubectl/v1.20.1 (linux/amd64) kubernetes/c4d7527",
26    "objectRef": {
27        "resource": "configmaps",
28        "namespace": "kube-system",
29        "name": "aws-auth",
30        "apiVersion": "v1"
31    },
32    "responseStatus": {
33        "metadata": {},
34        "code": 200
35    },
36    <OMITTED>

Diese Logs können auch sehr hilfreich sein, um Zugriffsversuche nicht autorisierter Nutzer auf Ressourcen zu erkennen. Mit der folgenden Abfrage können Sie nach Anfragen eines anonymen Nutzers suchen:

1{ ($.user.username = *anonymous) }
2
3{
4    "kind": "Event",
5    "apiVersion": "audit.k8s.io/v1",
6    "level": "Metadata",
7    "auditID": "68f24024-080b-4ae7-a97b-fd5fd9792e31",
8    "stage": "ResponseComplete",
9    "requestURI": "/api/v1/namespaces/kube-system/configmaps/aws-auth",
10    "verb": "get",
11    "user": {
12        "username": "system:anonymous",
13        "groups": [
14            "system:unauthenticated"
15        ]
16    },
17    "sourceIPs": [
18        "12.34.256.27"
19    ],
20    "userAgent": "kubectl/v1.20.1 (linux/amd64) kubernetes/c4d7527",
21    "objectRef": {
22        "resource": "configmaps",
23        "namespace": "kube-system",
24        "name": "aws-auth",
25        "apiVersion": "v1"
26    },
27    "responseStatus": {
28        "metadata": {},
29        "status": "Failure",
30        "reason": "Forbidden",
31        "code": 403
32    },
33    "requestReceivedTimestamp": "2021-06-21T17:08:02.384514Z",
34    "stageTimestamp": "2021-06-21T17:08:02.384693Z",
35    "annotations": {
36        "authorization.k8s.io/decision": "forbid",
37        "authorization.k8s.io/reason": ""
38    }
39}

Authenticator-Logs wiederum können uns dabei helfen, nachzuverfolgen, wer versucht, sich beim Cluster anzumelden, und diese Entitäten Kubernetes-Gruppen und -Nutzern zuzuordnen. Aus dem vorherigen Beispiel wissen wir, dass der Nutzer mit der Schlüssel-ID AROAYREY3WYOBFHU7VIRM die ConfigMap geändert hat. Wir wissen jedoch nicht, zu welcher AWS-Entität diese Schlüssel-ID gehört.

1ime="2021-06-21T16:32:01Z" level=info msg="access granted" arn="arn:aws:iam::123456789012:role/ci" client="127.0.0.1:39092" groups="[system:masters]" method=POST path=/authenticate sts=sts.eu-west-1.amazonaws.com uid="heptio-authenticator-aws:123456789012:AROAYREY3WYOBFHU7VIRM" username=kubernetes-admin

Als Nächstes: Erweiterte Absicherung von Amazon EKS

In diesem Blogbeitrag haben wir einige Sicherheitsprobleme untersucht, die bei der Verwendung von Amazon Elastic Kubernetes Service auftreten können, darunter Authentifizierung und Autorisierung sowie der Zugriff auf den Instance Metadata Service. Außerdem haben wir gesehen, wie sich diese Probleme in Produktionsumgebungen entschärfen lassen. Im nächsten Teil dieser Serie untersuchen wir die Multi-Account-Architektur als wichtigen Schritt zur Isolierung von Amazon-EKS-Clustern, die Bedeutung dedizierter IAM-Rollen beim Erstellen von Amazon-EKS-Clustern und den Schutz von Secrets, die in Amazon-EKS-Control-Planes gespeichert sind. Lesen Sie den nächsten Beitrag oder folgen Sie uns auf Twitter unter @snkysec, um benachrichtigt zu werden, sobald er veröffentlicht wird.

Mit dem Scanning von Snyk Infrastructure as Code (Snyk IaC) lassen sich Sicherheitsprobleme bei der Verwendung von Amazon EKS mit Cloud Formation oder Terraform ebenfalls entschärfen: Es erkennt Sicherheitsprobleme in Ihrem Deployment-Code, bevor dieser die Produktionsumgebung erreicht. Melden Sie sich kostenlos an und starten Sie mit dem Scanning!