Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Identitäts- und Zugriffsverwaltung

Identity and Access Management (IAM) ist ein AWS-Service, der zwei wichtige Funktionen erfüllt: Authentifizierung und Autorisierung. Die Authentifizierung beinhaltet die Überprüfung einer Identität, während die Autorisierung die Aktionen regelt, die von AWS-Ressourcen ausgeführt werden können. Innerhalb von AWS kann eine Ressource ein anderer AWS-Service sein, z. B. EC2, oder ein AWS-Prinzipal wie ein IAM-Benutzer oder eine IAM-Rolle. https://docs.aws.amazon.com/IAM/latest/UserGuide/id.html#id_iam-roles Die Regeln, die die Aktionen regeln, die eine Ressource ausführen darf, werden als IAM-Richtlinien ausgedrückt.

Steuerung des Zugriffs auf EKS-Cluster

Das Kubernetes-Projekt unterstützt eine Vielzahl verschiedener Strategien zur Authentifizierung von Anfragen an den Kube-Apiserver-Dienst, z. B. Bearer Tokens, Zertifikate, OIDC usw. X.509 EKS bietet derzeit native Unterstützung für die Webhook-Token-Authentifizierung, Dienstkonto-Token und seit dem 21. Februar 2021 die OIDC-Authentifizierung.

Die Webhook-Authentifizierungsstrategie ruft einen Webhook auf, der Träger-Token verifiziert. Auf EKS werden diese Bearer-Token von der AWS-CLI oder dem https://github.com/kubernetes-sigs/aws-iam-authenticator aws-iam-authenticator-Client generiert, wenn Sie Befehle ausführen. kubectl Während Sie Befehle ausführen, wird das Token an den Kube-Apiserver übergeben, der es an den Authentifizierungs-Webhook weiterleitet. Wenn die Anfrage wohlgeformt ist, ruft der Webhook eine vorsignierte URL auf, die in den Hauptteil des Tokens eingebettet ist. Diese URL validiert die Signatur der Anfrage und gibt Informationen über den Benutzer zurück, z. B. das Benutzerkonto, Arn, und UserId an den Kube-Apiserver.

Um ein Authentifizierungstoken manuell zu generieren, geben Sie den folgenden Befehl in ein Terminalfenster ein:

aws eks get-token --cluster-name <cluster_name> --region <region>

Die Ausgabe sollte wie folgt aussehen:

{
    "kind": "ExecCredential",
    "apiVersion": "client.authentication.k8s.io/v1alpha1",
    "spec": {},
    "status": {
        "expirationTimestamp": "2024-12-20T17:38:48Z",
        "token": "k8s-aws-v1.aHR0cHM6Ly9zdHMudXMtd2VzdC0yLmFtYXpvbmF3cy5jb20vP0FjdGlvbj1HZ...."
    }
}

Sie können ein Token auch programmgesteuert abrufen. Unten ist ein in Go geschriebenes Beispiel:

package main

import (
  "fmt"
  "log"
  "sigs.k8s.io/aws-iam-authenticator/pkg/token"
)

func main()  {
  g, _ := token.NewGenerator(false, false)
  tk, err := g.Get("<cluster_name>")
  if err != nil {
    log.Fatal(err)
  }
  fmt.Println(tk)
}

Die Ausgabe sollte wie folgt aussehen:

{
  "kind": "ExecCredential",
  "apiVersion": "client.authentication.k8s.io/v1alpha1",
  "spec": {},
  "status": {
    "expirationTimestamp": "2020-02-19T16:08:27Z",
    "token": "k8s-aws-v1.aHR0cHM6Ly9zdHMuYW1hem9uYXdzLmNvbS8_QWN0aW9uPUdldENhbGxlcklkZW50aXR5JlZlcnNpb249MjAxMS0wNi0xNSZYLUFtei1BbGdvcml0aG09QVdTNC1ITUFDLVNIQTI1NiZYLUFtei1DcmVkZW50aWFsPUFLSUFKTkdSSUxLTlNSQzJXNVFBJTJGMjAyMDAyMTklMkZ1cy1lYXN0LTElMkZzdHMlMkZhd3M0X3JlcXVlc3QmWC1BbXotRGF0ZT0yMDIwMDIxOVQxNTU0MjdaJlgtQW16LUV4cGlyZXM9NjAmWC1BbXotU2lnbmVkSGVhZGVycz1ob3N0JTNCeC1rOHMtYXdzLWlkJlgtQW16LVNpZ25hdHVyZT0yMjBmOGYzNTg1ZTMyMGRkYjVlNjgzYTVjOWE0MDUzMDFhZDc2NTQ2ZjI0ZjI4MTExZmRhZDA5Y2Y2NDhhMzkz"
  }
}

Jedes Token beginnt mit, k8s-aws-v1. gefolgt von einer Base64-kodierten Zeichenfolge. Die Zeichenfolge sollte, wenn sie dekodiert wird, etwas Ähnliches wie folgt aussehen:

https://sts.amazonaws.com/?Action=GetCallerIdentity&Version=2011-06-15&X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=XXXXJPFRILKNSRC2W5QA%2F20200219%2Fus-xxxx-1%2Fsts%2Faws4_request&X-Amz-Date=20200219T155427Z&X-Amz-Expires=60&X-Amz-SignedHeaders=host%3Bx-k8s-aws-id&X-Amz-Signature=XXXf8f3285e320ddb5e683a5c9a405301ad76546f24f28111fdad09cf648a393

Das Token besteht aus einer vorsignierten URL, die Amazon-Anmeldeinformationen und eine Signatur enthält. Weitere Einzelheiten finden Sie unter https://docs.aws.amazon.com/STS/latest/APIReference/API_GetCallerIdentity.html.

Das Token hat eine Lebensdauer (TTL) von 15 Minuten. Danach muss ein neues Token generiert werden. Dies erfolgt automatisch, wenn Sie beispielsweise einen Client verwenden. Wenn Sie kubectl jedoch das Kubernetes-Dashboard verwenden, müssen Sie ein neues Token generieren und sich jedes Mal erneut authentifizieren, wenn das Token abläuft.

Sobald die Identität des Benutzers durch den AWS IAM-Service authentifiziert wurde, liest der Kube-Apiserver den aws-auth ConfigMap im kube-system Namespace, um die RBAC-Gruppe zu ermitteln, die dem Benutzer zugeordnet werden soll. Der aws-auth ConfigMap wird verwendet, um eine statische Zuordnung zwischen IAM-Prinzipalen, d. h. IAM-Benutzern und -Rollen, und Kubernetes-RBAC-Gruppen zu erstellen. Auf RBAC-Gruppen kann in Kubernetes oder verwiesen werden. RoleBindings ClusterRoleBindings Sie ähneln IAM-Rollen insofern, als sie eine Reihe von Aktionen (Verben) definieren, die für eine Sammlung von Kubernetes-Ressourcen (Objekten) ausgeführt werden können.

CloudWatch Abfrage, die Benutzern hilft, Clients zu identifizieren, die Anfragen an den globalen STS-Endpunkt senden

Führen Sie die folgende CloudWatch Abfrage aus, um den STS-Endpunkt abzurufen. Wenn stsendpoint „sts.amazonaws.com“ entspricht, handelt es sich um einen globalen STS-Endpunkt. Wenn stsendpoint gleich „sts“ ist. <region>.amazonaws.com“, dann ist es ein regionaler STS-Endpunkt.

fields @timestamp, @message, @logStream, @log,stsendpoint
| filter @logStream like /authenticator/
| filter @message like /stsendpoint/
| sort @timestamp desc
| limit 10000

Cluster Access Manager

Cluster Access Manager, heute die bevorzugte Methode zur Verwaltung des Zugriffs von AWS-IAM-Prinzipalen auf Amazon EKS-Cluster, ist eine Funktion der AWS-API und eine Opt-in-Funktion für EKS-Cluster der Version 1.23 und höher (neu oder vorhanden). Es vereinfacht die Identitätszuordnung zwischen AWS IAM- und Kubernetes-RBACs, sodass Sie nicht mehr zwischen AWS- und Kubernetes-APIs wechseln oder diese aws-auth ConfigMap für die Zugriffsverwaltung bearbeiten müssen, wodurch der Betriebsaufwand reduziert und Fehlkonfigurationen behoben werden können. Das Tool ermöglicht es Cluster-Administratoren auch, cluster-admin Berechtigungen zu widerrufen oder zu verfeinern, die dem AWS-IAM-Prinzipal, der zur Erstellung des Clusters verwendet wurde, automatisch erteilt wurden.

