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 wesentliche Funktionen erfüllt: Authentifizierung und Autorisierung. Die Authentifizierung beinhaltet die Überprüfung einer Identität, wohingegen die Autorisierung die Aktionen regelt, die von AWS-Ressourcen ausgeführt werden können. Innerhalb von AWS kann es sich bei einer Ressource beispielsweise EC2 um einen anderen AWS-Service oder um einen AWS-Principal wie einen IAM-Benutzer oder eine IAM-Rolle handeln. Die Regeln für die Aktionen, 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-Service, z. B. Bearer-Token, X.509-Zertifikate, OIDC usw. EKS bietet derzeit native Unterstützung für die Webhook-Token-Authentifizierung, Dienstkonto-Token und seit dem 21. Februar 2021 auch die OIDC-Authentifizierung.

Die Webhook-Authentifizierungsstrategie ruft einen Webhook auf, der Inhaber-Token verifiziert. Auf EKS werden diese Bearer-Token von der AWS-CLI oder dem aws-iam-authenticatorClient generiert, wenn Sie kubectl Befehle ausführen. Wenn 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 Konto des Benutzers, 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>

Sie können ein Token auch programmgesteuert abrufen. Im Folgenden finden Sie 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 so 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. Wenn die Zeichenfolge dekodiert wird, sollte sie etwa so 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 einen Amazon-Berechtigungsnachweis und eine Signatur enthält. Weitere Informationen finden Sie unter https://docs.aws.amazon.com/STS/latest/APIReference/API_ GetCallerIdentity .html.

Das Token hat eine Gültigkeitsdauer (TTL) von 15 Minuten. Danach muss ein neues Token generiert werden. Dies erfolgt automatisch, wenn Sie einen Client verwendenkubectl, z. B. wenn Sie das Kubernetes-Dashboard verwenden, müssen Sie ein neues Token generieren und sich jedes Mal neu authentifizieren, wenn das Token abläuft.

Sobald die Identität des Benutzers durch den AWS IAM-Service authentifiziert wurde, liest der Kube-Apiserver die aws-auth ConfigMap im kube-system Namespace, um die RBAC-Gruppe zu bestimmen, die dem Benutzer zugeordnet werden soll. Das aws-auth ConfigMap wird verwendet, um eine statische Zuordnung zwischen IAM-Prinzipalen, d. h. IAM-Benutzern und -Rollen, und Kubernetes-RBAC-Gruppen zu erstellen. RBAC-Gruppen können in Kubernetes oder referenziert 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.

Cluster-Zugriffsmanager

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 optionale Funktion für EKS v1.23 und spätere Cluster (neu oder bereits vorhanden). Es vereinfacht die Identitätszuweisung zwischen AWS IAM und KubernetesRBACs, sodass Sie nicht zwischen AWS und Kubernetes wechseln APIs oder das 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 Clusteradministratoren 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 Kubernetes AuthZ-Entscheidungen in Bezug auf API-Serveranfragen unterstützen und zulassen (aber nicht verweigern). Eine Ablehnungsentscheidung wird getroffen, wenn sowohl der vorgelagerte RBAC- als auch der Amazon EKS-Autorisierer das Ergebnis einer Anfragebewertung nicht bestimmen können.

Mit dieser Funktion unterstützt Amazon EKS drei Authentifizierungsmodi:

Zunächst können Clusteradministratoren Amazon EKS-Cluster erstellen oder aktualisieren, indem sie die bevorzugte Authentifizierung auf API_AND_CONFIG_MAP oder API -methode festlegen und Zugriffseinträge definieren, um 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 bereits ohne die Administratorrechte des Clustererstellers.

Es ist möglich, die Amazon EKS-Clusterkonfiguration mithilfe des update-cluster-config Befehls zu aktualisieren, um den 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 nicht von API 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 zum Überprüfen der vorhandenen Zugriffsrichtlinien und Zugriffseinträge für den angegebenen Cluster. Die Standardrichtlinien werden RBACs wie folgt so erstellt, dass sie zu Kubernetes passen.

$ 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": []
}

