IAM User vs. IAM Role: Wann welches Konzept verwenden und warum EC2-Anwendungen immer Rollen nutzen sollten

Wer zum ersten Mal eine Anwendung auf einer EC2-Instanz deployt und dabei auf S3 zugreifen muss, landet schnell bei der gleichen Frage: Lege ich einen IAM-User an, generiere Access Keys und packe sie in die Konfiguration — oder gibt es einen besseren Weg? Die Antwort ist eindeutig, aber das Warum dahinter ist entscheidend, um spätere Sicherheitsprobleme zu vermeiden.

TL;DR: IAM User vs. IAM Role auf einen Blick

KriteriumIAM UserIAM Role
IdentitätstypLanglebige Identität für eine Person oder einen ProzessTemporäre Identität, die von einem Prinzipal übernommen wird
CredentialsStatische Access Keys (langlebig)Temporäre STS-Credentials (kurzlebig)
Typischer EinsatzMenschliche Konsolen-/CLI-Zugriffe, Legacy-SystemeEC2, Lambda, ECS, Cross-Account-Zugriffe, Federated Identity
RotationManuell erforderlichAutomatisch durch STS
Empfehlung für EC2 → S3Nicht empfohlenPflicht (Instance Profile)

Wie IAM User und IAM Roles grundlegend funktionieren

Ein IAM User ist eine permanente Identität innerhalb eines AWS-Accounts. Er besitzt eigene, langlebige Credentials: entweder ein Passwort für die Konsole oder Access Key ID plus Secret Access Key für programmatischen Zugriff. Diese Credentials existieren so lange, bis sie manuell gelöscht oder deaktiviert werden.

Eine IAM Role hingegen ist eine Identität ohne eigene permanente Credentials. Sie definiert eine Menge von Berechtigungen und eine Trust Policy, die festlegt, wer diese Rolle übernehmen darf. Wenn ein Prinzipal — etwa eine EC2-Instanz, ein Lambda-Dienst oder ein Nutzer aus einem anderen Account — die Rolle übernimmt, stellt AWS Security Token Service (STS) temporäre Credentials aus: Access Key ID, Secret Access Key und ein Session Token. Diese Credentials laufen nach einer konfigurierbaren Dauer ab und werden automatisch rotiert.

graph LR subgraph UserFlow ["IAM User Flow (nicht empfohlen für EC2)"] U["IAM User"] -->|"statische Access Keys"| API1["AWS API"] API1 --> S3A["S3 Bucket"] end subgraph RoleFlow ["IAM Role Flow (empfohlen)"] EC2["EC2 Instanz"] -->|"AssumeRole via IMDS"| STS["AWS STS"] STS -->|"temporäre Credentials"| SDK["AWS SDK / CLI"] SDK -->|"signierter Request"| S3B["S3 Bucket"] end style UserFlow fill:#fff3cd,stroke:#ffc107 style RoleFlow fill:#d4edda,stroke:#28a745
  1. IAM User-Flow: Der User besitzt statische Access Keys, die direkt für API-Calls verwendet werden. Rotation ist manuell und fehleranfällig.
  2. IAM Role-Flow: Die EC2-Instanz übernimmt eine Rolle über das Instance Metadata Service (IMDS). STS stellt temporäre Credentials aus, die der AWS SDK automatisch abruft und rotiert.
  3. Trust Policy: Die Rolle erlaubt explizit dem EC2-Dienst (ec2.amazonaws.com), sie zu übernehmen — kein anderer Prinzipal kann dies ohne explizite Erlaubnis.

IAM Role für EC2: Das Instance Profile-Konzept

Eine IAM Role wird einer EC2-Instanz nicht direkt zugewiesen. Der Mechanismus dazwischen heißt Instance Profile — ein Container, der genau eine IAM Role enthält und an eine EC2-Instanz gebunden werden kann. In der Konsole wird das Instance Profile beim Erstellen einer Rolle für EC2 automatisch mit gleichem Namen angelegt. Über die CLI muss es explizit erstellt und mit der Rolle verknüpft werden.