Diese API basiert auf zwei Konzepten:

Beim Start unterstützt Amazon EKS nur vordefinierte und von AWS verwaltete Richtlinien. Zugriffsrichtlinien sind keine IAM-Entitäten und werden von Amazon EKS definiert und verwaltet.

Cluster Access Manager ermöglicht die Kombination von Upstream-RBAC mit Zugriffsrichtlinien, die das Zulassen und Weitergeben (aber nicht das Ablehnen) von Kubernetes-AuthZ-Entscheidungen in Bezug auf API-Serveranfragen unterstützen. Eine Ablehnungsentscheidung wird getroffen, wenn sowohl die Upstream-RBAC- als auch die Amazon EKS-Autorisierer das Ergebnis einer Anforderungsbewertung nicht ermitteln können.

Mit dieser Funktion unterstützt Amazon EKS drei Authentifizierungsmodi:

Zu Beginn können Cluster-Administratoren Amazon EKS-Cluster erstellen oder aktualisieren, indem sie die bevorzugte API Authentifizierungsmethode auf API_AND_CONFIG_MAP oder festlegen und Zugriffseinträge definieren, um den Zugriff auf die gewünschten AWS-IAM-Prinzipale zu gewähren.

$ aws eks create-cluster \
    --name <CLUSTER_NAME> \
    --role-arn <CLUSTER_ROLE_ARN> \
    --resources-vpc-config subnetIds=<value>,endpointPublicAccess=true,endpointPrivateAccess=true \
    --logging '{"clusterLogging":[{"types":["api","audit","authenticator","controllerManager","scheduler"],"enabled":true}]}' \
    --access-config authenticationMode=API_AND_CONFIG_MAP,bootstrapClusterCreatorAdminPermissions=false

Der obige Befehl ist ein Beispiel für die Erstellung eines Amazon EKS-Clusters, der bereits ohne die Administratorberechtigungen des Cluster-Erstellers benötigt wird.

Es ist möglich, die Amazon EKS-Cluster-Konfiguration mithilfe des update-cluster-config Befehls zu aktualisieren, um API AuthenticationMode zu aktivieren. Um dies auf vorhandenen Clustern zu tun, müssen CONFIG_MAP Sie zuerst auf API_AND_CONFIG_MAP und dann auf aktualisieren. API Diese Operationen können nicht rückgängig gemacht werden, was bedeutet, dass es nicht möglich ist, von zu API_AND_CONFIG_MAP oder CONFIG_MAP und auch von API zu zu zu zu zu wechseln. API_AND_CONFIG_MAP CONFIG_MAP

$ aws eks update-cluster-config \
    --name <CLUSTER_NAME> \
    --access-config authenticationMode=API

Die API unterstützt Befehle zum Hinzufügen und Widerrufen des Zugriffs auf den Cluster sowie zur Überprüfung der vorhandenen Zugriffsrichtlinien und Zugriffseinträge für den angegebenen Cluster. Die Standardrichtlinien werden so erstellt, dass sie den Kubernetes-RBACs entsprechen, wie folgt.

$ aws eks list-access-policies
{
    "accessPolicies": [
        {
            "name": "AmazonEKSAdminPolicy",
            "arn": "arn:aws:eks::aws:cluster-access-policy/AmazonEKSAdminPolicy"
        },
        {
            "name": "AmazonEKSClusterAdminPolicy",
            "arn": "arn:aws:eks::aws:cluster-access-policy/AmazonEKSClusterAdminPolicy"
        },
        {
            "name": "AmazonEKSEditPolicy",
            "arn": "arn:aws:eks::aws:cluster-access-policy/AmazonEKSEditPolicy"
        },
        {
            "name": "AmazonEKSViewPolicy",
            "arn": "arn:aws:eks::aws:cluster-access-policy/AmazonEKSViewPolicy"
        }
    ]
}

$ aws eks list-access-entries --cluster-name <CLUSTER_NAME>

{
    "accessEntries": []
}

Keine Zugriffseinträge sind verfügbar, wenn der Cluster ohne die Administratorberechtigung des Clustererstellers erstellt wird. Dies ist der einzige Eintrag, der standardmäßig erstellt wird.

Die aws-auth ConfigMap (veraltet)

Eine Möglichkeit, die Kubernetes-Integration mit der AWS-Authentifizierung durchzuführen, ist über den aws-auth ConfigMap, der sich im Namespace befindet. kube-system Es ist verantwortlich für die Zuordnung der AWS-IAM-Identitäten (Benutzer, Gruppen und Rollen) zur rollenbasierten Zugriffskontrolle (RBAC) von Kubernetes. Das aws-auth ConfigMap wird während der Bereitstellungsphase automatisch in Ihrem Amazon EKS-Cluster erstellt. Es wurde ursprünglich erstellt, um Knoten den Beitritt zu Ihrem Cluster zu ermöglichen. Wie bereits erwähnt, können Sie es jedoch auch verwenden, ConfigMap um IAM-Prinzipalen den RBAC-Zugriff hinzuzufügen.

Um die Ihres Clusters zu überprüfen aws-auth ConfigMap, können Sie den folgenden Befehl verwenden.

kubectl -n kube-system get configmap aws-auth -o yaml

Dies ist ein Beispiel für eine Standardkonfiguration von aws-authConfigMap.

apiVersion: v1
data:
  mapRoles: |
    - groups:
      - system:bootstrappers
      - system:nodes
      - system:node-proxier
      rolearn: arn:aws:iam::<AWS_ACCOUNT_ID>:role/kube-system-<SELF_GENERATED_UUID>
      username: system:node:{{SessionName}}
kind: ConfigMap
metadata:
  creationTimestamp: "2023-10-22T18:19:30Z"
  name: aws-auth
  namespace: kube-system

Die Hauptsitzung befindet sich unter dem data mapRoles Block, der im Wesentlichen aus 3 Parametern besteht. ConfigMap

Es ist auch möglich, Berechtigungen für AWS-IAM-Benutzer zuzuordnen, indem ein neuer Konfigurationsblock fürmapUsers, unter data in dem, definiert wird aws-authConfigMap, wodurch der rolearn-Parameter für userarn ersetzt wird. Als Best Practice wird jedoch immer empfohlen, stattdessen den Benutzer zu verwenden. mapRoles

Um Berechtigungen zu verwalten, können Sie das aws-auth ConfigMap Hinzufügen oder Entfernen des Zugriffs auf Ihren Amazon EKS-Cluster bearbeiten. Es ist zwar möglich, diese aws-auth ConfigMap manuell zu bearbeiten, es wird jedoch empfohlen, Tools wie zu verwendeneksctl, da dies eine sehr vertrauliche Konfiguration ist und eine ungenaue Konfiguration Sie außerhalb Ihres Amazon EKS-Clusters sperren kann. Weitere Informationen finden Sie weiter unten im Unterabschnitt Verwenden Sie Tools, um Änderungen an der ConfigMap aws-auth vorzunehmen.

Vorteile gegenüber der Zugriffsverwaltung ConfigMap-based

Empfehlungen für den Cluster-Zugriff

Kombinieren Sie IAM Identity Center mit der CAM-API

Machen Sie den EKS-Cluster-Endpunkt privat

Wenn Sie einen EKS-Cluster bereitstellen, ist der API-Cluster-Endpunkt standardmäßig auf öffentlich gesetzt, d. h. er kann über das Internet abgerufen werden. Obwohl der Endpunkt über das Internet zugänglich ist, gilt er dennoch als sicher, da alle API-Anfragen von IAM authentifiziert und anschließend von Kubernetes RBAC autorisiert werden müssen. Wenn Ihre Unternehmenssicherheitsrichtlinie jedoch vorschreibt, dass Sie den Zugriff auf die API aus dem Internet einschränken oder Sie daran hindern, Datenverkehr außerhalb der Cluster-VPC weiterzuleiten, können Sie:

Verwenden Sie kein Dienstkonto-Token für die Authentifizierung

