kubernetes-sigs/aws-iam-authenticatorEin Tool zur Authentifizierung an einem Kubernetes-Cluster mithilfe von AWS-IAM-Anmeldeinformationen.
Ein Tool, um AWS-IAM-Anmeldedaten zu verwenden, um sich bei einem Kubernetes-Cluster zu authentifizieren. Die ursprüngliche Arbeit an diesem Tool wurde von Heptio vorangetrieben. Das Projekt erhält Beiträge von zahlreichen Community-Entwicklern und wird derzeit von Heptio und den Amazon-EKS-OSS-Engineers gepflegt.
Wenn Sie als Administrator einen Kubernetes-Cluster auf AWS betreiben, müssen Sie ohnehin AWS-IAM-Anmeldedaten für die Bereitstellung und Aktualisierung des Clusters verwalten. Durch die Verwendung von AWS IAM Authenticator for Kubernetes müssen Sie keine separaten Anmeldedaten für den Kubernetes-Zugriff mehr verwalten. AWS IAM bietet außerdem eine Reihe nützlicher Eigenschaften, wie z. B. einen Out-of-Band-Prüfpfad (über CloudTrail) und die Durchsetzung von 2FA/MFA.
Wenn Sie einen Kubernetes-Installer auf AWS entwickeln, kann AWS IAM Authenticator for Kubernetes Ihren Bootstrap-Prozess vereinfachen.
Sie müssen Ihre anfänglichen Admin-Anmeldedaten nicht mehr irgendwie sicher aus Ihrem neu installierten Cluster herausschmuggeln.
Stattdessen können Sie zum Zeitpunkt der Cluster-Bereitstellung eine dedizierte Rolle KubernetesAdmin erstellen und Authenticator so einrichten, dass Cluster-Administratoren sich anmelden können.
Angenommen, Sie haben einen Cluster, der in AWS läuft, und Sie möchten Unterstützung für AWS IAM Authenticator for Kubernetes hinzufügen, dann müssen Sie:
Zuerst müssen Sie eine oder mehrere IAM-Rollen erstellen, die Benutzern/Gruppen in Ihrem Kubernetes-Cluster zugeordnet werden. Der einfachste Weg, dies zu tun, ist die Anmeldung in der AWS-Konsole:
Dadurch wird eine IAM-Rolle ohne Berechtigungen erstellt, die von autorisierten Benutzern/Rollen in Ihrem Konto übernommen werden kann. Notieren Sie sich den Amazon Resource Name (ARN) Ihrer Rolle, den Sie unten benötigen.
Sie können dies auch in einem einzigen Schritt mit der AWS-CLI anstelle der AWS-Konsole tun:```sh
ACCOUNT_ID=$(aws sts get-caller-identity --output text --query 'Account')
POLICY=$(echo -n '{"Version":"2012-10-17","Statement":[{"Effect":"Allow","Principal":{"AWS":"arn:aws:iam::'; echo -n "$ACCOUNT_ID"; echo -n ':root"},"Action":"sts:AssumeRole","Condition":{}}]}')
aws iam create-role
--role-name KubernetesAdmin
--description "Kubernetes administrator role (for AWS IAM Authenticator for Kubernetes)."
--assume-role-policy-document "$POLICY"
--output text
--query 'Role.Arn'
Sie können diesen Schritt auch überspringen und Folgendes verwenden:
- Eine vorhandene Rolle (z. B. eine kontenübergreifende Zugriffsrolle).
- Einen IAM-Benutzer (siehe `mapUsers` unten).
- Eine EC2-Instanz oder eine föderierte Rolle (siehe `mapRoles` unten).
### 2. Den Server ausführen
Der Server soll auf jedem Ihrer Master-Knoten als DaemonSet mit Host-Netzwerk laufen, damit er einen Localhost-Port bereitstellen kann.
Ein Beispiel für eine ConfigMap- und DaemonSet-Konfiguration finden Sie in [`deploy/example.yaml`](https://github.com/kubernetes-sigs/aws-iam-authenticator/blob/master/deploy/example.yaml).
Bevor Sie sie anwenden, aktualisieren Sie diese Werte für Ihren Cluster:
- Ersetzen Sie die Platzhalter-IAM-ARNs (`arn:aws:iam::000000000000:...`) in `config.yaml`.
- Setzen Sie `clusterID` auf einen eindeutigen Wert für Ihren Cluster.
- Stellen Sie sicher, dass die DaemonSet-Planungsregeln mit den Labels/Taints Ihrer Control-Plane-Knoten übereinstimmen.
Dann stellen Sie es bereit:```sh
kubectl apply -f deploy/example.yaml
kubectl -n kube-system rollout status daemonset/aws-iam-authenticator
kubectl -n kube-system get pods -l k8s-app=aws-iam-authenticator
Sobald der Pod auf einem Control-Plane-Knoten läuft, erstellt der aws-iam-authenticator server die Webhook-kubeconfig auf dem Host unter /etc/kubernetes/aws-iam-authenticator/kubeconfig.yaml (oder dem über --generate-kubeconfig konfigurierten Pfad).
Wenn Sie ein automatisiertes Installationsprogramm erstellen, können Sie die Zertifikats-, Schlüssel- und Webhook-kubeconfig-Dateien mühelos mit aws-iam-authenticator init vorab generieren.
Dieser Befehl generiert Dateien und legt sie in den konfigurierten Ausgabeverzeichnissen ab.
Sie können dies auf jedem Master-Knoten ausführen, bevor Sie den API-Server starten. Sie können sie auch generieren, bevor Sie Master-Knoten bereitstellen, und sie in den entsprechenden Host-Pfaden installieren.
Wenn Sie keine Dateien vorab generieren, generiert aws-iam-authenticator server sie bei Bedarf.
Das funktioniert, erfordert jedoch, dass Sie Ihren Kubernetes-API-Server nach der Installation neu starten.
Die Kubernetes-API integriert AWS IAM Authenticator for Kubernetes über einen Token-Authentifizierungs-Webhook.
Wenn Sie aws-iam-authenticator server ausführen, generiert es eine Webhook-Konfigurationsdatei und speichert sie im Host-Dateisystem.
Sie müssen Ihrer API-Server-Konfiguration ein einziges zusätzliches Flag hinzufügen:```
--authentication-token-webhook-config-file=/etc/kubernetes/aws-iam-authenticator/kubeconfig.yaml
Auf vielen Clustern läuft der API-Server als statischer Pod.
Sie können das Flag zu `/etc/kubernetes/manifests/kube-apiserver.yaml` hinzufügen.
Stellen Sie sicher, dass das Host-Verzeichnis `/etc/kubernetes/aws-iam-authenticator/` in Ihren API-Server-Pod eingebunden ist.
Möglicherweise müssen Sie auch den kubelet-Daemon auf Ihrem Master-Knoten neu starten, um die aktualisierte Static-Pod-Definition zu übernehmen:```
systemctl restart kubelet.service
Das Standardverhalten des Servers besteht darin, Zuordnungen ausschließlich aus den Feldern mapUsers und mapRoles seiner Konfigurationsdatei zu beziehen. Siehe Vollständiges Konfigurationsformat unten für Details.
Mit dem Flag --backend-mode können Sie den Server so konfigurieren, dass er Zuordnungen aus zwei zusätzlichen Backends bezieht: einer EKS-artigen ConfigMap (--backend-mode=EKSConfigMap) oder IAMIdentityMapping-Custom-Resources (--backend-mode=CRD). Das Standard-Backend, die vom Server-Pod gemountete Server-Konfigurationsdatei, entspricht --backend-mode=MountedFile.