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/HEAD/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.
Sie können eine durch Kommas getrennte Liste dieser Backends übergeben, damit der Server sie der Reihe nach durchsucht. Beispielsweise wird der Server mit --backend-mode=EKSConfigMap,MountedFile zuerst die EKS-artige ConfigMap nach Zuordnungen durchsuchen und, falls er keine Zuordnung für die angegebene IAM-Rolle/den angegebenen IAM-Benutzer findet, die Server-Konfigurationsdatei. Wenn eine Zuordnung für dieselbe IAM-Rolle/denselben IAM-Benutzer in mehreren Backends existiert, verwendet der Server die Zuordnung aus dem Backend, das zuerst in der durch Kommas getrennten Liste erscheint. In diesem Beispiel wird, wenn eine Zuordnung in der EKS-ConfigMap gefunden wird, diese verwendet, unabhängig davon, ob eine doppelte oder widersprüchliche Zuordnung in der Server-Konfigurationsdatei existiert.
Beachten Sie, dass der Server bei der Einstellung eines einzelnen Backends nur aus diesem bezieht und die anderen ignoriert, selbst wenn sie existieren. Beispielsweise wird der Server mit --backend-mode=CRD nur aus IAMIdentityMappings beziehen und die gemountete Datei sowie die EKS-ConfigMap ignorieren.
MountedFileDies ist das Standard-Backend für Zuordnungen und für die meisten Benutzer ausreichend. Siehe Vollständiges Konfigurationsformat unten für Details.
CRD (Alpha)Dieses Backend modelliert jede IAM-Zuordnung als IAMIdentityMapping-Kubernetes-Custom-Resource. 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 zuerst das CRD-Manifest mit apply anwenden:```
kubectl apply -f deploy/iamidentitymapping.yaml
Mit den bereitgestellten CRDs können Sie dann Custom Resources erstellen, die Ihre
IAM-Identitäten modellieren. Siehe
[`./deploy/example-iamidentitymapping.yaml`](https://github.com/kubernetes-sigs/aws-iam-authenticator/blob/HEAD/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
EKSConfigMapDie kube-system/aws-auth ConfigMap im EKS-Stil dient als Backend. Die
ConfigMap muss exakt dasselbe Format wie in EKS-Clustern aufweisen:
https://docs.aws.amazon.com/eks/latest/userguide/add-user-role.html. Dies ist
nützlich, wenn Sie von/zu EKS migrieren und Ihre Mappings beibehalten möchten, oder
EKS zusätzlich zu anderen AWS-Clustern betreiben und in jedem Cluster dieselben
Mappings haben möchten.
DynamicFileEine lokale Datei, die durch cfg.dynamicfilepath angegeben wird, kann als Backend dienen. Der Dateiinhalt muss exakt dasselbe Format wie die EKSConfigMap aufweisen. Sobald sich dieser Dateiinhalt ändert, lädt der Authenticator ihn automatisch neu. Dies bietet mehr Flexibilität bei der Verwaltung der ARN-Mappings.
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 spielen.
Der aws-iam-authenticator kann ein reserviertes Präfix für den k8s-Benutzernamen unterstützen. Wenn das reservierte Präfix festgelegt 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.
Schließlich möchten Sie sich authentifizieren, sobald der Server eingerichtet ist.
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 Dokumentation zu den kubectl-Credential-Plugins):```yaml
users:
Das bedeutet, dass es sich bei der `kubeconfig` vollständig um öffentliche Daten handelt und sie von allen Authenticator-Benutzern geteilt werden kann.
Es kann sinnvoll sein, sie an einem vertrauenswürdigen öffentlichen Ort wie AWS S3 hochzuladen.
Stellen Sie sicher, dass die Binärdatei `aws-iam-authenticator` installiert ist.
Sie können sie mit `go install sigs.k8s.io/aws-iam-authenticator/cmd/aws-iam-authenticator@latest` installieren.
Um sich zu authentifizieren, führen Sie `kubectl --kubeconfig /path/to/kubeconfig" [...]` aus.
kubectl führt die Binärdatei `aws-iam-authenticator` mit den in Ihrer kubeconfig angegebenen Parametern per `exec` aus, die ein Token erzeugt und es an den Apiserver übergibt.
Das Token ist 15 Minuten gültig (der kürzeste Wert, den AWS zulässt) und kann mehrfach wiederverwendet werden.
Sie können beim Generieren des Tokens auch einen Sitzungsnamen angeben, indem Sie den Parameter `--session-name or -s` einfügen. Dieser Parameter kann nicht zusammen mit `--forward-session-name` verwendet werden.
Sie können `-r ROLE_ARN` auch weglassen, um das Token mit Ihren vorhandenen Anmeldeinformationen zu signieren, ohne eine dedizierte Rolle anzunehmen.
Dies ist nützlich, wenn Sie sich direkt als IAM-Benutzer authentifizieren möchten oder wenn Sie sich mithilfe einer EC2-Instanzrolle oder einer föderierten Rolle authentifizieren möchten.
## Verwendung mit Kops
Cluster, die von [Kops](https://github.com/kubernetes/kops) verwaltet werden, können für die Verwendung von Authenticator konfiguriert werden. Anweisungen zur Verwendung finden Sie in der [Kops-Dokumentation](https://kops.sigs.k8s.io/authentication/#aws-iam-authenticator).
## Wie funktioniert es?
Es funktioniert mithilfe des AWS-[`sts:GetCallerIdentity`](https://docs.aws.amazon.com/STS/latest/APIReference/API_GetCallerIdentity.html)-API-Endpunkts.
Dieser Endpunkt gibt Informationen über die AWS-IAM-Anmeldeinformationen zurück, die Sie für die Verbindung zu ihm verwenden.
#### Clientseite (`aws-iam-authenticator token`)
Wir verwenden 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 über den Kubernetes-API-Server und über eine Webhook-Konfiguration an den `/authenticate`-Endpunkt des Authenticator-Servers übergeben.
Der Authenticator-Server validiert alle Parameter der vorab signierten Anfrage, um sicherzustellen, dass nichts verdächtig aussieht.
Anschließend sendet er die Anfrage an den echten Server `https://sts.amazonaws.com`, der die HMAC-Signatur des Clients validiert und Informationen über den Benutzer zurückgibt.
Sobald der Server die AWS-Identität des Clients kennt, übersetzt er diese Identität mithilfe einer einfachen statischen Zuordnung in einen Kubernetes-Benutzer und in 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.
Insbesondere 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 zwar pro Cluster eindeutig sein, aber sie muss kein Geheimnis sein.
Einige gute Optionen sind:
- Eine zufällige ID, z. B. von `openssl rand 16 -hex`
- Der Domainname Ihres 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 und Verwenden von AWS-Profilen
Anmeldeinformationen können für die Verwendung mit `aws-iam-authenticator` über jede der verfügbaren Methoden des [AWS SDK for Go](https://docs.aws.amazon.com/sdk-for-go/v1/developer-guide/configuring-sdk.html#specifying-credentials) angegeben werden.
Dies umfasst die Angabe von AWS-Anmeldeinformationen über Umgebungsvariablen oder die Nutzung einer Credentials-Datei.
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 Anmeldeinformationen zu authentifizieren, die im Profil _dev_ angegeben sind, kann `AWS_PROFILE` exportiert oder explizit angegeben werden (z. B. `AWS_PROFILE=dev kubectl get all`). Wenn keine `AWS_PROFILE` gesetzt ist, wird das Profil _default_ verwendet.
Die `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 Anmeldeinformationen aus dem benannten Profil _dev_ von `aws-iam-authenticator` immer verwendet werden sollen, müsste Ihre Kubeconfig-Datei einen `env`-Schlüssel enthalten, der das Profil festlegt:```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"
Mit dieser Methode kann das entsprechende Profil implizit verwendet werden. Beachten Sie, dass alle Umgebungsvariablen, die als Teil des exec-Ablaufs gesetzt werden, Vorrang vor den bereits in Ihrer Umgebung gesetzten haben.
Föderierte AWS-Benutzer haben häufig ein „aussagekräftiges“ Attribut, das über die AWS-Konfiguration des Kontos auf ihre angenommene Rolle abgebildet wird, etwa eine E-Mail-Adresse.
Diese angenommenen Sitzungen bestehen aus einigen Teilen, 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 auf die neu angenommene Rolle übertragen.
Durch die Verwendung von aws-iam-authenticator token ... --forward-session-name wird das ursprüngliche Attribut caller-specified-role-name auf die neue angenommene STS-Sitzung abgebildet.
Dies kann hilfreich sein, um schnell zu versuchen, zuzuordnen, „wer Aktion X im K8-Cluster ausgeführt hat“.
Bitte beachten Sie: dies sollte nicht als endgültig betrachtet werden und muss über die role id (die konsistent bleibt) mit CloudTrail-Protokollen abgeglichen werden, da ein Benutzer dies clientseitig potenziell ändern könnte.
Es ist möglich, Anfragen an die Kubernetes-API von einem Client außerhalb des Clusters zu senden, sei es über die reine Kubernetes-REST-API oder über einen der sprachspezifischen Kubernetes-Clients (z. B. Python). Um dies zu tun, müssen Sie ein Bearer-Token erstellen, das mit der Anfrage an die API gesendet wird. Dieses Bearer-Token erfordert, dass Sie die Zeichenfolge k8s-aws-v1. mit einer base64-kodierten Zeichenfolge einer signierten HTTP-Anfrage an die STS GetCallerIdentity Query API anhängen. Dies wird dann im Authorization Header der Anfrage gesendet. Zu beachten ist allerdings, dass der IAM Authenticator die base64-Auffüllung explizit weglässt, um jegliche =-Zeichen zu vermeiden und so eine Zeichenfolge zu gewährleisten, die sicher in URLs verwendet werden kann. Im Folgenden finden Sie ein Beispiel in Python, wie dieses Token erstellt 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)
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 du überprüfen solltest:
Stelle sicher, dass deine AWS-Basisanmeldeinformationen in deiner Shell verfügbar sind (aws sts get-caller-identity kann bei der Fehlersuche helfen).
Stelle sicher, dass die Zielrolle deinem Quellkonto Zugriff erlaubt (in der Vertraensrichtlinie der Rolle).
Stelle sicher, dass dein Quellprinzipal (Benutzer/Rolle/Gruppe) eine IAM-Richtlinie hat, die sts:AssumeRole für die Zielrolle erlaubt.
Stelle sicher, dass du keine expliziten Deny-Richtlinien an deinen Benutzer, deine Gruppe oder in AWS Organizations angehängt hast, die sts:AssumeRole verhindern würden.
Versuche, den sts:AssumeRole-Aufruf im Policy Simulator zu simulieren.
Client und Server verwenden dasselbe Konfigurationsformat. Sie können exakt dieselbe Konfigurationsdatei verwenden, da in der Konfiguration keine Geheimnisse gespeichert sind.```yaml
clusterID: my-dev-cluster.example.com
aws-iam-authenticator tokendefaultRole: arn:aws:iam::000000000000:role/KubernetesAdmin
server:
port: 21362 # (default)
stateDir: /var/aws-iam-authenticator # (default)
path where a generated webhook kubeconfig will be stored.generateKubeconfig: /etc/kubernetes/aws-iam-authenticator.kubeconfig # (default)
ec2DescribeInstancesRoleARN: arn:aws:iam::000000000000:role/DescribeInstancesRole
scrubbedAccounts:
@ characters- characters.mapRoles:
mapUsers:
mapAccounts:
backendMode:
## Entwicklung
Siehe die Seite [Entwicklung](https://github.com/kubernetes-sigs/aws-iam-authenticator/blob/HEAD/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 Betreuer dieses Projekts über:
- [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-Verhaltenskodex](https://github.com/kubernetes-sigs/aws-iam-authenticator/blob/HEAD/code-of-conduct.md).