Ein Dienstkonto-Token ist ein langlebiger, statischer Berechtigungsnachweis. Wenn es kompromittiert wird, verloren geht oder gestohlen wird, kann ein Angreifer möglicherweise alle mit diesem Token verbundenen Aktionen ausführen, bis das Dienstkonto gelöscht wird. Manchmal müssen Sie möglicherweise eine Ausnahme für Anwendungen gewähren, die die Kubernetes-API von außerhalb des Clusters nutzen müssen, z. B. eine CI/CD Pipeline-Anwendung. Wenn solche Anwendungen wie EC2-Instances auf einer AWS-Infrastruktur ausgeführt werden, sollten Sie erwägen, ein Instanzprofil zu verwenden und dieses einer Kubernetes-RBAC-Rolle zuzuordnen.

Nutzen Sie den Zugriff mit den geringsten Privilegien auf AWS-Ressourcen

Einem IAM-Benutzer müssen keine Rechte für AWS-Ressourcen zugewiesen werden, um auf die Kubernetes-API zugreifen zu können. Wenn Sie einem IAM-Benutzer Zugriff auf einen EKS-Cluster gewähren müssen, erstellen Sie im aws-auth ConfigMap für diesen Benutzer einen Eintrag, der einer bestimmten Kubernetes-RBAC-Gruppe zugeordnet ist.

Entfernen Sie die Cluster-Admin-Berechtigungen aus dem Cluster Creator Principal

Standardmäßig werden Amazon EKS-Cluster mit einer dauerhaften cluster-admin Berechtigung erstellt, die an den Principal des Cluster-Erstellers gebunden ist. Mit der Cluster Access Manager-API ist es möglich, Cluster zu erstellen, ohne dass diese Berechtigung aktiviert istfalse, wenn der --access-config bootstrapClusterCreatorAdminPermissions API Authentifizierungsmodus verwendet API_AND_CONFIG_MAP wird. Das Widerrufen dieses Zugriffs wird als bewährte Methode angesehen, um unerwünschte Änderungen an der Clusterkonfiguration zu vermeiden. Das Verfahren zum Widerrufen dieses Zugriffs folgt dem gleichen Verfahren zum Widerrufen aller anderen Zugriffe auf den Cluster.

Die API bietet Ihnen die Flexibilität, nur einen IAM-Principal von einer Zugriffsrichtlinie zu trennen, in diesem Fall von. AmazonEKSClusterAdminPolicy

$ aws eks list-associated-access-policies \
    --cluster-name <CLUSTER_NAME> \
    --principal-arn <IAM_PRINCIPAL_ARN>

$ aws eks disassociate-access-policy --cluster-name <CLUSTER_NAME> \
    --principal-arn <IAM_PRINCIPAL_ARN. \
    --policy-arn arn:aws:eks::aws:cluster-access-policy/AmazonEKSClusterAdminPolicy

Oder den mit der Berechtigung verknüpften Zugriffseintrag vollständig entfernen. cluster-admin

$ aws eks list-access-entries --cluster-name <CLUSTER_NAME>

{
    "accessEntries": []
}

$ aws eks delete-access-entry --cluster-name <CLUSTER_NAME> \
  --principal-arn <IAM_PRINCIPAL_ARN>

Dieser Zugriff kann bei Bedarf bei einem Vorfall, einem Notfall oder einem Glasbruch, in dem der Cluster sonst nicht zugänglich ist, erneut gewährt werden.

Wenn der Cluster immer noch mit der CONFIG_MAP Authentifizierungsmethode konfiguriert ist, sollte allen zusätzlichen Benutzern der Zugriff auf den Cluster über die Rolle gewährt werden aws-auth ConfigMap, die der Entität zugewiesen aws-auth ConfigMap ist, die den Cluster erstellt hat. Sie kann gelöscht und nur dann neu erstellt werden, wenn ein Vorfall, ein Notfall oder ein Glasbruch eintritt oder wenn der Cluster beschädigt aws-auth ConfigMap ist und der Cluster aus anderen Gründen nicht zugänglich ist. Dies kann besonders in Produktionsclustern nützlich sein.

Verwenden Sie IAM-Rollen, wenn mehrere Benutzer identischen Zugriff auf den Cluster benötigen

Anstatt einen Eintrag für jeden einzelnen IAM-Benutzer zu erstellen, ermöglichen Sie diesen Benutzern, eine IAM-Rolle anzunehmen und diese Rolle einer Kubernetes-RBAC-Gruppe zuzuordnen. Dies wird einfacher zu verwalten sein, insbesondere wenn die Anzahl der Benutzer, die Zugriff benötigen, zunimmt.

Wenn Sie immer noch die aws-auth ConfigMap als Authentifizierungsmethode verwenden, sollten Sie bei der Zuweisung von K8s RBAC-Berechtigungen zu einer IAM-Rolle\ {{}} in Ihren Benutzernamen aufnehmen. SessionName Auf diese Weise zeichnet das Audit-Log den Sitzungsnamen auf, sodass Sie zusammen mit dem Protokoll verfolgen können, wer der tatsächliche Benutzer diese Rolle annimmt. CloudTrail

- rolearn: arn:aws:iam::XXXXXXXXXXXX:role/testRole
  username: testRole:{{SessionName}}
  groups:
    - system:masters

Verwenden Sie beim Erstellen von und Zugriff mit den geringsten Rechten RoleBindings ClusterRoleBindings

Entspricht dem vorherigen Punkt zur Gewährung des Zugriffs auf AWS-Ressourcen RoleBindings und ClusterRoleBindings sollte nur den Satz von Berechtigungen enthalten, der für die Ausführung einer bestimmten Funktion erforderlich ist. Vermeiden Sie die Verwendung ["*"] in Ihren Rollen und ClusterRoles sofern dies nicht unbedingt erforderlich ist. Wenn Sie sich nicht sicher sind, welche Berechtigungen Sie zuweisen sollen, sollten Sie erwägen, ein Tool wie audit2rbac zu verwenden, um automatisch Rollen und Bindungen auf der Grundlage der beobachteten API-Aufrufe im Kubernetes-Audit-Log zu generieren.

Erstellen Sie einen Cluster mithilfe eines automatisierten Prozesses

Wie in den vorherigen Schritten beschrieben, werden dem Benutzer API_AND_CONFIG_MAP oder der Rolle der IAM-Entität, z. B. einem Verbundbenutzer, der den Cluster erstellt, automatisch cluster-admin Berechtigungen in der RBAC-Konfiguration des Clusters erteilt, wenn Sie beim Erstellen eines Amazon EKS-Clusters nicht den Benutzungs- oder API Authentifizierungsmodus verwenden und sich nicht abmelden, um system:masters Berechtigungen an den Cluster-Ersteller zu delegieren. Auch wenn es eine bewährte Methode ist, diese Erlaubnis zu entfernen, wie hier beschrieben, wenn Sie die CONFIG_MAP Authentifizierungsmethode verwenden, auf die Sie sich verlassen aws-auth ConfigMap, kann dieser Zugriff nicht widerrufen werden. Daher ist es eine gute Idee, den Cluster mit einer Infrastrukturautomatisierungspipeline zu erstellen, die an eine dedizierte IAM-Rolle gebunden ist, ohne dass andere Benutzer oder Entitäten Berechtigungen übernehmen müssen, und regelmäßig die Berechtigungen und Richtlinien dieser Rolle zu überprüfen und zu überprüfen, wer Zugriff hat, um die Pipeline auszulösen. Außerdem sollte diese Rolle nicht zur Ausführung von Routineaktionen auf dem Cluster verwendet werden. Sie sollte ausschließlich für Aktionen auf Cluster-Ebene verwendet werden, die von der Pipeline ausgelöst werden, beispielsweise durch SCM-Codeänderungen.

Erstellen Sie den Cluster mit einer dedizierten IAM-Rolle

Wenn Sie einen Amazon EKS-Cluster erstellen, werden dem Benutzer oder der Rolle der IAM-Entität, z. B. einem Verbundbenutzer, der den Cluster erstellt, automatisch system:masters Berechtigungen in der RBAC-Konfiguration des Clusters erteilt. Dieser Zugriff kann nicht entfernt werden und wird nicht über den verwaltet. aws-auth ConfigMap Daher empfiehlt es sich, den Cluster mit einer dedizierten IAM-Rolle zu erstellen und regelmäßig zu überprüfen, wer diese Rolle übernehmen kann. Diese Rolle sollte nicht verwendet werden, um Routineaktionen auf dem Cluster durchzuführen. Stattdessen sollte zusätzlichen Benutzern zu diesem aws-auth ConfigMap Zweck der Zugriff auf den Cluster gewährt werden. Nach der aws-auth ConfigMap Konfiguration sollte die Rolle gesichert und nur im temporären Modus mit erhöhten Rechten verwendet werden. Break Glass sollte in Szenarien verwendet werden, in denen der Cluster sonst nicht zugänglich ist. Dies kann besonders in Clustern nützlich sein, für die kein direkter Benutzerzugriff konfiguriert ist.