Es sind keine Zugriffseinträge verfügbar, wenn der Cluster ohne die Administratorberechtigung für den Clusterersteller erstellt wird. Dies ist der einzige Eintrag, der standardmäßig erstellt wird.

Der aws-auth ConfigMap (veraltet)

Eine Möglichkeit, die Kubernetes-Integration mit der AWS-Authentifizierung durchzuführen, ist die aws-auth ConfigMap, die sich im Namespace befindet. kube-system Es ist verantwortlich für die Zuordnung der AWS IAM-Authentifizierung (Benutzer, Gruppen und Rollen) zur rollenbasierten Zugriffskontrolle (RBAC) von Kubernetes. Der 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, aber wie bereits erwähnt, können Sie damit ConfigMap auch RBACs Zugriff auf IAM-Prinzipale gewähren.

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 davon ConfigMap befindet sich unter dem data mapRoles Block, der im Wesentlichen aus 3 Parametern besteht.

Es ist auch möglich, Berechtigungen für AWS IAM-Benutzer zuzuordnen und einen neuen Konfigurationsblock fürmapUsers, unterdata, zu definieren aws-authConfigMap, der den rolearn-Parameter für userarn ersetzt. 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, sie aws-auth ConfigMap manuell zu bearbeiten, es wird jedoch empfohlen, Tools wie zu verwendeneksctl, da es sich um eine sehr sensible Konfiguration handelt und eine ungenaue Konfiguration Sie außerhalb Ihres Amazon EKS-Clusters sperren kann. Weitere Informationen finden Sie unten im Unterabschnitt Tools verwenden, um Änderungen an ConfigMap aws-auth vorzunehmen.

Empfehlungen für den Clusterzugriff

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. auf ihn kann über das Internet zugegriffen 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 auf einer AWS-Infrastruktur wie EC2 Instances ausgeführt werden, sollten Sie erwägen, ein Instance-Profil zu verwenden und dieses einer Kubernetes-RBAC-Rolle zuzuordnen.

Verwenden Sie den Zugriff mit den geringsten Rechten 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 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-Ersteller-Prinzipal

Standardmäßig werden Amazon EKS-Cluster mit einer dauerhaften cluster-admin Berechtigung erstellt, die an den Cluster-Erstellerprinzipal gebunden ist. Mit der Cluster Access Manager-API ist es möglich, Cluster zu erstellen, ohne dass diese Berechtigung den Authentifizierungsmodus --access-config bootstrapClusterCreatorAdminPermissions auffalse, bei der Verwendung API_AND_CONFIG_MAP oder den API Authentifizierungsmodus setzt. Das Widerrufen dieses Zugriffs wurde als bewährte Methode angesehen, um unerwünschte Änderungen an der Clusterkonfiguration zu vermeiden. Das Verfahren zum Widerrufen dieses Zugriffs folgt demselben Verfahren zum Widerrufen aller anderen Zugriffe auf den Cluster.

Die API bietet Ihnen die Flexibilität, nur einen IAM-Prinzipal von einer Zugriffsrichtlinie zu trennen, in diesem Fall der. 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 Sie entfernen den mit der Berechtigung verknüpften Zugriffseintrag vollständig. 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 erneut gewährt werden, falls dies bei einem Zwischenfall, einem Notfall oder einem Breakglasszenario erforderlich ist, bei dem ansonsten kein Zugriff auf den Cluster möglich ist.

Wenn der Cluster immer noch mit der CONFIG_MAP Authentifizierungsmethode konfiguriert aws-auth ConfigMap ist, sollte allen zusätzlichen Benutzern Zugriff auf den Cluster gewährt werden. Nach der aws-auth ConfigMap Konfiguration kann die Rolle, die der Entität zugewiesen wurde, die den Cluster erstellt hat, gelöscht und nur dann neu erstellt werden, wenn ein Vorfall, ein Notfall oder ein Breakglass-Szenario vorliegt oder wenn der Cluster beschädigt aws-auth ConfigMap ist und der Cluster anderweitig 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 aws-auth configMap weiterhin als Authentifizierungsmethode verwenden und einer IAM-Rolle die RBAC-Berechtigungen von K8 zuweisen, sollten Sie\ {{}} in Ihren Benutzernamen aufnehmen. SessionName Auf diese Weise zeichnet das Audit-Protokoll den Sitzungsnamen auf, sodass Sie zusammen mit dem Protokoll nachverfolgen können, wer der tatsächliche Benutzer diese Rolle übernommen hat. CloudTrail

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

