AWS CLI
Last updated
Was this helpful?
Last updated
Was this helpful?
Mit der AWS CLI kann man all die Dinge machen, die man auch Ăźber die AWS Console per UI tun kann.
Nach der Installation des Binary (Ăźbrigens ist die CLI in programmiert und hat deshalb auch perfekte Python Libraries via ) muss die Shell noch mit Credentials bestĂźckt werden.
FĂźr den Zugriff benĂśtigt man Security-Credentials (Access Keys = Tokens), die man beispielsweise manuell per AWS Console (Web-UI) manuell erzeugen kann. Ein aws configure fĂźhrt interaktiv durch die Konfiguration - hier werden die Credentials abgefragt und am Ende eine Datei ~/.aws/config geschrieben => damit ist die Konfiguration persistent. Darin lassen sich verschiedene Profile einrichten (siehe unten), um in verschiedenen Kontexten (mit verschiedenen Rollen oder als unterschiedliche User) zu arbeiten.
ABER ACHTUNG: Die Credentials sind in Plaintext abgespeichert ... groĂe Gefahr, daĂ sie gestohlen oder sogar von Dir selbst versehentlich verĂśffentlicht werden (z. B. bei einem
git push). Aus diesem Grund empfiehlt sich die Verwendung vonaws-vault, das man auf encrypted Credentials in einem Password-Store (z. B.passoder den MacOS-Keystore umbiegen kann - siehe unten).
Ich habe die Command-Line Tools von AWS Ăźber pip (Python Paket Manager) installiert wie :
Ich hatte den
pipschon installiert -
So bin ich an die aktuelle Version 1.16.96 gekommen (Ăźber diesen Weg werden auch Updates installiert) - auf diese Weise kann man auch ein Update machen.
Die Option
--usersorgte dafĂźr, daĂ die Installation nur in meinem Home-Verzeichnis erfolgte (~/.local/bin/aws). Ich habe dieses Python Script in meinen$PATHgelegt, so daĂ ich es von Ăźberall aufrufen kann.
ACHTUNG: nicht zu empfehlen - alte Version!!!
Ăber meinen Ubuntu Package-Manager (auf Ubuntu 18.04 LTS)
habe ich nur eine awscli-1.14.xxx bekommen.
Die AWS Console (WebUI) bietet in manchen Regionen die CloudShell an, so daà man gar kein lokales Terminal braucht, um die AWS zu nutzen. Man hat dann auch gleicht die entsprechende Rolle und Region, die man beim interaktiven Login ausgewählt hat und kann damit direkt Kommandos ausfßhren, ohne sich um eine Konfiguration via aws configure kßmmern zu mßssen.
Man hat damit auch gleich auto-Completion fĂźr aws-CLI zur VerfĂźgung. Auf andere Tools wie Command-History und Tools, die man normalerweise in der eigenen Shell installiert hat, muss man natĂźrlich verzichten (aber die CloudShell bringt schon viele GNU-Tools mit ... awk, jq).
AnschlieĂend muĂ man die Credentials ~/.aws/credentials noch einbinden.
ACHTUNG: diese Credentials liegen im Plaintext vor!!!
Als erfahrener AWSler kann man die dabei angelegten Dateien in
~/.awsaber auch manuell anlegen.
AnschlieĂend sollte man Zugriff haben und folgenden Befehl ausfĂźhren kĂśnnen:
Hierzu legt man eine Rolle an, die einem User (dessen Token man später verwenden wird) entsprechende Berechtigung erteilt.
Per
kann man sich einen Token erzeugen (AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY), der die entsprechenden AWS-Kommandos (gemäà Berechtigung) ausfßhren kann.
Mit diesem Tool lassen sich AWS Credentials (AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY) sicher speichern (es kann nicht mehr passieren, dass man unerwĂźnscht seine .aws/credentials Datei nach GitHub pusht - das wird GANZ schnell entdeckt und ausgenutzt ... ich habe das schon mal miterlebt) und im aws-CLI in dieser Art und Weise verwenden:
aws-vault exec mobi3006 -- aws s3 ls
Am Kommando kann man schon erkennen, daà aws-vault ein Decorator ist, um mit der (frei-wählbaren) Profil-ID (hier: mobi3006) ein aws Kommando auszufßhren.
Diese Profil-ID (hier:
mobi3006) muss mit der AWS-Konfiguration~/.aws/configmatchen!!!
Der Decorator holt die Credentials (AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY) zur Profil-ID aus dem aws-vault Passwort-Store, erzeugt Ăźber den AWS-Tokenstore einen kurzlebigen Token und stellt diese Informationen als Umgebungsvariablen im AusfĂźhrungskontext des Kommandos bereit. Das kann man sehr schĂśn sehen, wenn man folgenden Befehl ausfĂźhrt:
aws-vault exec mobi3006 -- env | grep AWS
Hier wird man erkennen, daĂ folgende Umgebungsvariablen gesetzt sind:
AWS_ACCESS_KEY_ID
AWS_SECRET_ACCESS_KEY
AWS_SECURITY_TOKEN
AWS_SESSION_EXPIRATION
AWS_SESSION_TOKEN
AWS_VAULT
Doch wie kommen die Credentials in den aws-vault?
man muss sie einmalig per aws-vault add mobi3006 hinzufĂźgen ... im interaktiven Modus werden dann AWS_ACCESS_KEY_ID und AWS_SECRET_ACCESS_KEY abgefragt und in aws-vault-Passwortstore gespeichert
anschlieĂend kann man die Einträge per aws-vault list sichtbar machen
Den Content der Einträge kann man allerdings nicht per aws-vault sehen - warum?
aws-vault stellt nur den Wrapper bereit, um kurzlebige Tokens zu erzeugen
die Speicherung der Basis-Credentials erfolgt in einem separaten Backend (sog. Vaulting Backend)
unter Linux ist das Default Backend Gnome-Keyring oder KWallet
unter MacOS ist es Keychain
Da das Vaulting-Backend allerdings auch mit einem Passwort geschĂźtzt ist, das aws-vault nicht kennt, muss man es interaktiv eingeben. Deshalb poppt gelegentlich auch ein Fenster hoch und man muss ein Passwort eingeben. Es handelt sich dabei um das Keyring-Passwort.
pass ist besonders interessant auf reinen Linux-Headless Systemen, da der Core ein reines CLI-Tool ist ... Gnome/KWallet kÜnnte man aufgrund der fehlenden UI nicht verwenden. Bei der Verwendung von pass muà man dem Kommando allerdings noch den Parameter --backend=pass mitgeben (z. B. aws-vault --backend=pass exec mobi3006 -- aws s3 ls) oder man setzt die Umgebungsvariable export AWS_VAULT_BACKEND=pass, dann kann man sich den zusätzlichen Parameter sparen.
aws-vaultist in der Funktion vergleichbar mit einem ssh-Agent. Dieser ist allerdings tief in densshWorkflow integriert und somit unsichtbar ... wohingegenaws-vaultdem Kommando vorangestellt werden muss.
Dieser Command-Line Password Store verwendet GPG, um die Credentials sicher in einer Datei ~/.password-store abzuspeichern, die man beispielsweise auch in einem Git Repository zur VerfĂźgung stellen kann.
pass ist nicht das Default Backend von aws-vault und dementsprechend muss es im Kommando aws-vault --backend=pass exec mobi3006 -- aws s3 ls angegeben werden. Durch Setzen der Umgebungsvariable export AWS_VAULT_BACKEND=pass und export AWS_ASSUME_ROLE_TTL=12h kann man den Zugriff komfortabler gestalten.
Die Kommandos hängen davon ab, ob man die Python Installation verwendet hat oder die Package-Installation - ):
Hier wird man interaktiv nach den Crentials (AWS Access Key ID, AWS Secret Access Key, Default region). Aus den Angaben werden die Dateien ~/.aws/credentials und ~/.aws/config erzeugt. Diese Credentials kann man sich in der AWS Console (Web UI) im Bereich "IAM - Access Management - Users - - Security Credentials - Access Keys" erzeugen lassen. Kein Problem, wenn man ihn mal vergiĂt - einfach neu erzeugen und in ~/.aws/credentials eintragen. Hat man mehrere AWS Accounts, dann kann man die im konfigurieren
Es kann sinnvoll sein, unterschiedeliche Konfigurationen (= Profile) zu verwenden ... je nach Nutzungskontext. Das läĂt sich ganz einfach per aws configure --profile foo-bar umsetzen oder durch manuelle Editierung der ~/.aws/config Datei. Das Default-Profile kann per export AWS_PROFILE=foo-bar gesetzt werden oder man es fĂźr ein einziges Kommando: aws iam get-user --user-name your_username@example.com --profile mySecondAccount.
AWS Roles verwendet man, wenn man seine Credentials nicht auf der Instanz hinterlegen mĂśchte. Auf diese Weise kann man eine Role mit Permissions auf ein S3-Bucket anlegen und einer EC2-Instanz zuweisen. Dadurch hat die EC2-Instanz automatisch Zugriff auf das S3. Bucket. Mit läĂt sich das auch schĂśn automatosieren.
Der Python-Aws-CLI-Installer bringt auch gleich die passende mit. Unter ~/.local/bin/aws_completer. sind die notwendigen Quellen abgelegt. Durch hinzufĂźgen folgender Zeilen zur ~/.zshrc wird die AWS-Auto-Completion automatisch aktiviert:
Will man verschiedene Konfigurationen verwenden,
Viele Organisationen verwenden mehrere AWS Accounts. Der wird verwendet, um Token zu erzeugen, die kurzfristige Zugriffe auf Ressourcen zu gewähren (innerhalb eines Accounts aber auch Account-ßbergreifend).
Mit dem lassen sich kurzlebige Tokens (AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY) mit eingeschränken Permissions per Code (und damit automatisierbar) ausstellen.
Das ist ganz ähnlich zu .
man kann aber auch verwenden