Überwachen Sie regelmäßig den Zugriff auf den Cluster

Wer Zugriff benötigt, wird sich wahrscheinlich im Laufe der Zeit ändern. Planen Sie ein, diese regelmäßig aws-auth ConfigMap zu überprüfen, um festzustellen, wem Zugriff gewährt wurde und welche Rechte ihnen zugewiesen wurden. Sie können auch Open-Source-Tools wie kubectl-who-can oder rbac-lookup verwenden, um die Rollen zu untersuchen, die an ein bestimmtes Dienstkonto, einen bestimmten Benutzer oder eine bestimmte Gruppe gebunden sind. Wir werden uns eingehender mit diesem Thema befassen, wenn wir zum Abschnitt über Auditing kommen. Prüfung und Protokollierung Weitere Ideen finden Sie in diesem Artikel der NCC Group.

Wenn Sie sich auf aws-auth ConfigMap verlassen, verwenden Sie Tools, um Änderungen vorzunehmen

Ein falsch formatiertes aws-auth ConfigMap kann dazu führen, dass Sie den Zugriff auf den Cluster verlieren. Wenn Sie Änderungen an der vornehmen müssen, verwenden Sie ein Tool. ConfigMap

eksctl Die eksctl CLI enthält einen Befehl zum Hinzufügen von Identitätszuordnungen zur aws-auth. ConfigMap

CLI-Hilfe anzeigen:

$ eksctl create iamidentitymapping --help
...

Überprüfen Sie die Identitäten, die Ihrem Amazon EKS-Cluster zugeordnet sind.

$ eksctl get iamidentitymapping --cluster $CLUSTER_NAME --region $AWS_REGION
ARN                                                                   USERNAME                        GROUPS                                                  ACCOUNT
arn:aws:iam::788355785855:role/kube-system-<SELF_GENERATED_UUID>      system:node:{{SessionName}}     system:bootstrappers,system:nodes,system:node-proxier

Machen Sie aus einer IAM-Rolle einen Cluster-Administrator:

$ eksctl create iamidentitymapping --cluster  <CLUSTER_NAME> --region=<region> --arn arn:aws:iam::123456:role/testing --group system:masters --username admin
...

Weitere Informationen finden Sie in der Dokumentation eksctl

https://github.com/keikoproj/aws-authaws-auth von keikoproj

aws-authvon keikoproj beinhaltet sowohl eine CLI- als auch eine Go-Bibliothek.

Laden Sie die CLI-Hilfe herunter und zeigen Sie sie an:

$ go get github.com/keikoproj/aws-auth
...
$ aws-auth help
...

Installieren Sie es alternativ aws-auth mit dem Krew-Plugin-Manager für Kubectl.

$ kubectl krew install aws-auth
...
$ kubectl aws-auth
...

Weitere Informationen finden Sie in den aws-auth-Dokumenten, einschließlich der GitHub Go-Bibliothek.

AWS IAM Authenticator CLI

Das aws-iam-authenticator Projekt beinhaltet eine CLI zur Aktualisierung der. ConfigMap

Laden Sie eine Version herunter am GitHub.

Fügen Sie Cluster-Berechtigungen zu einer IAM-Rolle hinzu:

$ ./aws-iam-authenticator add role --rolearn arn:aws:iam::185309785115:role/lil-dev-role-cluster --username lil-dev-user --groups system:masters --kubeconfig ~/.kube/config
...

Alternative Ansätze zur Authentifizierung und Zugriffsverwaltung

IAM ist zwar die bevorzugte Methode zur Authentifizierung von Benutzern, die Zugriff auf einen EKS-Cluster benötigen, es ist jedoch möglich, einen OIDC-Identitätsanbieter zu verwenden, z. B. GitHub mithilfe eines Authentifizierungs-Proxys und Kubernetes-Identitätswechsels. https://kubernetes.io/docs/reference/access-authn-authz/authentication/#user-impersonation Beiträge für zwei solche Lösungen wurden im AWS Open Source-Blog veröffentlicht:

Sie können AWS SSO auch verwenden, um AWS mit einem externen Identitätsanbieter, z. B. Azure AD, zu verbinden. Wenn Sie sich dafür entscheiden, bietet die AWS CLI v2.0 eine Option zum Erstellen eines benannten Profils, das es einfach macht, Ihrer aktuellen CLI-Sitzung eine SSO-Sitzung zuzuordnen und eine IAM-Rolle zu übernehmen. Beachten Sie, dass Sie vor der Ausführung eine Rolle übernehmen müssen, kubectl da die IAM-Rolle verwendet wird, um die Kubernetes-RBAC-Gruppe des Benutzers zu bestimmen.

Identitäten und Anmeldeinformationen für EKS-Pods

Bestimmte Anwendungen, die in einem Kubernetes-Cluster ausgeführt werden, benötigen die Erlaubnis, die Kubernetes-API aufzurufen, damit sie ordnungsgemäß funktionieren. Beispielsweise muss der AWS Load Balancer Controller in der Lage sein, die Endpunkte eines Dienstes aufzulisten. Der Controller muss außerdem in der Lage sein, AWS-APIs zur Bereitstellung und Konfiguration eines ALB aufzurufen. In diesem Abschnitt werden wir uns mit den bewährten Methoden für die Zuweisung von Rechten und Privilegien an Pods befassen.

Kubernetes-Dienstkonten

Ein Dienstkonto ist ein spezieller Objekttyp, mit dem Sie einem Pod eine Kubernetes-RBAC-Rolle zuweisen können. Ein Standarddienstkonto wird automatisch für jeden Namespace innerhalb eines Clusters erstellt. Wenn Sie einen Pod in einem Namespace bereitstellen, ohne auf ein bestimmtes Dienstkonto zu verweisen, wird das Standarddienstkonto für diesen Namespace automatisch dem Pod zugewiesen, und das Secret, d. h. das Dienstkonto-Token (JWT) für dieses Dienstkonto, wird als Volume unter dem Pod bereitgestellt. /var/run/secrets/kubernetes.io/serviceaccount Beim Dekodieren des Dienstkonto-Tokens in diesem Verzeichnis werden die folgenden Metadaten angezeigt:

{
  "iss": "kubernetes/serviceaccount",
  "kubernetes.io/serviceaccount/namespace": "default",
  "kubernetes.io/serviceaccount/secret.name": "default-token-5pv4z",
  "kubernetes.io/serviceaccount/service-account.name": "default",
  "kubernetes.io/serviceaccount/service-account.uid": "3b36ddb5-438c-11ea-9438-063a49b60fba",
  "sub": "system:serviceaccount:default:default"
}

Das Standarddienstkonto hat die folgenden Berechtigungen für die Kubernetes-API.

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  annotations:
    rbac.authorization.kubernetes.io/autoupdate: "true"
  creationTimestamp: "2020-01-30T18:13:25Z"
  labels:
    kubernetes.io/bootstrapping: rbac-defaults
  name: system:discovery
  resourceVersion: "43"
  selfLink: /apis/rbac.authorization.k8s.io/v1/clusterroles/system%3Adiscovery
  uid: 350d2ab8-438c-11ea-9438-063a49b60fba