Verwenden Sie bei der Erstellung und den Zugriff mit den geringsten Rechten RoleBindings ClusterRoleBindings

Wie der vorherige Punkt über die Gewährung des Zugriffs auf AWS-Ressourcen, RoleBindings und ClusterRoleBindings sollte nur die Berechtigungen enthalten, die für die Ausführung einer bestimmten Funktion erforderlich sind. 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 ein Tool wie audit2rbac 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 beim Erstellen eines Amazon EKS-Clusters 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 gewährt, wenn nicht der Verwendungs- oder API Authentifizierungsmodus verwendet wird und die Delegierung von system:masters Berechtigungen an den Cluster-Ersteller nicht deaktiviert wird. Es ist sogar eine bewährte Methode, diese Berechtigung zu entfernen, wie hier beschrieben, wenn Sie die CONFIG_MAP Authentifizierungsmethode verwenden, und sich darauf verlassen aws-auth ConfigMap, dass dieser Zugriff nicht widerrufen werden kann. Daher ist es eine gute Idee, den Cluster mit einer Pipeline zur Infrastrukturautomatisierung zu erstellen, die an eine dedizierte IAM-Rolle gebunden ist, ohne dass Rechte von anderen Benutzern oder Entitäten übernommen werden 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 Durchführung von Routineaktionen auf dem Cluster verwendet werden. Sie sollte ausschließlich für Aktionen auf Clusterebene verwendet werden, die durch die Pipeline ausgelöst werden, beispielsweise über 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 gewährt. Dieser Zugriff kann nicht entfernt werden und wird nicht über den verwaltet. aws-auth ConfigMap Daher empfiehlt es sich, den Cluster mit einer eigenen IAM-Rolle zu erstellen und regelmäßig zu überprüfen, wer diese Rolle übernehmen kann. Diese Rolle sollte nicht zur Durchführung von Routineaktionen auf dem Cluster verwendet werden. Stattdessen sollte zu diesem Zweck zusätzlichen Benutzern über den Zugriff auf den aws-auth ConfigMap Cluster gewährt werden. Nach der aws-auth ConfigMap Konfiguration sollte die Rolle gesichert und nur im temporären Modus mit erhöhten Rechten (Breakglass) für Szenarien verwendet werden, in denen ansonsten kein Zugriff auf den Cluster möglich ist. Dies kann besonders in Clustern nützlich sein, für die kein direkter Benutzerzugriff konfiguriert ist.

Überprüfen Sie regelmäßig den Zugriff auf den Cluster

Wer Zugriff benötigt, wird sich wahrscheinlich im Laufe der Zeit ändern. Planen Sie, sie 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 oder rbac-Lookup verwenden kubectl-who-can, 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. 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 eine IAM-Rolle zu einem 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 den Dokumenten eksctl

aws-auth von keikoproj

aws-authvon keikoproj enthält 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
...

Alternativ können Sie die Installation aws-auth mit dem Krew-Plugin-Manager für Kubectl durchführen.

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

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

AWS-IAM-Authentifikator-CLI

Das aws-iam-authenticator Projekt enthält eine CLI zur Aktualisierung derConfigMap.

Laden Sie eine Version herunter am GitHub.

Fügen Sie Clusterberechtigungen 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 für Authentifizierung und Zugriffsmanagement

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. einen Authentifizierungsproxy und Kubernetes-Identitätswechsel zu GitHub verwenden. Beiträge zu zwei solchen 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 AWS CLI v2.0 eine Option zum Erstellen eines benannten Profils, mit dem Sie ganz einfach eine SSO-Sitzung mit Ihrer aktuellen CLI-Sitzung verknüpfen und eine IAM-Rolle übernehmen können. 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 ermitteln.

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 Services aufzulisten. Der Controller muss außerdem in der Lage sein, AWS aufzurufen APIs , um eine ALB bereitzustellen und zu konfigurieren. In diesem Abschnitt werden wir die bewährten Methoden für die Zuweisung von Rechten und Privilegien an Pods untersuchen.