Sobald das Instance Profile zugewiesen ist, stellt IMDS unter dem Endpunkt http://169.254.169.254/latest/meta-data/iam/security-credentials/<role-name> die temporären Credentials bereit. Alle AWS SDKs und die CLI greifen automatisch auf diesen Endpunkt zurück — ohne dass eine einzige Zeile Credential-Konfiguration im Code notwendig ist.

sequenceDiagram participant App as Anwendung (EC2) participant IMDS as IMDS (169.254.169.254) participant STS as AWS STS participant S3 as Amazon S3 App->>IMDS: GET /latest/meta-data/iam/security-credentials/EC2S3AccessRole IMDS->>STS: AssumeRole (intern) STS-->>IMDS: Temporäre Credentials + Ablaufzeit IMDS-->>App: AccessKeyId, SecretAccessKey, SessionToken App->>S3: S3 API Call (signiert mit temp. Credentials) S3-->>App: Response Note over App,IMDS: SDK rotiert Credentials automatisch vor Ablauf
  1. Instance Profile: Bindeglied zwischen EC2-Instanz und IAM Role. Enthält genau eine Rolle.
  2. IMDS-Abruf: Das AWS SDK ruft automatisch temporäre Credentials vom Instance Metadata Service ab.
  3. STS-Rotation: Credentials laufen ab und werden vor Ablauf automatisch erneuert — ohne Anwendungseingriff.
  4. S3 API Call: Der signierte Request erreicht S3 mit den temporären Credentials der Rolle.

IAM Role für EC2 zu S3 einrichten: Schritt-für-Schritt

Schritt 1: IAM Role mit Trust Policy für EC2 erstellen

Zuerst wird die Rolle erstellt. Die Trust Policy legt fest, dass ausschließlich der EC2-Dienst diese Rolle übernehmen darf — das ist die Grundlage für das gesamte Sicherheitsmodell.

# Trust Policy als JSON-Datei speichern
cat > ec2-trust-policy.json << 'EOF'
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Service": "ec2.amazonaws.com"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}
EOF

# Rolle erstellen
aws iam create-role \
  --role-name EC2S3AccessRole \
  --assume-role-policy-document file://ec2-trust-policy.json \
  --description "Erlaubt EC2-Instanzen den Zugriff auf spezifische S3-Buckets"

Schritt 2: Least-Privilege IAM Policy für S3-Zugriff erstellen

Statt einer verwalteten Policy wie AmazonS3FullAccess wird eine enge, ressourcenspezifische Policy erstellt. Der Zugriff beschränkt sich auf den konkreten Bucket — das verhindert, dass eine kompromittierte Instanz auf andere Buckets im Account zugreifen kann.

cat > s3-access-policy.json << 'EOF'
{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "s3:GetObject",
        "s3:PutObject",
        "s3:DeleteObject"
      ],
      "Resource": "arn:aws:s3:::mein-anwendungs-bucket/*"
    },
    {
      "Effect": "Allow",
      "Action": "s3:ListBucket",
      "Resource": "arn:aws:s3:::mein-anwendungs-bucket"
    }
  ]
}
EOF

# Policy erstellen
aws iam create-policy \
  --policy-name EC2S3BucketPolicy \
  --policy-document file://s3-access-policy.json

Schritt 3: Policy an die Rolle anhängen

Die erstellte Policy wird mit der Rolle verknüpft. Die Policy-ARN enthält die Account-ID — diese muss durch die tatsächliche Account-ID ersetzt werden.

aws iam attach-role-policy \
  --role-name EC2S3AccessRole \
  --policy-arn arn:aws:iam::123456789012:policy/EC2S3BucketPolicy

Schritt 4: Instance Profile erstellen und Rolle zuweisen

Das Instance Profile ist der eigentliche Träger, der an die EC2-Instanz gebunden wird. Dieser Schritt entfällt in der Konsole, ist aber über die CLI explizit notwendig — ein häufig übersehener Punkt, der zu 'no credentials'-Fehlern führt.

