kubernetes-sigs/aws-iam-authenticatorEin Tool zur Authentifizierung an einem Kubernetes-Cluster mithilfe von AWS-IAM-Anmeldeinformationen.
# AWS IAM Authenticator für Kubernetes
Ein Tool zur Verwendung von AWS IAM-Anmeldeinformationen für die Authentifizierung an einem Kubernetes-Cluster.
Die ursprüngliche Arbeit an diesem Tool wurde von Heptio vorangetrieben. Das Projekt erhält Beiträge von mehreren Community-Engineers und wird derzeit von Heptio und Amazon EKS OSS Engineers gepflegt.
## Inhaltsverzeichnis
- [Warum möchte ich das?](#why-do-i-want-this)
- [Wie verwende ich es?](#how-do-i-use-it)
- [Kops-Nutzung](#kops-usage)
- [Wie funktioniert es?](#how-does-it-work)
- [Was ist eine Cluster-ID?](#what-is-a-cluster-id)
- [Angeben von Anmeldeinformationen & Verwenden von AWS-Profilen](#specifying-credentials--using-aws-profiles)
- [API-Autorisierung von außerhalb eines Clusters](#api-authorization-from-outside-a-cluster)
- [Fehlerbehebung](#troubleshooting)
- [Vollständiges Konfigurationsformat](#full-configuration-format)
- [Entwicklung](#development)
- [Community, Diskussion, Beiträge und Support](#community-discussion-contribution-and-support)
## Warum möchte ich das?
Wenn Sie als Administrator einen Kubernetes-Cluster auf AWS betreiben, müssen Sie bereits AWS IAM-Anmeldeinformationen verwalten, um den Cluster bereitzustellen und zu aktualisieren.
Durch die Verwendung von AWS IAM Authenticator für Kubernetes vermeiden Sie die Verwaltung separater Anmeldeinformationen für den Kubernetes-Zugriff.
AWS IAM bietet außerdem eine Reihe nützlicher Eigenschaften wie einen Out-of-Band-Audit-Trail (über CloudTrail) und die Durchsetzung von 2FA/MFA.
Wenn Sie einen Kubernetes-Installer auf AWS erstellen, kann AWS IAM Authenticator für Kubernetes Ihren Bootstrap-Prozess vereinfachen.
Sie müssen Ihre anfänglichen Admin-Anmeldeinformationen nicht auf irgendeine Weise sicher aus Ihrem neu installierten Cluster herausschmuggeln.
Stattdessen können Sie zum Zeitpunkt der Cluster-Bereitstellung eine dedizierte `KubernetesAdmin`-Rolle erstellen und Authenticator so einrichten, dass Cluster-Administrator-Anmeldungen zugelassen werden.
## Wie verwende ich es?
Angenommen, Sie haben einen Cluster, der auf AWS läuft, und möchten Unterstützung für AWS IAM Authenticator für Kubernetes hinzufügen, dann müssen Sie:
1. Eine IAM-Rolle erstellen, die Sie zur Identifizierung von Benutzern verwenden.
2. Den Authenticator-Server als DaemonSet ausführen.
3. Ihren API-Server so konfigurieren, dass er mit Authenticator kommuniziert.
4. kubectl so einrichten, dass es Authenticator-Tokens verwendet.
### 1. Eine IAM-Rolle erstellen
Zuerst müssen Sie eine oder mehrere IAM-Rollen erstellen, die Benutzern/Gruppen innerhalb Ihres Kubernetes-Clusters zugeordnet werden.
Der einfachste Weg, dies zu tun, ist sich in der AWS Console anzumelden:
- Wählen Sie die Option "Role for cross-account access" / "Provide access between AWS accounts you own".
- Fügen Sie Ihre AWS-Konto-ID-Nummer ein (verfügbar oben rechts in der Console).
- Ihre Rolle benötigt keine zusätzlich angehängten Richtlinien.
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 werden.
Sie können dies auch in einem einzigen Schritt mit der AWS CLI anstelle der AWS Console tun:
```sh
# get your account ID
ACCOUNT_ID=$(aws sts get-caller-identity --output text --query 'Account')
# define a role trust policy that opens the role to users in your account (limited by IAM policy)
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":{}}]}')
# create a role named KubernetesAdmin (will print the new role's ARN)
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 Cross-Account-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 ist dafür gedacht, auf jedem Ihrer Master-Knoten als DaemonSet mit Host-Netzwerk zu 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`.
- Legen Sie `clusterID` auf einen eindeutigen Wert für Ihren Cluster fest.
- Stellen Sie sicher, dass die Scheduling-Regeln des DaemonSets mit den Labels/Taints Ihrer Control-Plane-Knoten übereinstimmen.
Stellen Sie es dann 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 unter dem über `--generate-kubeconfig` konfigurierten Pfad).
#### (Optional) Zertifikat, Schlüssel und Kubeconfig vorab generieren
Wenn Sie einen automatisierten Installer erstellen, können Sie die Zertifikats-, Schlüssel- und Webhook-Kubeconfig-Dateien auch einfach mit `aws-iam-authenticator init` vorab generieren.
Dieser Befehl erzeugt Dateien und legt sie in den konfigurierten Ausgabeverzeichnissen ab.
Sie können dies auf jedem Master-Knoten vor dem Start des API-Servers ausführen.
Sie können sie auch vor der Bereitstellung der Master-Knoten generieren und sie in den entsprechenden Host-Pfaden installieren.
Wenn Sie keine Dateien vorab generieren, erzeugt `aws-iam-authenticator server` sie bei Bedarf.
Dies funktioniert, erfordert jedoch, dass Sie Ihren Kubernetes API-Server nach der Installation neu starten.
### 3. Konfigurieren Sie Ihren API-Server für die Kommunikation mit dem Server
Die Kubernetes API integriert sich über einen [Token-Authentifizierungs-Webhook](https://kubernetes.io/docs/reference/access-authn-authz/authentication/#webhook-token-authentication) in den AWS IAM Authenticator for Kubernetes.
Wenn Sie `aws-iam-authenticator server` ausführen, wird eine Webhook-Konfigurationsdatei erzeugt und im Host-Dateisystem gespeichert.
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 statisches 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 Ihr API-Server-Pod eingebunden ist.
Möglicherweise müssen Sie außerdem den kubelet-Daemon auf Ihrem Master-Node neu starten, damit die aktualisierte statische Pod-Definition übernommen wird:
```
systemctl restart kubelet.service
```
### 4. IAM-Rolle/Benutzer-zu-Kubernetes-Benutzer/Gruppen-Zuordnungen erstellen
Das Standardverhalten des Servers besteht darin, Zuordnungen ausschließlich aus den
Feldern `mapUsers` und `mapRoles` seiner Konfigurationsdatei zu beziehen. Siehe [Vollständiges
Konfigurationsformat](#full-configuration-format) 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 ConfigMap im EKS-Stil
(`--backend-mode=EKSConfigMap`) oder `IAMIdentityMapping`-Custom-Resources
(`--backend-mode=CRD`). Das Standard-Backend, die vom Server-Pod eingebundene
Server-Konfigurationsdatei, entspricht `--backend-mode=MountedFile`.
Sie können eine kommagetrennte Liste dieser Backends übergeben, damit der Server sie
in dieser Reihenfolge durchsucht. Mit `--backend-mode=EKSConfigMap,MountedFile` durchsucht der
Server beispielsweise die ConfigMap im EKS-Stil nach Zuordnungen und dann, wenn er
keine Zuordnung für die angegebene IAM-Rolle/den angegebenen Benutzer findet, die
Server-Konfigurationsdatei. Wenn eine Zuordnung für dieselbe IAM-Rolle/ denselben Benutzer in mehreren Backends existiert, verwendet der Server
die Zuordnung in dem Backend, das in der kommagetrennten Liste zuerst vorkommt.
In diesem Beispiel wird eine in der EKS-ConfigMap gefundene Zuordnung verwendet,
unabhängig davon, ob eine doppelte oder widersprüchliche Zuordnung in der Server-
Konfigurationsdatei existiert.
Beachten Sie, dass der Server bei Festlegung eines einzelnen Backends *nur* aus
diesem einen bezieht und die anderen ignoriert, selbst wenn sie existieren. Mit
`--backend-mode=CRD` bezieht der Server beispielsweise *nur* aus `IAMIdentityMappings`
und ignoriert die eingebundene Datei und die EKS-ConfigMap.
#### `MountedFile`
Dies ist das Standard-Backend für Zuordnungen und für die meisten Benutzer ausreichend. Siehe
[Vollständiges Konfigurationsformat](#full-configuration-format) unten für Details.
#### `CRD` (Alpha)
Dieses Backend modelliert jede IAM-Zuordnung als eine `IAMIdentityMapping`-[Kubernetes
Custom
Resource](https://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/custom-resources/).
Dieser Ansatz ermöglicht es Ihnen, Zuordnungen auf Kubernetes-native Weise mit
kubectl oder der API zu verwalten. Außerdem können Syntaxfehler (wie falsch ausgerichtetes YAML) leichter
erkannt werden und wirken sich nicht auf alle Zuordnungen aus.
Um eine `IAMIdentityMapping`-CRD einzurichten, müssen Sie zunächst das CRD-
Manifest mit `apply` anwenden:
```
kubectl apply -f deploy/iamidentitymapping.yaml
```
Mit den bereitgestellten CRDs können Sie anschließend Custom Resources erstellen, die Ihre
IAM-Identitäten modellieren. Siehe
[`./deploy/example-iamidentitymapping.yaml`](https://github.com/kubernetes-sigs/aws-iam-authenticator/blob/master/deploy/example-iamidentitymapping.yaml):
```
---
apiVersion: iamauthenticator.k8s.aws/v1alpha1
kind: IAMIdentityMapping
metadata:
name: kubernetes-admin
spec:
# Arn of the User or Role to be allowed to authenticate
arn: arn:aws:iam::XXXXXXXXXXXX:user/KubernetesAdmin
# Username that Kubernetes will see the user as, this is useful for setting
# up allowed specific permissions for different users
username: kubernetes-admin
# Groups to be attached to your users/roles. For example `system:masters` to
# create cluster admin, or `system:nodes`, `system:bootstrappers` for nodes to
# access the API server.
groups:
- system:masters
```
#### `EKSConfigMap`
Die EKS-artige `kube-system/aws-auth` ConfigMap dient als Backend. Die
ConfigMap muss exakt dasselbe Format wie in EKS-Clustern haben:
https://docs.aws.amazon.com/eks/latest/userguide/add-user-role.html. Dies ist
nützlich, wenn Sie von EKS migrieren oder zu EKS migrieren und Ihre Zuordnungen beibehalten möchten, oder wenn
Sie EKS zusätzlich zu einigen anderen AWS-Clustern betreiben und dieselben
Zuordnungen in jedem Cluster haben möchten.
#### `DynamicFile`
Eine lokale Datei, die durch cfg.dynamicfilepath angegeben wird, kann als Backend dienen. Der Dateiinhalt
muss exakt dasselbe Format wie die EKSConfigMap haben. Wann immer
sich dieser Dateiinhalt ändert, lädt der Authenticator ihn automatisch neu. Dies
bietet mehr Flexibilität bei der Verwaltung der ARN-Zuordnungen.
Unter https://github.com/kubernetes-sigs/aws-iam-authenticator/blob/master/hack/dev/authenticator_with_dynamicfile_mode.yaml
erfahren Sie, wie der DynamicFile-Modus konfiguriert wird.
Führen Sie `make e2e RUNNER=kind` aus, um mit einem kind-Cluster mit aktiviertem DynamicFile-Modus zu experimentieren.
### 5. So konfigurieren Sie reservedPrefixConfig für Kubernetes-Benutzernamen
Der aws-iam-authenticator kann ein reserviertes Präfix für k8s-Benutzernamen unterstützen. Wenn das reservierte Präfix
gesetzt ist, wird der Benutzername mit dem reservierten Präfix nicht authentifiziert, mit dem Fehler
"username must not begin with with the following prefixes:".
Unter https://github.com/kubernetes-sigs/aws-iam-authenticator/blob/master/hack/dev/authenticator_with_dynamicfile_mode.yaml
erfahren Sie, wie das reservierte Präfix konfiguriert wird.
### 6. Konfigurieren von kubectl für die Verwendung von Authentifizierungstokens, die vom AWS IAM Authenticator for Kubernetes bereitgestellt werden
Sobald der Server eingerichtet ist, möchten Sie sich schließlich authentifizieren.
Sie benötigen weiterhin eine `kubeconfig`, die die öffentlichen Daten zu Ihrem Cluster enthält (Cluster-CA-Zertifikat, Endpunktadresse).
Der Abschnitt `users` Ihrer Konfiguration sollte jedoch einen exec-Abschnitt enthalten ([siehe die kubectl-Dokumentation zu Credential-Plugins](https://kubernetes.io/docs/reference/access-authn-authz/authentication/#client-go-credential-plugins)):
```yaml
# [...]
users:
- name: kubernetes-admin
user:
exec:
apiVersion: client.authentication.k8s.io/v1beta1
command: aws-iam-authenticator
args:
- "token"
- "-i"
- "REPLACE_ME_WITH_YOUR_CLUSTER_ID"
- "-r"
- "REPLACE_ME_WITH_YOUR_ROLE_ARN"
# no client certificate/key needed here!
```
Das bedeutet, dass die `kubeconfig` vollständig öffentliche Daten sind und von allen Authenticator-Benutzern gemeinsam genutzt werden können.
Es kann sinnvoll sein, sie an einen vertrauenswürdigen öffentlichen Ort wie AWS S3 hochzuladen.
Stelle sicher, dass die Binärdatei `aws-iam-authenticator` installiert ist.
Du kannst sie mit `go install sigs.k8s.io/aws-iam-authenticator/cmd/aws-iam-authenticator@latest` installieren.
Zur Authentifizierung führe `kubectl --kubeconfig /path/to/kubeconfig" [...]` aus.
kubectl wird die Binärdatei `aws-iam-authenticator` mit den in deiner kubeconfig angegebenen Parametern per `exec` ausführen, wodurch ein Token generiert und an den Apiserver übergeben wird.
Das Token ist 15 Minuten lang gültig (der kürzeste von AWS erlaubte Wert) und kann mehrfach wiederverwendet werden.
Du kannst bei der Token-Generierung auch einen Sitzungsnamen angeben, indem du den Parameter `--session-name or -s` einfügst. Dieser Parameter kann nicht zusammen mit `--forward-session-name` verwendet werden.
Du kannst auch `-r ROLE_ARN` weglassen, um das Token mit deinen vorhandenen Anmeldeinformationen zu signieren, ohne eine dedizierte Rolle anzunehmen.
Dies ist nützlich, wenn du dich direkt als IAM-Benutzer authentifizieren möchtest oder wenn du dich über eine EC2-Instanzrolle oder eine föderierte Rolle authentifizieren möchtest.
## Kops-Nutzung
Von [Kops](https://github.com/kubernetes/kops) verwaltete Cluster können so konfiguriert werden, dass sie Authenticator verwenden. Nutzungsanweisungen findest du in der [Kops-Dokumentation](https://kops.sigs.k8s.io/authentication/#aws-iam-authenticator).
## Wie funktioniert es?
Es funktioniert über den AWS-API-Endpunkt [`sts:GetCallerIdentity`](https://docs.aws.amazon.com/STS/latest/APIReference/API_GetCallerIdentity.html).
Dieser Endpunkt gibt Informationen über die AWS-IAM-Anmeldeinformationen zurück, die du für die Verbindung zu ihm verwendest.
#### Clientseite (`aws-iam-authenticator token`)
Wir nutzen diese API auf eine etwas ungewöhnliche Weise, indem der Authenticator-Client eine Anfrage an den Endpunkt generiert und vorab signiert.
Wir serialisieren diese Anfrage in ein Token, das das Kubernetes-Authentifizierungssystem durchlaufen kann.
#### Serverseite (`aws-iam-authenticator server`)
Das Token wird durch den Kubernetes-API-Server und über eine Webhook-Konfiguration an den `/authenticate`-Endpunkt des Authenticator-Servers weitergegeben.
Der Authenticator-Server validiert alle Parameter der vorab signierten Anfrage, um sicherzustellen, dass nichts merkwürdig aussieht.
Anschließend übermittelt er die Anfrage an den echten `https://sts.amazonaws.com`-Server, der die HMAC-Signatur des Clients validiert und Informationen über den Benutzer zurückgibt.
Da der Server nun die AWS-Identität des Clients kennt, übersetzt er diese Identität über ein einfaches statisches Mapping in einen Kubernetes-Benutzer und -Gruppen.
Dieser Mechanismus ist mit einigen Änderungen von [Vault](https://www.vaultproject.io/docs/auth/aws.html#iam-auth-method) übernommen.
## Was ist eine Cluster-ID?
Die Authenticator-Cluster-ID ist eine pro Cluster eindeutige Kennung, die bestimmte Replay-Angriffe verhindert.
Konkret verhindert sie, dass ein Authenticator-Server (z. B. in einer Entwicklungsumgebung) das Token eines Clients verwendet, um sich bei einem anderen Authenticator-Server in einem anderen Cluster zu authentifizieren.
Die Cluster-ID muss pro Cluster eindeutig sein, aber sie muss kein Geheimnis sein.
Einige gute Möglichkeiten sind:
- Eine zufällige ID, etwa aus `openssl rand 16 -hex`
- Der Domänenname deines Kubernetes-API-Servers
Die [Vault-Dokumentation](https://www.vaultproject.io/docs/auth/aws.html#iam-auth-method) erklärt diesen Angriff ebenfalls (siehe `X-Vault-AWS-IAM-Server-ID`).
## Angeben von Anmeldeinformationen & Verwenden von AWS-Profilen
Anmeldeinformationen können für die Verwendung mit `aws-iam-authenticator` über jede der Methoden angegeben werden, die im
[AWS SDK for Go](https://docs.aws.amazon.com/sdk-for-go/v1/developer-guide/configuring-sdk.html#specifying-credentials) verfügbar sind.
Dazu gehört das Angeben von AWS-Anmeldeinformationen über Umgebungsvariablen oder die Verwendung einer Anmeldeinformationsdatei.
AWS-[benannte Profile](https://docs.aws.amazon.com/cli/latest/userguide/cli-multiple-profiles.html) werden von `aws-iam-authenticator`
über die Umgebungsvariable `AWS_PROFILE` unterstützt. Um sich beispielsweise mit den im Profil _dev_ angegebenen Anmeldeinformationen zu authentifizieren, kann `AWS_PROFILE`
exportiert oder explizit angegeben werden (z. B. `AWS_PROFILE=dev kubectl get all`). Wenn kein `AWS_PROFILE` gesetzt ist, wird das Profil _default_ verwendet.
Das `AWS_PROFILE` kann auch direkt in der kubeconfig-Datei
[als Teil des `exec`-Ablaufs](https://kubernetes.io/docs/reference/access-authn-authz/authentication/#configuration) angegeben werden. Um beispielsweise festzulegen,
dass `aws-iam-authenticator` immer die Anmeldeinformationen aus dem benannten Profil _dev_ verwenden soll, würde Ihre kubeconfig einen `env`-Schlüssel
enthalten, der das Profil setzt:
```yaml
apiVersion: v1
clusters:
- cluster:
server: ${server}
certificate-authority-data: ${cert}
name: kubernetes
contexts:
- context:
cluster: kubernetes
user: aws
name: aws
current-context: aws
kind: Config
preferences: {}
users:
- name: aws
user:
exec:
apiVersion: client.authentication.k8s.io/v1beta1
command: aws-iam-authenticator
env:
- name: "AWS_PROFILE"
value: "dev"
args:
- "token"
- "-i"
- "mycluster"
```
Diese Methode ermöglicht die implizite Verwendung des passenden Profils. Beachten Sie, dass alle Umgebungsvariablen, die im Rahmen des `exec`-Ablaufs gesetzt werden, Vorrang vor den bereits in Ihrer Umgebung gesetzten Werten haben.
#### Hinweis für föderierte Benutzer:
Föderierte AWS-Benutzer haben häufig ein „aussagekräftiges" Attribut, das über die AWS-Konfiguration des Kontos ihrer angenommenen Rolle zugeordnet wird, etwa eine E-Mail-Adresse.
Diese angenommenen Sitzungen bestehen aus [mehreren Teilen](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_variables.html#principaltable), der `role id`
und dem `caller-specified-role-name`. Standardmäßig wird, wenn ein föderierter Benutzer die Option `--role` von `aws-iam-authenticator` verwendet, um eine neue Rolle anzunehmen, der
`caller-specified-role-name` in ein zufälliges Token umgewandelt, und die `role id` wird an die neu angenommene Rolle weitergegeben.
Die Verwendung von `aws-iam-authenticator token ... --forward-session-name` ordnet das ursprüngliche `caller-specified-role-name`-Attribut der neuen von STS angenommenen Sitzung zu.
Dies kann hilfreich sein, um schnell zu versuchen, „wer die Aktion X auf dem K8-Cluster ausgeführt hat" zuzuordnen.
Bitte beachten Sie, **dies sollte nicht als definitiv angesehen werden** und muss über die `role id` (die konsistent bleibt) mit CloudTrail-Protokollen abgeglichen werden,
da ein Benutzer dies potenziell auf der Clientseite ändern könnte.
## API-Autorisierung von außerhalb eines Clusters
Es ist möglich, Anfragen an die Kubernetes-API von einem Client außerhalb des Clusters zu stellen, sei es über die
reine Kubernetes-REST-API oder über einen der sprachspezifischen Kubernetes-Clients
(z. B. [Python](https://github.com/kubernetes-client/python)). Dazu müssen Sie ein Bearer-Token erstellen, das
mit der Anfrage an die API übermittelt wird. Dieses Bearer-Token erfordert, dass Sie die Zeichenkette `k8s-aws-v1.` mit einer
base64-kodierten Zeichenkette einer signierten HTTP-Anfrage an die STS-GetCallerIdentity-Query-API anhängen. Diese wird dann im
`Authorization`-Header der Anfrage gesendet. Zu beachten ist jedoch, dass der IAM Authenticator explizit
base64-Padding weglässt, um jegliche `=`-Zeichen zu vermeiden und so eine Zeichenkette zu garantieren, die sicher in URLs verwendet werden kann. Nachfolgend ein Beispiel in
Python, wie dieses Token konstruiert würde:
```python
import base64
import boto3
import re
from botocore.signers import RequestSigner
def get_bearer_token(cluster_id, region):
STS_TOKEN_EXPIRES_IN = 60
session = boto3.session.Session()
client = session.client('sts', region_name=region)
service_id = client.meta.service_model.service_id
signer = RequestSigner(
service_id,
region,
'sts',
'v4',
session.get_credentials(),
session.events
)
params = {
'method': 'GET',
'url': 'https://sts.{}.amazonaws.com/?Action=GetCallerIdentity&Version=2011-06-15'.format(region),
'body': {},
'headers': {
'x-k8s-aws-id': cluster_id
},
'context': {}
}
signed_url = signer.generate_presigned_url(
params,
region_name=region,
expires_in=STS_TOKEN_EXPIRES_IN,
operation_name=''
)
base64_url = base64.urlsafe_b64encode(signed_url.encode('utf-8')).decode('utf-8')
# remove any base64 encoding padding:
return 'k8s-aws-v1.' + re.sub(r'=*', '', base64_url)
# If making a HTTP request you would create the authorization headers as follows:
headers = {'Authorization': 'Bearer ' + get_bearer_token('my_cluster', 'us-east-1')}
```
## Fehlerbehebung
Wenn Ihr Client mit einem Fehler wie `could not get token: AccessDenied [...]` fehlschlägt, können Sie versuchen, die Rolle direkt mit der AWS CLI zu übernehmen:
```sh
# AWS CLI version of `aws-iam-authenticator token -r arn:aws:iam::ACCOUNT:role/ROLE`:
$ aws sts assume-role --role-arn arn:aws:iam::ACCOUNT:role/ROLE --role-session-name test
```
Wenn das fehlschlägt, gibt es einige mögliche Probleme, die überprüft werden sollten:
- Stellen Sie sicher, dass Ihre Basis-AWS-Anmeldeinformationen in Ihrer Shell verfügbar sind (`aws sts get-caller-identity` kann bei der Fehlersuche helfen).
- Stellen Sie sicher, dass die Zielrolle den Zugriff Ihres Quellkontos erlaubt (in der Vertrauensrichtlinie der Rolle).
- Stellen Sie sicher, dass Ihr Quellprinzipal (Benutzer/Rolle/Gruppe) über eine IAM-Richtlinie verfügt, die `sts:AssumeRole` für die Zielrolle erlaubt.
- Stellen Sie sicher, dass keine expliziten Deny-Richtlinien an Ihren Benutzer, Ihre Gruppe oder in AWS Organizations angehängt sind, die den `sts:AssumeRole` verhindern würden.
- Versuchen Sie, den `sts:AssumeRole`-Aufruf im [Policy Simulator](https://policysim.aws.amazon.com/home/index.jsp) zu simulieren.
## Vollständiges Konfigurationsformat
Client und Server haben dasselbe Konfigurationsformat.
Sie können dieselbe exakte Konfigurationsdatei gemeinsam nutzen, da in der Konfiguration keine Geheimnisse gespeichert werden.
```yaml
# a unique-per-cluster identifier to prevent replay attacks (see above)
clusterID: my-dev-cluster.example.com
# default IAM role to assume for `aws-iam-authenticator token`
defaultRole: arn:aws:iam::000000000000:role/KubernetesAdmin
# server listener configuration
server:
# localhost port where the server will serve the /authenticate endpoint
port: 21362 # (default)
# state directory for generated TLS certificate and private keys
stateDir: /var/aws-iam-authenticator # (default)
# output `path` where a generated webhook kubeconfig will be stored.
generateKubeconfig: /etc/kubernetes/aws-iam-authenticator.kubeconfig # (default)
# role to assume before querying EC2 API in order to discover metadata like EC2 private DNS Name
ec2DescribeInstancesRoleARN: arn:aws:iam::000000000000:role/DescribeInstancesRole
# AWS region for EC2 DescribeInstances and token verification. If unset, the region is looked
# up from the EC2 Instance Metadata Service (IMDS) at startup. Also settable with `--region`.
region: us-west-2
# AWS Account IDs to scrub from server logs. (Defaults to empty list)
scrubbedAccounts:
- "111122223333"
- "222233334444"
# each mapRoles entry maps an IAM role to a username and set of groups
# Each username and group can optionally contain template parameters:
# 1) "{{AccountID}}" is the 12 digit AWS ID.
# 2) "{{SessionName}}" is the role session name, with `@` characters
# transliterated to `-` characters.
# 3) "{{SessionNameRaw}}" is the role session name, without character
# transliteration (available in version >= 0.5).
mapRoles:
# statically map arn:aws:iam::000000000000:role/KubernetesAdmin to cluster admin
- rolearn: arn:aws:iam::000000000000:role/KubernetesAdmin
username: kubernetes-admin
groups:
- system:masters
# map EC2 instances in my "KubernetesNode" role to users like
# "aws:000000000000:instance:i-0123456789abcdef0". Only use this if you
# trust that the role can only be assumed by EC2 instances. If an IAM user
# can assume this role directly (with sts:AssumeRole) they can control
# SessionName.
- rolearn: arn:aws:iam::000000000000:role/KubernetesNode
username: aws:{{AccountID}}:instance:{{SessionName}}
groups:
- system:bootstrappers
- aws:instances
# map nodes that should conform to the username "system:node:<private-DNS>". This
# requires the authenticator to query the EC2 API in order to discover the private
# DNS of the EC2 instance originating the authentication request.
# {{EC2PrivateDNSName}} is resolved by using the session name as an EC2 instance
# ID and calling ec2:DescribeInstances. Note that if this role is assumed directly
# by an IAM User (not via federation), the user can set the session name to any
# instance ID, resolving another instance's private DNS and impersonating that node.
# Optionally, you may specify a role that should be assumed before querying the EC2 API with the
# key "server.ec2DescribeInstancesRoleARN" (see above).
- rolearn: arn:aws:iam::000000000000:role/KubernetesNode
username: system:node:{{EC2PrivateDNSName}}
groups:
- system:nodes
- system:bootstrappers
# map federated users in my "KubernetesAdmin" role to users like
# "admin:alice-example.com". The SessionName is an arbitrary role name
# like an e-mail address passed by the identity provider. Note that if this
# role is assumed directly by an IAM User (not via federation), the user
# can control the SessionName.
- rolearn: arn:aws:iam::000000000000:role/KubernetesAdmin
username: admin:{{SessionName}}
groups:
- system:masters
# map federated users in my "KubernetesOtherAdmin" role to users like
# "alice-example.com". The SessionName is an arbitrary role name
# like an e-mail address passed by the identity provider. Note that if this
# role is assumed directly by an IAM User (not via federation), the user
# can control the SessionName. Note that the "{{SessionName}}" macro is
# quoted to ensure it is properly parsed as a string.
- rolearn: arn:aws:iam::000000000000:role/KubernetesOtherAdmin
username: "{{SessionName}}"
groups:
- system:masters
# If unalterable identification of an IAM User is desirable, you can map against
# AccessKeyID.
- rolearn: arn:aws:iam::000000000000:role/KubernetesOtherAdmin
username: "admin:{{AccessKeyID}}"
groups:
- system:masters
# each mapUsers entry maps an IAM user to a static username and set of groups
mapUsers:
# map user IAM user Alice in 000000000000 to user "alice" in group "system:masters"
- userarn: arn:aws:iam::000000000000:user/Alice
username: alice
groups:
- system:masters
# automatically map IAM ARN from these accounts to username.
# NOTE: Always use quotes to avoid the account numbers being recognized as numbers
# instead of strings by the yaml parser.
mapAccounts:
- "012345678901"
- "456789012345"
# source mappings from this file (mapUsers, mapRoles, & mapAccounts)
backendMode:
- MountedFile
```
## Entwicklung
Siehe die Seite [Entwicklung](https://github.com/kubernetes-sigs/aws-iam-authenticator/blob/master/docs/development.md).
## Community, Diskussion, Beiträge und Support
Erfahren Sie auf der [Community-Seite](http://kubernetes.io/community/), wie Sie sich in der Kubernetes-Community engagieren können.
Sie erreichen die Maintainer dieses Projekts unter:
- [Slack](https://kubernetes.slack.com/messages/sig-aws)
- [Mailingliste](https://groups.google.com/forum/#!forum/kubernetes-sig-aws)
### Verhaltenskodex
Die Teilnahme an der Kubernetes-Community unterliegt dem [Kubernetes Code of Conduct](https://github.com/kubernetes-sigs/aws-iam-authenticator/blob/master/code-of-conduct.md).