Kubernetes-Dienstkonten

Ein Dienstkonto ist ein besonderer Objekttyp, mit dem Sie einem Pod eine Kubernetes-RBAC-Rolle zuweisen können. Für jeden Namespace innerhalb eines Clusters wird automatisch ein Standarddienstkonto 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 dem Pod als Volume hinzugefügt. /var/run/secrets/kubernetes.io/serviceaccount Durch die Dekodierung 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 berechtigt nicht authentifizierte und authentifizierte Benutzer zum Lesen von API-Informationen und gilt als sicher, wenn sie öffentlich zugänglich ist.

Wenn eine Anwendung, die in einem Pod ausgeführt wird, Kubernetes aufruft APIs, muss dem Pod ein Dienstkonto zugewiesen werden, das ihm ausdrücklich die Erlaubnis erteilt, diese aufzurufen. APIs Ä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 sein, die die Anwendung benötigt, um zu funktionieren, 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. Es nutzt eine Kubernetes-Funktion, die als Service Account Token Volume Projection bekannt ist. Wenn Pods mit einem Dienstkonto konfiguriert sind, 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 kryptografisch das von Kubernetes ausgegebene OIDC-Token und das daraus resultierende Token wird als Volume bereitgestellt. Dieses signierte Token ermöglicht es dem Pod, die APIs mit AWS verknüpfte IAM-Rolle aufzurufen. Wenn eine AWS-API aufgerufen wird, SDKs ruft sts:AssumeRoleWithWebIdentity AWS auf. Nach der Überprüfung der Tokensignatur tauscht IAM das von Kubernetes ausgestellte Token gegen temporäre AWS-Rollenanmeldedaten aus.

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

Die Dekodierung des (JWT-) Tokens für IRSA erzeugt eine Ausgabe, 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 nur Leseberechtigungen für den Pod, indem es eine IAM-Rolle annimmt. 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-Steuerebene ausgeführt wird, fügt den AWS-Rollen-ARN und den Pfad zu einer Web-Identity-Token-Datei als Umgebungsvariablen in den Pod ein. Diese Werte können auch manuell angegeben 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 - -technical-overview.html. roles-for-service-accounts

EKS-Pod-Identitäten

EKS Pod Identities ist eine auf der re:Invent 2023 eingeführte Funktion, mit der Sie einem Kubernetes-Servicekonto eine IAM-Rolle zuweisen können, ohne für jeden Cluster in Ihrem AWS-Konto einen Open Id Connect (OIDC) -Identitätsanbieter (IDP) konfigurieren zu müssen. Um EKS Pod Identity verwenden zu können, müssen Sie einen Agenten bereitstellen, der als Pod auf jedem geeigneten Worker-Knoten ausgeführt wird. DaemonSet Dieser Agent wird Ihnen als EKS-Add-on zur Verfügung gestellt 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 AssumeRoleForPodIdentityAPI aufruft. Das an Ihre Pods übermittelte Pod-Identitätstoken ist ein JWT, das von Ihrem EKS-Cluster ausgegeben und kryptografisch signiert wurde und entsprechende JWT-Ansprüche für die Verwendung mit EKS Pod Identities enthält.

Weitere Informationen zu EKS Pod Identities finden Sie in diesem Blog.

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 mitzuteilen, 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, aws:SourceOrgId um sich vor dem dienstübergreifenden Problem Confused Deputy zu schützen. Im obigen Beispiel für eine Vertrauensrichtlinie für Rollen ResourceOrgId ist dies 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 mit EKS Pod Identities übernimmt.

ABAC- und EKS-Pod-Identitäten

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

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

Wenn Sie beispielsweise nur einem bestimmten Dienstkonto Zugriff gewähren möchten, um auf eine AWS-Ressource in Ihrem Konto mit einer IAM- oder Ressourcenrichtlinie zuzugreifen, müssten Sie überprüfen eks-cluster-arn und kubernetes-namespace kennzeichnen sowie sicherstellen, dass nur Dienstkonten aus dem vorgesehenen Cluster Zugriff auf diese Ressource haben, da andere Cluster identische kubernetes-service-accounts und kubernetes-namespaces haben könnten. kubernetes-service-account