# Instance Profile erstellen
aws iam create-instance-profile \
  --instance-profile-name EC2S3AccessProfile

# Rolle zum Instance Profile hinzufügen
aws iam add-role-to-instance-profile \
  --instance-profile-name EC2S3AccessProfile \
  --role-name EC2S3AccessRole

Schritt 5: Instance Profile an EC2-Instanz zuweisen

Das Instance Profile kann beim Start einer neuen Instanz oder nachträglich an eine laufende Instanz zugewiesen werden. Bei einer laufenden Instanz ist keine Neustart notwendig — die Credentials sind innerhalb von Sekunden über IMDS verfügbar.

# An eine laufende Instanz zuweisen
aws ec2 associate-iam-instance-profile \
  --instance-id i-0123456789abcdef0 \
  --iam-instance-profile Name=EC2S3AccessProfile

# Zuweisung verifizieren
aws ec2 describe-iam-instance-profile-associations \
  --filters Name=instance-id,Values=i-0123456789abcdef0

Schritt 6: Credentials und Zugriff auf der Instanz verifizieren

Auf der EC2-Instanz selbst lässt sich prüfen, ob die Credentials korrekt bereitgestellt werden. Das AWS CLI greift automatisch auf IMDS zurück — kein explizites Credential-Profil notwendig.

# Auf der EC2-Instanz ausführen:
# Aktive Identität prüfen
aws sts get-caller-identity

# S3-Bucket-Inhalt auflisten
aws s3 ls s3://mein-anwendungs-bucket/

# Temporäre Credentials direkt aus IMDS abrufen (zur Diagnose)
curl http://169.254.169.254/latest/meta-data/iam/security-credentials/EC2S3AccessRole

Der klassische Fehler: Access Keys in EC2-Konfigurationen

Symptom: Die Anwendung läuft lokal einwandfrei, also werden die lokalen AWS-Credentials — oder frisch generierte Access Keys eines IAM Users — in eine Konfigurationsdatei oder Umgebungsvariable auf der EC2-Instanz geschrieben. Funktioniert. Ticket geschlossen.

Die Fehldiagnose: 'Die Anwendung braucht Credentials, also braucht sie einen User mit Keys.' Das klingt logisch, ist aber das falsche Modell. EC2-Instanzen sind keine Menschen — sie brauchen keine permanente Identität.

Die eigentliche Ursache des späteren Problems: Statische Access Keys rotieren nicht automatisch. Sie landen in Deployment-Skripten, AMI-Images, Git-Repositories oder CloudWatch-Logs. Ein einziges versehentliches git push mit einer .env-Datei, und die Keys sind kompromittiert. AWS selbst scannt öffentliche GitHub-Repositories auf geleakte Credentials und sperrt betroffene Keys — aber der Schaden ist dann oft schon entstanden.

Ein IAM User mit Access Keys ist wie ein Hausschlüssel, der nie ausläuft und den man kopieren kann. Ein Instance Profile ist wie ein temporärer Zugangscode, der sich alle paar Stunden ändert und nur von innen funktioniert.

Mit einem Instance Profile existieren keine Credentials in der Konfiguration, in Umgebungsvariablen oder im Code. Das SDK findet sie automatisch über die Credential Provider Chain — IMDS hat dabei die höchste Priorität bei Ausführung auf EC2.

Wann IAM User tatsächlich sinnvoll sind

IAM Roles sind nicht für jeden Anwendungsfall die richtige Wahl. IAM User bleiben relevant für:

  • Menschliche Identitäten ohne SSO/Federation: Wenn kein Identity Provider (IdP) wie AWS IAM Identity Center verfügbar ist und ein Entwickler direkten Konsolen- oder CLI-Zugriff benötigt.
  • Legacy-Systeme außerhalb von AWS: On-Premises-Anwendungen oder externe Dienste, die keine Rolle übernehmen können und keine OIDC/SAML-Federation unterstützen. Hier sind Access Keys mit strikter Rotation und MFA-Enforcement die einzige Option.
  • Spezifische Service-Anforderungen: Einige ältere AWS-Dienste oder Drittanbieter-Integrationen unterstützen ausschließlich statische Credentials. Vor dem Einsatz sollte jedoch geprüft werden, ob eine modernere Integrationsmethode verfügbar ist.