rules:
- nonResourceURLs:
  - /api
  - /api/*
  - /apis
  - /apis/*
  - /healthz
  - /openapi
  - /openapi/*
  - /version
  - /version/
  verbs:
  - get

Diese Rolle autorisiert nicht authentifizierte und authentifizierte Benutzer zum Lesen von API-Informationen und gilt als sicher, wenn sie öffentlich zugänglich ist.

Wenn eine in einem Pod ausgeführte Anwendung die Kubernetes-APIs aufruft, muss dem Pod ein Dienstkonto zugewiesen werden, das ihm ausdrücklich die Erlaubnis erteilt, diese APIs aufzurufen. Ähnlich wie bei den Richtlinien für den Benutzerzugriff sollte die Rolle oder die ClusterRole Bindung an ein Dienstkonto auf die API-Ressourcen und -Methoden beschränkt werden, die die Anwendung zum Funktionieren benötigt, und auf nichts anderes. Um ein nicht standardmäßiges Dienstkonto zu verwenden, setzen Sie einfach das spec.serviceAccountName Feld eines Pods auf den Namen des Dienstkontos, das Sie verwenden möchten. Weitere Informationen zum Erstellen von Dienstkonten finden Sie unter https://kubernetes.io/docs/reference/access-authn-authz/rbac/ #service -account-permissions.

IAM-Rollen für Dienstkonten (IRSA)

IRSA ist eine Funktion, mit der Sie einem Kubernetes-Dienstkonto eine IAM-Rolle zuweisen können. Dabei wird eine Kubernetes-Funktion genutzt, die als Service Account Token Volume Projection bekannt ist. https://kubernetes.io/docs/tasks/configure-pod-container/configure-service-account/#serviceaccount-token-volume-projection Wenn Pods mit einem Dienstkonto konfiguriert werden, das auf eine IAM-Rolle verweist, ruft der Kubernetes-API-Server beim Start den öffentlichen OIDC-Discovery-Endpunkt für den Cluster auf. Der Endpunkt signiert das von Kubernetes ausgegebene OIDC-Token kryptografisch und das daraus resultierende Token wird als Volume gemountet. Dieses signierte Token ermöglicht es dem Pod, die der AWS-API zugeordnete IAM-Rolle aufzurufen. Wenn eine AWS-API aufgerufen wird, werden die AWS-SDKs aufgerufen. sts:AssumeRoleWithWebIdentity Nach der Validierung der Signatur des Tokens tauscht IAM das von Kubernetes ausgestellte Token gegen temporäre AWS-Rollenanmeldeinformationen aus.

Bei der Verwendung von IRSA ist es wichtig, AWS-SDK-Sitzungen wiederzuverwenden, um unnötige Aufrufe von AWS STS zu vermeiden.

Bei der Dekodierung des (JWT) -Tokens für IRSA wird eine Ausgabe erzeugt, die dem Beispiel ähnelt, das Sie unten sehen:

{
  "aud": [
    "sts.amazonaws.com"
  ],
  "exp": 1582306514,
  "iat": 1582220114,
  "iss": "https://oidc.eks.us-west-2.amazonaws.com/id/D43CF17C27A865933144EA99A26FB128",
  "kubernetes.io": {
    "namespace": "default",
    "pod": {
      "name": "alpine-57b5664646-rf966",
      "uid": "5a20f883-5407-11ea-a85c-0e62b7a4a436"
    },
    "serviceaccount": {
      "name": "s3-read-only",
      "uid": "a720ba5c-5406-11ea-9438-063a49b60fba"
    }
  },
  "nbf": 1582220114,
  "sub": "system:serviceaccount:default:s3-read-only"
}

Dieses spezielle Token gewährt S3 die Pod-Leseberechtigungen, indem es eine IAM-Rolle übernimmt. Wenn die Anwendung versucht, aus S3 zu lesen, wird das Token gegen einen temporären Satz von IAM-Anmeldeinformationen ausgetauscht, der dem Folgenden ähnelt:

{
    "AssumedRoleUser": {
        "AssumedRoleId": "AROA36C6WWEJULFUYMPB6:abc",
        "Arn": "arn:aws:sts::123456789012:assumed-role/eksctl-winterfell-addon-iamserviceaccount-de-Role1-1D61LT75JH3MB/abc"
    },
    "Audience": "sts.amazonaws.com",
    "Provider": "arn:aws:iam::123456789012:oidc-provider/oidc.eks.us-west-2.amazonaws.com/id/D43CF17C27A865933144EA99A26FB128",
    "SubjectFromWebIdentityToken": "system:serviceaccount:default:s3-read-only",
    "Credentials": {
        "SecretAccessKey": "wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY",
        "SessionToken": "FwoGZXIvYXdzEGMaDMLxAZkuLpmSwYXShiL9A1S0X87VBC1mHCrRe/pB2oesl1eXxUYnPJyC9ayOoXMvqXQsomq0xs6OqZ3vaa5Iw1HIyA4Cv1suLaOCoU3hNvOIJ6C94H1vU0siQYk7DIq9Av5RZeuE2FnOctNBvYLd3i0IZo1ajjc00yRK3v24VRq9nQpoPLuqyH2jzlhCEjXuPScPbi5KEVs9fNcOTtgzbVf7IG2gNiwNs5aCpN4Bv/Zv2A6zp5xGz9cWj2f0aD9v66vX4bexOs5t/YYhwuwAvkkJPSIGvxja0xRThnceHyFHKtj0Hbi/PWAtlI8YJcDX69cM30JAHDdQHltm/4scFptW1hlvMaPWReCAaCrsHrATyka7ttw5YlUyvZ8EPogj6fwHlxmrXM9h1BqdikomyJU00gm1FJelfP1zAwcyrxCnbRl3ARFrAt8hIlrT6Vyu8WvWtLxcI8KcLcJQb/LgkWsCTGlYcY8z3zkigJMbYn07ewTL5Ss7LazTJJa758I7PZan/v3xQHd5DEc5WBneiV3iOznDFgup0VAMkIviVjVCkszaPSVEdK2NU7jtrh6Jfm7bU/3P6ZGCkyDLIa8MBn9KPXeJd/yjTk5IifIwO/mDpGNUribg6TPxhzZ8b/XdZO1kS1gVgqjXyVCM+BRBh6C4H21w/eMzjCtDIpoxt5rGKL6Nu/IFMipoC4fgx6LIIHwtGYMG7SWQi7OsMAkiwZRg0n68/RqWgLzBt/4pfjSRYuk=",
        "Expiration": "2020-02-20T18:49:50Z",
        "AccessKeyId": "ASIAIOSFODNN7EXAMPLE"
    }
}

Ein mutierender Webhook, der als Teil der EKS-Steuerungsebene ausgeführt wird, fügt den AWS-Rollen-ARN und den Pfad zu einer Webidentitäts-Tokendatei als Umgebungsvariablen in den Pod ein. Diese Werte können auch manuell eingegeben werden.

AWS_ROLE_ARN=arn:aws:iam::AWS_ACCOUNT_ID:role/IAM_ROLE_NAME
AWS_WEB_IDENTITY_TOKEN_FILE=/var/run/secrets/eks.amazonaws.com/serviceaccount/token

Das Kubelet rotiert das projizierte Token automatisch, wenn es älter als 80% seiner gesamten TTL ist, oder nach 24 Stunden. Die AWS-SDKs sind dafür verantwortlich, das Token neu zu laden, wenn es rotiert. Weitere Informationen zu IRSA finden Sie unter https://docs.aws.amazon.com/eks/latest/userguide/iam-roles-for-service-accounts-technical-overview.html.

EKS-Pod-Identitäten

EKS Pod Identities ist eine auf der re:Invent 2023 eingeführte Funktion, mit der Sie einem Kubernetes-Dienstkonto eine IAM-Rolle zuweisen können, ohne für jeden Cluster in Ihrem AWS-Konto einen Open Id Connect (OIDC) Identity Provider (IDP) konfigurieren zu müssen. Um EKS Pod Identity verwenden zu können, müssen Sie einen Agenten bereitstellen, der als Pod auf jedem berechtigten Worker-Knoten ausgeführt wird. DaemonSet Dieser Agent wird Ihnen als EKS zur Verfügung gestellt Add-on und ist eine Voraussetzung für die Nutzung der EKS Pod Identity-Funktion. Ihre Anwendungen müssen eine unterstützte Version des AWS-SDK verwenden, um diese Funktion nutzen zu können.

Wenn EKS-Pod-Identitäten für einen Pod konfiguriert sind, mountet und aktualisiert EKS ein Pod-Identitätstoken unter/var/run/secrets/pods.eks.amazonaws.com/serviceaccount/eks-pod-identity-token. Dieses Token wird vom AWS-SDK für die Kommunikation mit dem EKS Pod Identity Agent verwendet, der das Pod-Identitätstoken und die IAM-Rolle des Agenten verwendet, um temporäre Anmeldeinformationen für Ihre Pods zu erstellen, indem er die AssumeRoleForPodIdentity API aufruft. Das an Ihre Pods übermittelte Pod-Identitätstoken ist ein JWT, das von Ihrem EKS-Cluster ausgestellt und kryptografisch signiert ist. Es enthält die entsprechenden JWT-Ansprüche für die Verwendung mit EKS-Pod-Identitäten.

Weitere Informationen zu EKS Pod Identities finden Sie in diesem Blog. https://aws.amazon.com/blogs/containers/amazon-eks-pod-identity-a-new-way-for-applications-on-eks-to-obtain-iam-credentials/

Sie müssen keine Änderungen an Ihrem Anwendungscode vornehmen, um EKS Pod Identities verwenden zu können. Unterstützte AWS-SDK-Versionen erkennen automatisch Anmeldeinformationen, die mit EKS Pod Identities zur Verfügung gestellt wurden, mithilfe der Anmeldeinformationsanbieterkette. Wie IRSA legt auch EKS-Pod-Identitäten Variablen in Ihren Pods fest, um ihnen zu zeigen, wie sie AWS-Anmeldeinformationen finden können.

Arbeiten mit IAM-Rollen für EKS-Pod-Identitäten

{
  "Version":"2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "pods.eks.amazonaws.com"
      },
      "Action": [
        "sts:AssumeRole",
        "sts:TagSession"
      ],
      "Condition": {
        "StringEquals": {
          "aws:SourceOrgId": "${aws:ResourceOrgId}"
        }
      }
    }
  ]
}

AWS empfiehlt die Verwendung von Bedingungsschlüsseln wie aws:SourceOrgId zum Beispiel zum Schutz vor dem dienstübergreifenden Problem der verwirrten Stellvertreter. Im obigen Beispiel für eine Vertrauensrichtlinie für Rollen ResourceOrgId ist die eine Variable, die der AWS-Organisations-ID der AWS-Organisation entspricht, zu der das AWS-Konto gehört. EKS übergibt einen Wert, der diesem Wert aws:SourceOrgId entspricht, wenn es eine Rolle bei EKS Pod Identities übernimmt.

ABAC- und EKS-Pod-Identitäten

Wenn EKS Pod Identities eine IAM-Rolle übernimmt, werden die folgenden Sitzungs-Tags festgelegt:

Mit diesen Sitzungs-Tags können Sie mithilfe der attributebasierten Zugriffskontrolle (ABAC) nur bestimmten Kubernetes-Servicekonten Zugriff auf Ihre AWS-Ressourcen gewähren. Dabei ist es sehr wichtig zu verstehen, dass Kubernetes-Servicekonten nur innerhalb eines Namespaces eindeutig sind und Kubernetes-Namespaces nur innerhalb eines EKS-Clusters eindeutig sind. Auf diese Sitzungs-Tags kann in den AWS-Richtlinien mithilfe des globalen Bedingungsschlüssels zugegriffen werden, z. B. aws:PrincipalTag/<tag-key> aws:PrincipalTag/eks-cluster-arn

Wenn Sie beispielsweise nur einem bestimmten Servicekonto Zugriff gewähren möchten, um auf eine AWS-Ressource in Ihrem Konto mit einer IAM- oder Ressourcenrichtlinie zuzugreifen, müssten Sie sowohl die kubernetes-namespace Tags als auch die überprüfeneks-cluster-arn, kubernetes-service-account um sicherzustellen, dass nur die Dienstkonten aus dem vorgesehenen Cluster Zugriff auf diese Ressource haben, da andere Cluster identische kubernetes-service-accounts und kubernetes-namespaces haben könnten.

Dieses Beispiel einer S3-Bucket-Richtlinie gewährt nur Zugriff auf Objekte in dem S3-Bucket, an den sie angehängt ist kubernetes-service-accountkubernetes-namespace, nur wenn eks-cluster-arn alle ihre erwarteten Werte erfüllen, wobei der EKS-Cluster im AWS-Konto gehostet wird111122223333.

{
    "Version":"2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "AWS": "arn:aws:iam::111122223333:root"
            },
            "Action": "s3:*",
            "Resource":            [
                "arn:aws:s3:::ExampleBucket/*"
            ],
            "Condition": {
                "StringEquals": {
                    "aws:PrincipalTag/kubernetes-service-account": "s3objectservice",
                    "aws:PrincipalTag/eks-cluster-arn": "arn:aws:eks:us-west-2:111122223333:cluster/ProductionCluster",
                    "aws:PrincipalTag/kubernetes-namespace": "s3datanamespace"
                }
            }
        }
    ]
}

EKS-Pod-Identitäten im Vergleich zu IRSA

Sowohl EKS-Pod-Identitäten als auch IRSA sind bevorzugte Methoden, um temporäre AWS-Anmeldeinformationen für Ihre EKS-Pods bereitzustellen. Sofern Sie keine speziellen Anwendungsfälle für IRSA haben, empfehlen wir Ihnen, EKS-Pod-Identitäten zu verwenden, wenn Sie EKS verwenden. Diese Tabelle hilft beim Vergleich der beiden Funktionen.

Identitäten und Anmeldeinformationen für EKS-Pods: Empfehlungen

Aktualisieren Sie das AWS-Node-Daemonset, um IRSA zu verwenden

Derzeit ist das AWS-Node-Daemonset so konfiguriert, dass es eine den EC2-Instances zugewiesene Rolle verwendet, um Pods IP-Adressen zuzuweisen. Diese Rolle umfasst mehrere von AWS verwaltete Richtlinien, z. B. amazoneks_CNI_Policy, die es praktisch allen auf einem Knoten laufenden Pods ermöglichenEC2ContainerRegistryReadOnly , ENIs, IP-Adressen oder das Abrufen von Bildern aus ECR zu attach/detach ermöglichen. assign/unassign Da dies ein Risiko für Ihren Cluster darstellt, wird empfohlen, das AWS-Node-Daemonset so zu aktualisieren, dass IRSA verwendet wird. Ein Skript dafür finden Sie im Repository für dieses Handbuch. https://github.com/aws/aws-eks-best-practices/tree/master/projects/enable-irsa/src

Das aws-node-Daemonset unterstützt EKS-Pod-Identitäten in den Versionen v1.15.5 und höher.

Beschränken Sie den Zugriff auf das Instanzprofil, das dem Worker-Knoten zugewiesen ist

Wenn Sie IRSA- oder EKS-Pod-Identitäten verwenden, wird die Anmeldeinformationskette des Pods aktualisiert, sodass zuerst IRSA- oder EKS-Pod-Identitäten verwendet werden. Der Pod kann jedoch weiterhin die Rechte des Instanzprofils erben, das dem Worker-Knoten zugewiesen ist. Für Pods, die diese Berechtigungen nicht benötigen, können Sie den Zugriff auf die Instance-Metadaten blockieren, um sicherzustellen, dass Ihre Anwendungen nur über die erforderlichen Berechtigungen verfügen und nicht ihre Knoten.

Sie können den Zugriff auf Instance-Metadaten blockieren, indem Sie verlangen, dass die Instance nur IMDSv2 verwendet und die Hop-Anzahl wie im folgenden Beispiel auf 1 aktualisiert wird. Sie können diese Einstellungen auch in die Startvorlage der Knotengruppe aufnehmen. Deaktivieren Sie Instanzmetadaten nicht, da dies verhindert, dass Komponenten wie der Node Termination Handler und andere Dinge, die auf Instanzmetadaten angewiesen sind, ordnungsgemäß funktionieren.

$ aws ec2 modify-instance-metadata-options --instance-id <value> --http-tokens required --http-put-response-hop-limit 1
...

Wenn Sie Terraform verwenden, um Startvorlagen für die Verwendung mit verwalteten Knotengruppen zu erstellen, fügen Sie den Metadatenblock hinzu, um die Anzahl der Hops zu konfigurieren, wie in diesem Codeausschnitt dargestellt:

tf hl_lines="7" resource "aws_launch_template" "foo" { name = "foo" …​ metadata_options { http_endpoint = "enabled" http_tokens = "required" http_put_response_hop_limit = 1 instance_metadata_tags = "enabled" } …​

Sie können auch den Zugriff eines Pods auf EC2-Metadaten blockieren, indem Sie iptables auf dem Knoten manipulieren. Weitere Informationen zu dieser Methode finden Sie unter Beschränken des Zugriffs auf den Instance-Metadatendienst.

Wenn Sie eine Anwendung haben, die eine ältere Version des AWS-SDK verwendet, die IRSA- oder EKS-Pod-Identitäten nicht unterstützt, sollten Sie die SDK-Version aktualisieren.

Passen Sie die Vertrauensrichtlinie für IAM-Rollen für IRSA-Rollen auf den Namen, den Namespace und den Cluster des Dienstkontos an

Die Vertrauensrichtlinie kann auf einen Namespace oder ein bestimmtes Dienstkonto innerhalb eines Namespace beschränkt werden. Wenn Sie IRSA verwenden, empfiehlt es sich, die Vertrauensrichtlinie für die Rolle so explizit wie möglich zu formulieren, indem Sie den Namen des Dienstkontos angeben. Dadurch wird effektiv verhindert, dass andere Pods innerhalb desselben Namespaces die Rolle übernehmen. Die CLI eksctl erledigt dies automatisch, wenn Sie sie zum Erstellen von accounts/IAM Servicerollen verwenden. https://eksctl.io/usage/iamserviceaccounts/Weitere Informationen finden Sie unter.

Wenn Sie direkt mit IAM arbeiten, fügt dies der Vertrauensrichtlinie der Rolle eine Bedingung hinzu, die mithilfe von Bedingungen sicherstellt, dass es sich bei dem :sub Anspruch um den Namespace und das Dienstkonto handelt, das Sie erwarten. Als Beispiel hatten wir zuvor ein IRSA-Token mit dem Unteranspruch „system:serviceaccount:default:s3-read-only“. Das default ist der s3-read-only Namespace und das Dienstkonto ist. Sie würden eine Bedingung wie die folgende verwenden, um sicherzustellen, dass nur Ihr Dienstkonto in einem bestimmten Namespace aus Ihrem Cluster diese Rolle übernehmen kann:

  "Condition": {
      "StringEquals": {
          "oidc.eks.us-west-2.amazonaws.com/id/D43CF17C27A865933144EA99A26FB128:aud": "sts.amazonaws.com",
          "oidc.eks.us-west-2.amazonaws.com/id/D43CF17C27A865933144EA99A26FB128:sub": "system:serviceaccount:default:s3-read-only"
      }
  }

Verwenden Sie eine IAM-Rolle pro Anwendung

Sowohl bei IRSA als auch bei EKS Pod Identity hat es sich bewährt, jeder Anwendung ihre eigene IAM-Rolle zuzuweisen. Dadurch erhalten Sie eine bessere Isolierung, da Sie eine Anwendung ändern können, ohne eine andere zu beeinträchtigen. Außerdem können Sie das Prinzip der geringsten Rechte anwenden, indem Sie einer Anwendung nur die Berechtigungen gewähren, die sie benötigt.

Wenn Sie ABAC mit EKS Pod Identity verwenden, können Sie eine gemeinsame IAM-Rolle für mehrere Dienstkonten verwenden und sich bei der Zugriffskontrolle auf deren Sitzungsattribute verlassen. Dies ist besonders nützlich, wenn Sie in großem Umfang arbeiten, da ABAC es Ihnen ermöglicht, mit weniger IAM-Rollen zu arbeiten.

Wenn Ihre Anwendung Zugriff auf IMDS benötigt, verwenden Sie IMDSv2 und erhöhen Sie das Hop-Limit für EC2-Instances auf 2

IMDSv2 erfordert, dass Sie eine PUT-Anfrage verwenden, um ein Sitzungstoken abzurufen. Die anfängliche PUT-Anforderung muss eine TTL für das Sitzungstoken enthalten. Neuere Versionen der AWS-SDKs erledigen dies und die Verlängerung des Tokens automatisch. Es ist auch wichtig, sich bewusst zu sein, dass das Standard-Hop-Limit für EC2-Instances absichtlich auf 1 gesetzt ist, um eine IP-Weiterleitung zu verhindern. Folglich kann es bei Pods, die ein Sitzungstoken anfordern und auf EC2-Instances ausgeführt werden, irgendwann zu einem Timeout kommen und auf den IMDSv1-Datenfluss zurückgreifen. EKS fügt Unterstützung für IMDSv2 hinzu, indem sowohl v1 als auch v2 aktiviert und das Hop-Limit für Knoten, die von eksctl oder mit den offiziellen Vorlagen bereitgestellt werden, auf 2 geändert wird. CloudFormation

Deaktivieren Sie das automatische Mounten von Dienstkonto-Tokens

Wenn Ihre Anwendung die Kubernetes-API nicht aufrufen muss, setzen Sie das automountServiceAccountToken Attribut PodSpec für Ihre Anwendung auf false in oder patchen Sie das Standarddienstkonto in jedem Namespace, sodass es nicht mehr automatisch in Pods eingebunden wird. Beispiel:

kubectl patch serviceaccount default -p $'automountServiceAccountToken: false'

Verwenden Sie für jede Anwendung dedizierte Dienstkonten

Jede Anwendung sollte über ein eigenes dediziertes Dienstkonto verfügen. Dies gilt für Dienstkonten für die Kubernetes-API sowie für IRSA und EKS Pod Identity.

Führen Sie die Anwendung als Nicht-Root-Benutzer aus

Container werden standardmäßig als Root ausgeführt. Dadurch können sie zwar die Web-Identity-Tokendatei lesen, es wird jedoch nicht als bewährte Methode angesehen, einen Container als Root auszuführen. Als Alternative können Sie erwägen, das spec.securityContext.runAsUser Attribut dem hinzuzufügen PodSpec. Der Wert von runAsUser ist ein beliebiger Wert.

Im folgenden Beispiel werden alle Prozesse innerhalb des Pods unter der im runAsUser Feld angegebenen Benutzer-ID ausgeführt.

apiVersion: v1
kind: Pod
metadata:
  name: security-context-demo
spec:
  securityContext:
    runAsUser: 1000
    runAsGroup: 3000
  containers:
  - name: sec-ctx-demo
    image: busybox
    command: [ "sh", "-c", "sleep 1h" ]

Wenn Sie einen Container ohne Root-Benutzer ausführen, verhindert dies, dass der Container das IRSA-Dienstkonto-Token liest, da dem Token standardmäßig 0600 [root] -Berechtigungen zugewiesen sind. Wenn Sie den SecurityContext für Ihren Container so aktualisieren, dass er fsgroup=65534 [Nobody] enthält, kann der Container das Token lesen.

spec:
  securityContext:
    fsGroup: 65534

In Kubernetes 1.19 und höher ist diese Änderung nicht mehr erforderlich und Anwendungen können das IRSA-Dienstkonto-Token lesen, ohne sie der Gruppe Nobody hinzuzufügen.

Gewähren Sie Anwendungen den Zugriff mit den geringsten Rechten

Action Hero ist ein Hilfsprogramm, das Sie zusammen mit Ihrer Anwendung ausführen können, um die AWS-API-Aufrufe und die entsprechenden IAM-Berechtigungen zu identifizieren, die Ihre Anwendung benötigt, um ordnungsgemäß zu funktionieren. Es ähnelt IAM Access Advisor insofern, als es Ihnen hilft, den Umfang der IAM-Rollen, die Anwendungen zugewiesen sind, schrittweise einzuschränken. Weitere Informationen finden Sie in der Dokumentation zur Gewährung des Zugriffs mit den geringsten Rechten auf AWS-Ressourcen.

Erwägen Sie, eine Berechtigungsgrenze für IAM-Rollen festzulegen, die mit IRSA- und Pod-Identitäten verwendet werden. Sie können die Berechtigungsgrenze verwenden, um sicherzustellen, dass die von IRSA- oder Pod-Identitäten verwendeten Rollen eine maximale Berechtigungsstufe nicht überschreiten dürfen. Eine Beispielanleitung für die ersten Schritte mit Berechtigungsgrenzen mit einer Beispielrichtlinie für Berechtigungsgrenzen finden Sie in diesem Github-Repo.

Überprüfen und widerrufen Sie unnötigen anonymen Zugriff auf Ihren EKS-Cluster

Idealerweise sollte der anonyme Zugriff für alle API-Aktionen deaktiviert werden. Anonymer Zugriff wird gewährt, indem ein RoleBinding oder ClusterRoleBinding für das in Kubernetes integrierte Benutzersystem erstellt wird: anonymous. Sie können das Tool rbac-lookup verwenden, um die Berechtigungen zu ermitteln, die system:anonymous user für Ihren Cluster hat:

./rbac-lookup | grep -P 'system:(anonymous)|(unauthenticated)'
system:anonymous               cluster-wide        ClusterRole/system:discovery
system:unauthenticated         cluster-wide        ClusterRole/system:discovery
system:unauthenticated         cluster-wide        ClusterRole/system:public-info-viewer

Jede ClusterRole andere Rolle als system:public-info-viewer sollte nicht an system:anonymous user oder system:unauthenticated group gebunden sein.

Es kann einige legitime Gründe geben, den anonymen Zugriff auf bestimmte APIs zu aktivieren. Wenn dies bei Ihrem Cluster der Fall ist, stellen Sie sicher, dass anonyme Benutzer nur auf diese spezifischen APIs zugreifen können. Wenn Sie diese APIs ohne Authentifizierung verfügbar machen, ist Ihr Cluster nicht anfällig.

Vor Kubernetes/EKS Version 1.14 war die Gruppe system:unauthenticated standardmäßig system:discovery und system:basic-user zugeordnet. ClusterRoles Beachten Sie, dass selbst wenn Sie Ihren Cluster auf Version 1.14 oder höher aktualisiert haben, diese Berechtigungen in Ihrem Cluster möglicherweise immer noch aktiviert sind, da Cluster-Updates diese Berechtigungen nicht widerrufen. Um zu überprüfen, welche außer system:public-info-viewer ClusterRoles über „system:unauthenticated“ verfügen, können Sie den folgenden Befehl ausführen (benötigt jq util):

kubectl get ClusterRoleBinding -o json | jq -r '.items[] | select(.subjects[]?.name =="system:unauthenticated") | select(.metadata.name != "system:public-info-viewer") | .metadata.name'

Und „system:unauthenticated“ kann aus allen Rollen außer „system:public-info-viewer“ entfernt werden, indem man:

kubectl get ClusterRoleBinding -o json | jq -r '.items[] | select(.subjects[]?.name =="system:unauthenticated") | select(.metadata.name != "system:public-info-viewer") | del(.subjects[] | select(.name =="system:unauthenticated"))' | kubectl apply -f -

Alternativ können Sie es manuell mit kubectl describe und kubectl edit überprüfen und entfernen. Um zu überprüfen, ob system:unauthenticated group über system:discovery-Berechtigungen für Ihren Cluster verfügt, führen Sie den folgenden Befehl aus:

kubectl describe clusterrolebindings system:discovery

Name:         system:discovery
Labels:       kubernetes.io/bootstrapping=rbac-defaults
Annotations:  rbac.authorization.kubernetes.io/autoupdate: true
Role:
  Kind:  ClusterRole
  Name:  system:discovery
Subjects:
  Kind   Name                    Namespace
  ----   ----                    ---------
  Group  system:authenticated
  Group  system:unauthenticated

Um zu überprüfen, ob system:unauthenticated group die system:basic-user-Berechtigung auf Ihrem Cluster hat, führen Sie den folgenden Befehl aus:

kubectl describe clusterrolebindings system:basic-user

Name:         system:basic-user
Labels:       kubernetes.io/bootstrapping=rbac-defaults
Annotations:  rbac.authorization.kubernetes.io/autoupdate: true
Role:
  Kind:  ClusterRole
  Name:  system:basic-user
Subjects:
  Kind   Name                    Namespace
  ----   ----                    ---------
  Group  system:authenticated
  Group  system:unauthenticated

Wenn system:unauthenticated group auf Ihrem Cluster an system:discovery system:basic-user gebunden ist, sollten Sie diese Rollen von der Gruppe and/or system:unauthenticated trennen. ClusterRoles Bearbeiten Sie ClusterRoleBinding system:discovery mit dem folgenden Befehl:

kubectl edit clusterrolebindings system:discovery

Der obige Befehl öffnet die aktuelle Definition von system:discovery ClusterRoleBinding in einem Editor, wie unten gezeigt:

# Please edit the object below. Lines beginning with a '#' will be ignored,
# and an empty file will abort the edit. If an error occurs while saving this file will be
# reopened with the relevant failures.
#
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  annotations:
    rbac.authorization.kubernetes.io/autoupdate: "true"
  creationTimestamp: "2021-06-17T20:50:49Z"
  labels:
    kubernetes.io/bootstrapping: rbac-defaults
  name: system:discovery
  resourceVersion: "24502985"
  selfLink: /apis/rbac.authorization.k8s.io/v1/clusterrolebindings/system%3Adiscovery
  uid: b7936268-5043-431a-a0e1-171a423abeb6
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: system:discovery
subjects:
- apiGroup: rbac.authorization.k8s.io
  kind: Group
  name: system:authenticated
- apiGroup: rbac.authorization.k8s.io
  kind: Group
  name: system:unauthenticated

Löschen Sie den Eintrag für die Gruppe system:unauthenticated aus dem Abschnitt „Subjects“ im obigen Editor-Bildschirm.

Wiederholen Sie die gleichen Schritte für system:basic-user. ClusterRoleBinding

Verwenden Sie AWS-SDK-Sitzungen mit IRSA wieder

Wenn Sie IRSA verwenden, verwenden Anwendungen, die mit dem AWS-SDK geschrieben wurden, das an Ihre Pods übermittelte Token, um sie aufzurufen und temporäre AWS-Anmeldeinformationen sts:AssumeRoleWithWebIdentity zu generieren. Dies unterscheidet sich von anderen AWS-Rechenservices, bei denen der Rechenservice temporäre AWS-Anmeldeinformationen direkt an die AWS-Rechenressource übermittelt, z. B. eine Lambda-Funktion. Das bedeutet, dass jedes Mal, wenn eine AWS-SDK-Sitzung initialisiert wird, ein Aufruf an AWS STS for AssumeRoleWithWebIdentity erfolgt. Wenn Ihre Anwendung schnell skaliert und viele AWS-SDK-Sitzungen initialisiert, kann es zu einer Drosselung durch AWS STS kommen, da Ihr Code viele Aufrufe tätigen wird. AssumeRoleWithWebIdentity

Um dieses Szenario zu vermeiden, empfehlen wir, AWS-SDK-Sitzungen in Ihrer Anwendung wiederzuverwenden, damit keine unnötigen Aufrufe von getätigt werden. AssumeRoleWithWebIdentity

Im folgenden Beispielcode wird eine Sitzung mit dem Boto3-Python-SDK erstellt, und dieselbe Sitzung wird verwendet, um Clients zu erstellen und sowohl mit Amazon S3 als auch mit Amazon SQS zu interagieren. AssumeRoleWithWebIdentitywird nur einmal aufgerufen, und das AWS-SDK aktualisiert die Anmeldeinformationen automatisch, my_session wenn sie ablaufen.

import boto3

= Create your own session

my_session = boto3.session.Session()

= Now we can create low-level clients from our session

sqs = my_session.client('`sqs`') s3 = my_session.client('`s3`')

s3response = s3.list_buckets() sqsresponse = sqs.list_queues()

#print the response from the S3 and SQS APIs print("`s3 response:`")
print(s3response) print("`—`") print("`sqs response:`")
print(sqsresponse)

Wenn Sie eine Anwendung mit IRSA von einem anderen AWS-Rechenservice wie EC2 zu EKS migrieren, ist dies ein besonders wichtiges Detail. Bei anderen Rechenservices ruft die Initialisierung einer AWS-SDK-Sitzung AWS STS nicht auf, es sei denn, Sie weisen es an.

Alternative Ansätze

IRSA- und EKS-Pod-Identitäten sind zwar die bevorzugten Methoden, um einem Pod eine AWS-Identität zuzuweisen, erfordern jedoch, dass Sie die aktuelle Version der AWS-SDKs in Ihre Anwendung aufnehmen. Eine vollständige Liste der SDKs, die derzeit IRSA unterstützenhttps://docs.aws.amazon.com/eks/latest/userguide/iam-roles-for-service-accounts-minimum-sdk.html, finden Sie für EKS-Pod-Identitäten unter https://docs.aws.amazon.com/eks/latest/userguide/pod-id-minimum-sdk.html. Wenn Sie eine Anwendung haben, die Sie nicht sofort mit einem kompatiblen SDK aktualisieren können, stehen mehrere von der Community entwickelte Lösungen für die Zuweisung von IAM-Rollen zu Kubernetes-Pods zur Verfügung, darunter kube2iam und kiam. Obwohl AWS die Verwendung dieser Lösungen nicht befürwortet, duldet oder unterstützt, werden sie häufig von der gesamten Community verwendet, um ähnliche Ergebnisse zu erzielen wie IRSA und EKS Pod Identities.

Wenn Sie eine dieser Lösungen verwenden müssen, die nicht von AWS bereitgestellt werden, gehen Sie bitte mit der gebotenen Sorgfalt vor und stellen Sie sicher, dass Sie die damit verbundenen Sicherheitsrisiken verstehen.

Tools und Ressourcen