Dieses Beispiel für eine S3-Bucket-Richtlinie gewährt nur dann Zugriff auf Objekte in dem S3-Bucket, an den sie angehängt ist kubernetes-service-accountkubernetes-namespace, 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 Identities 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, bei der Verwendung von EKS Pod Identities zu verwenden. Diese Tabelle hilft beim Vergleich der beiden Funktionen.

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

Aktualisieren Sie das aws-node-Daemonset für die Verwendung von IRSA

Derzeit ist der aws-node-Daemonset so konfiguriert, dass er eine den Instanzen zugewiesene Rolle verwendet, um sie Pods zuzuweisen. EC2 IPs Diese Rolle umfasst mehrere von AWS verwaltete Richtlinien, z. B. Amazoneks_CNI_Policy, die es allen Pods EC2ContainerRegistryReadOnly , die auf einem Knoten laufen, ermöglichen attach/detach ENIs, assign/unassign IP-Adressen zu verwenden oder Bilder aus ECR abzurufen. Da dies ein Risiko für Ihren Cluster darstellt, wird empfohlen, das aws-node-Daemonset so zu aktualisieren, dass es IRSA verwendet. Ein Skript dafür finden Sie im Repository für dieses Handbuch.

Der aws-node-Daemonset unterstützt EKS Pod Identities in den Versionen v1.15.5 und höher.

Beschränken Sie den Zugriff auf das dem Worker-Knoten zugewiesene Instanzprofil

Wenn Sie IRSA- oder EKS-Pod-Identitäten verwenden, wird die Anmeldeinformationskette des Pods so aktualisiert, dass 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 Instanz-Metadaten blockieren, um sicherzustellen, dass Ihre Anwendungen nur über die Berechtigungen verfügen, die sie benötigen, und nicht ihre Knoten.

Sie können den Zugriff auf Instanz-Metadaten blockieren, indem Sie festlegen, dass die Instance IMDSv2 nur die Instance verwenden darf, und die Anzahl der Hops auf 1 aktualisieren, wie im folgenden Beispiel gezeigt. Sie können diese Einstellungen auch in die Startvorlage der Knotengruppe aufnehmen. Deaktivieren Sie die Instanz-Metadaten nicht, da dies verhindert, dass Komponenten wie der Node Termination Handler und andere Dinge, die auf Instanz-Metadaten 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 den Zugriff eines Pods auf EC2 Metadaten auch blockieren, indem Sie iptables auf dem Knoten manipulieren. Weitere Informationen zu dieser Methode finden Sie unter Beschränken des Zugriffs auf den Instanz-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.

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

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

Wenn Sie direkt mit IAM arbeiten, fügt dies der Vertrauensrichtlinie der Rolle eine Bedingung hinzu, die anhand von Bedingungen sicherstellt, dass es sich bei dem :sub Anspruch um den Namespace und das Dienstkonto handelt, die Sie erwarten. Zum Beispiel hatten wir zuvor ein IRSA-Token mit dem Unteranspruch „system:serviceaccount:default:s3-read-only“. Dies 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 ist es eine bewährte Methode, jeder Anwendung ihre eigene IAM-Rolle zuzuweisen. Dadurch erhalten Sie eine verbesserte Isolierung, da Sie eine Anwendung ändern können, ohne dass sich dies auf eine andere auswirkt. 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 Sie mit ABAC mit weniger IAM-Rollen arbeiten können.

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

IMDSv2erfordert, dass Sie eine PUT-Anfrage verwenden, um ein Sitzungstoken zu erhalten. Die erste PUT-Anfrage muss eine TTL für das Sitzungstoken enthalten. Neuere Versionen von AWS SDKs werden dies und die Verlängerung dieses Tokens automatisch handhaben. Es ist auch wichtig zu beachten, dass das Standard-Hop-Limit für EC2 Instances bewusst auf 1 gesetzt ist, um eine IP-Weiterleitung zu verhindern. Infolgedessen kann es bei Pods, die ein Sitzungstoken anfordern und auf EC2 Instances ausgeführt werden, irgendwann zu einem Timeout kommen und auf die Nutzung des IMDSv1 Datenflusses zurückgreifen. EKS fügt Unterstützung hinzu, IMDSv2 indem es sowohl v1 als auch v2 aktiviert und das Hop-Limit auf Knoten, die von eksctl oder mit den offiziellen Vorlagen bereitgestellt werden, auf 2 ändert. 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 oder patchen Sie das Standarddienstkonto in jedem Namespace, sodass es nicht mehr automatisch in Pods eingebunden wird. Zum Beispiel:

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