Für alles, was innerhalb von AWS läuft — EC2, Lambda, ECS, EKS, CodeBuild — ist eine IAM Role die korrekte Wahl.

IAM User vs. IAM Role: Entscheidungsbaum

graph TD Start(["Zugriff auf AWS-Ressource benötigt"]) --> Q1{"Läuft der Prozess
innerhalb von AWS?"} Q1 -->|"Ja"| Role["IAM Role verwenden
(Instance Profile, Lambda Role etc.)"] Q1 -->|"Nein"| Q2{"Menschliche Identität?"} Q2 -->|"Ja"| Q3{"IAM Identity Center
verfügbar?"} Q3 -->|"Ja"| SSO["IAM Identity Center
(temporäre Credentials)"] Q3 -->|"Nein"| Q4{"Federation via
SAML/OIDC möglich?"} Q4 -->|"Ja"| Fed["Federated Identity
via IdP"] Q4 -->|"Nein"| User["IAM User mit MFA
und Key-Rotation"] Q2 -->|"Nein (Maschine/System)"| Q5{"Unterstützt das System
OIDC/AssumeRole?"} Q5 -->|"Ja"| RoleExt["IAM Role via
OIDC Federation"] Q5 -->|"Nein"| UserExt["IAM User (letztes Mittel)
mit strikter Rotation"] style Role fill:#d4edda,stroke:#28a745 style SSO fill:#d4edda,stroke:#28a745 style Fed fill:#d4edda,stroke:#28a745 style RoleExt fill:#d4edda,stroke:#28a745 style User fill:#fff3cd,stroke:#ffc107 style UserExt fill:#fff3cd,stroke:#ffc107
  1. Innerhalb von AWS? Wenn der Zugriff von einem AWS-Dienst ausgeht, ist eine Role immer die richtige Wahl.
  2. Mensch oder Maschine? Menschliche Identitäten profitieren von IAM Identity Center mit temporären Credentials statt langlebiger IAM-User-Keys.
  3. Federation möglich? Wenn ein externer IdP vorhanden ist, sollte Federation über SAML oder OIDC genutzt werden.
  4. IAM User als letztes Mittel: Nur wenn keine der obigen Optionen greift und Access Keys mit strikter Rotation und MFA verwendet werden.

Sicherheitsrelevante Tiefe: Die Credential Provider Chain

Das AWS SDK durchsucht Credentials in einer festgelegten Reihenfolge. Auf EC2-Instanzen ist dieser Mechanismus entscheidend — und ein häufiger Grund für unerwartetes Verhalten:

  1. Umgebungsvariablen (AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY)
  2. AWS-Credentials-Datei (~/.aws/credentials)
  3. AWS-Config-Datei (~/.aws/config)
  4. Container-Credentials (für ECS/EKS)
  5. Instance Metadata Service (IMDS) — EC2 Instance Profile

Wenn auf einer EC2-Instanz Umgebungsvariablen mit alten Access Keys gesetzt sind, werden diese vor dem Instance Profile verwendet — auch wenn das Instance Profile korrekt konfiguriert ist. Das führt zu dem verwirrenden Zustand, dass die Rolle zugewiesen ist, aber die Anwendung trotzdem mit den alten, möglicherweise abgelaufenen Keys arbeitet. Umgebungsvariablen auf der Instanz prüfen, bevor die Rolle als fehlerhaft diagnostiziert wird.

Wrap-up: IAM Role ist keine Option, sondern Standard für EC2

Für eine Anwendung auf EC2, die auf S3 zugreift, ist die Antwort eindeutig: IAM Role über ein Instance Profile. Keine Access Keys in Konfigurationsdateien, keine manuelle Rotation, keine Credentials im Code. Das SDK übernimmt den Rest automatisch.

IAM User haben ihren Platz — aber nicht auf EC2-Instanzen. Die nächsten sinnvollen Schritte:

  • Bestehende EC2-Instanzen auf Access Keys in Umgebungsvariablen oder Konfigurationsdateien prüfen: aws iam list-access-keys --user-name <username>
  • AWS-Dokumentation: IAM Roles für EC2
  • AWS IAM Best Practices
  • AWS IAM Access Analyzer einsetzen, um ungenutzte Berechtigungen und externe Zugriffe zu identifizieren

Glossar

BegriffBedeutung
IAM UserPermanente AWS-Identität mit langlebigen Credentials für eine Person oder einen Prozess
IAM RoleTemporäre AWS-Identität ohne eigene Credentials, die von berechtigten Prinzipalen übernommen wird
Instance ProfileContainer, der eine IAM Role enthält und an eine EC2-Instanz gebunden werden kann
STS (Security Token Service)AWS-Dienst, der temporäre, kurzlebige Credentials für übernommene Rollen ausstellt
IMDS (Instance Metadata Service)Lokaler HTTP-Endpunkt auf EC2-Instanzen, über den Metadaten und temporäre Credentials abgerufen werden
Trust PolicyJSON-Policy einer IAM Role, die definiert, welche Prinzipale die Rolle übernehmen dürfen

Kommentare

Kommentar veröffentlichen

Beliebte Posts aus diesem Blog

EC2 ohne Internetzugang im eigenen VPC – Internet Gateway und Route Table korrekt einrichten

Du hast ein eigenes VPC erstellt, eine EC2-Instanz in einem öffentlichen Subnetz gestartet – und ping google.com läuft ins Leere. Kein Timeout-Fehler, keine Fehlermeldung, einfach nichts. Dieses Problem tritt fast immer auf, wenn ein Custom VPC ohne Internet Gateway oder mit einer unvollständigen Route-Table-Konfiguration aufgesetzt wird, weil AWS bei eigenen VPCs bewusst keine Standard-Internetverbindung mitliefert. TL;DR – EC2 Internetzugang im Custom VPC Schritt Aktion Warum notwendig 1 Internet Gateway erstellen und an VPC anhängen Ohne IGW gibt es keinen Pfad ins öffentliche Internet 2 Route Table aktualisieren (0.0.0.0/0 → IGW) Der Traffic muss explizit über das IGW geroutet werden 3 Subnetz mit Route Table verknüpfen Eine Route Table ohne Subnetz-Assoziation hat keine Wirkung 4 Öffentliche IP oder Elastic IP prüfen Ohne öffentliche IP kann das IGW keinen eingehenden Rückpfad aufbauen 5 Securi...
Mehr anzeigen

EC2 SSH Verbindungs-Timeout: Security Group Inbound-Regeln richtig konfigurieren

Du startest eine neue EC2-Instanz, versuchst dich per SSH zu verbinden — und bekommst sofort ein 'Connection timed out'. Kein 'Connection refused', kein Passwort-Prompt, einfach Stille. Das ist fast immer ein Netzwerkproblem auf Infrastrukturebene, und die häufigste Ursache ist eine fehlende oder falsch konfigurierte Inbound-Regel in der Security Group der EC2 SSH-Verbindung. TL;DR — EC2 SSH Verbindungs-Timeout auf einen Blick Schicht Was prüfen Häufigste Ursache Security Group Inbound-Regel für TCP Port 22 Regel fehlt oder falsche Quell-IP Network ACL Inbound + Outbound für Port 22 und Ephemeral Ports Outbound-Regel für Ephemeral Ports fehlt Route Table Route zum Internet Gateway (0.0.0.0/0) Kein Internet Gateway zugewiesen Instanz Public IP vorhanden, Instanz-Status 'running' Keine öffentliche IP zugewiesen Wie EC2-Netzwerkzugriff funktioniert — Pflichtlektüre vor Schritt 1...
Mehr anzeigen