Verwenden Sie spezielle Dienstkonten für jede Anwendung

Jede Anwendung sollte über ein eigenes 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-Token-Datei lesen, aber die Ausführung eines Containers als Root-Benutzer wird nicht als bewährte Methode angesehen. Als Alternative könnten 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 als Nicht-Root-Benutzer ausführen, wird verhindert, dass der Container das Token des IRSA-Dienstkontos 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 Nobody-Gruppe 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 einem Beispiel für eine Richtlinie 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 in Ihrem 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 Rolle oder eine 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 Bereiche zu aktivieren. APIs Wenn dies bei Ihrem Cluster der Fall ist, stellen Sie sicher, dass nur die spezifischen APIs Daten für anonyme Benutzer zugänglich sind. Wenn Sie diese Daten APIs ohne Authentifizierung offenlegen, wird Ihr Cluster nicht anfällig.

Vor Kubernetes/EKS Version 1.14 war die Gruppe system:unauthenticated standardmäßig mit system:discovery und system:basic-user verknüpft. ClusterRoles Beachten Sie, dass diese Berechtigungen auch dann noch auf Ihrem Cluster aktiviert sein können, wenn Sie Ihren Cluster auf Version 1.14 oder höher aktualisiert haben, da Cluster-Updates diese Berechtigungen nicht entziehen. Um zu überprüfen, welche „system:unauthenticated“ außer system: ClusterRoles haben, können public-info-viewer Sie den folgenden Befehl ausführen (erfordert 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:“ entfernt werden, indem man: public-info-viewer

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. Führen Sie den folgenden Befehl aus, um zu überprüfen, ob system:unauthenticated group über system:discovery-Berechtigungen für Ihren Cluster verfügt:

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

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

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 und/oder system:basic-user gebunden ist, sollten Sie diese Rollen von system:unauthenticated group 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

Wiederverwendung von AWS-SDK-Sitzungen mit IRSA

Wenn Sie IRSA verwenden, verwenden Anwendungen, die mit dem AWS-SDK geschrieben wurden, das an Ihre Pods gelieferte Token für Aufrufe, um 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 Drosselungen durch AWS STS kommen, da Ihr Code viele Aufrufe tätigen wird. AssumeRoleWithWebIdentity

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

Im folgenden Beispielcode wird eine Sitzung mit dem Boto3-Python-SDK erstellt, und dieselbe Sitzung wird verwendet, um Clients zu erstellen und mit Amazon S3 und Amazon SQS zu interagieren. AssumeRoleWithWebIdentitywird nur einmal aufgerufen, und das AWS-SDK aktualisiert die Anmeldeinformationen automatischmy_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 von einem anderen AWS-Rechenservice migrieren, z. B. EC2 zu EKS mit IRSA, ist dies ein besonders wichtiges Detail. Bei anderen Rechendiensten ruft die Initialisierung einer AWS-SDK-Sitzung AWS STS nur auf, wenn Sie sie dazu anweisen.

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 von AWS SDKs in Ihre Anwendung aufnehmen. Eine vollständige Liste der Programme SDKs, die derzeit IRSA unterstützen, finden Sie unter https://docs.aws.amazon.com/eks/latest/userguide/iam- roles-for-service-accounts -minimum-sdk.html. EKS-Pod-Identitäten finden Sie unter .html. https://docs.aws.amazon.com/eks/ latest/userguide/pod id-minimum-sdk 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, wenden Sie bitte die gebotene Sorgfalt an und stellen Sie sicher, dass Sie die damit verbundenen Sicherheitsauswirkungen verstehen.

Tools und Ressourcen