Dienstkonten und STS

RustFS bietet zwei Mechanismen, um Zugangsdaten auszustellen, die von einer vorhandenen Identität abgeleitet sind: Dienstkonten (langlebige Zugriffsschlüssel eines übergeordneten Benutzers) und temporäre STS-Zugangsdaten (kurzlebige Schlüssel mit einem Sitzungstoken).

DienstkontenCopy Anchor Link

Ein Dienstkonto ist ein Paar aus Zugriffsschlüssel und geheimem Zugriffsschlüssel, das einem übergeordneten IAM-Benutzer gehört (oder dem Root-Konto). Es authentifiziert sich wie ein normaler Schlüssel, wird aber als sein übergeordnetes Konto autorisiert:

• Geerbte Richtlinie (Standard). Wird das Dienstkonto ohne Richtlinie angelegt, erbt es das, was die zusammengefassten Richtlinien des übergeordneten Benutzers zum Zeitpunkt der Anfrage erlauben.
• An die Sitzung gebundene Richtlinie. Wird beim Anlegen ein Richtliniendokument übergeben, wird es in das Dienstkonto eingebettet. Anfragen müssen dann sowohl von den Richtlinien des übergeordneten Kontos als auch von der eingebetteten Richtlinie erlaubt sein.
• Ablauf. Optional lässt sich ein Ablaufzeitpunkt (RFC 3339) setzen; die Zugangsdaten funktionieren nach diesem Zeitpunkt nicht mehr.

Dienstkonten können AssumeRole nicht aufrufen, und ein Zugriffsschlüssel eines Dienstkontos lässt sich nicht in einen regulären IAM-Benutzer umwandeln.

In der Console verwalten Sie Dienstkonten auf der Seite Access Keys (Zugriffsschlüssel); siehe Zugriffsschlüssel-Verwaltung. Die Admin-API stellt bereit:

JSON-Body beim Anlegen (alle Felder optional, sofern nicht anders angegeben):

{
  "policy": { "Version": "2012-10-17", "Statement": [] },
  "targetUser": "alice",
  "accessKey": "myserviceaccount",
  "secretKey": "mysecret",
  "name": "ci-pipeline",
  "description": "Key used by CI",
  "expiration": "2027-01-01T00:00:00Z"
}

Temporäre STS-ZugangsdatenCopy Anchor Link

RustFS stellt einen AWS-kompatiblen STS-Endpunkt an der Serverwurzel bereit (POST / mit formularcodierten Parametern). Zwei Aktionen werden unterstützt:

• AssumeRole — für vorhandene IAM-Identitäten, signiert mit SigV4.
• AssumeRoleWithWebIdentity — für OIDC-Identitäten, authentifiziert durch das JWT selbst (siehe Externe Identität (OIDC)).

AssumeRoleCopy Anchor Link

Die Anfrage muss mit AWS Signature V4 von langfristigen IAM-Zugangsdaten signiert sein. Temporäre Zugangsdaten und Dienstkonten können AssumeRole nicht aufrufen. Bei der eingebauten IAM-Autorisierung wertet RustFS sts:AssumeRole für reguläre IAM-Benutzer im Nur-Deny-Modus aus: Ein passendes ausdrückliches Deny lehnt die Anfrage ab, ein separates Allow ist nicht erforderlich. Der Benutzer muss mindestens eine anwendbare Benutzer- oder Gruppenrichtlinienzuordnung haben, und alle zugeordneten Richtliniennamen müssen auflösbar sein.

Formularparameter:

Beispiel:

curl -s -X POST "https://rustfs.example.com/" \
  --user "$ACCESS_KEY:$SECRET_KEY" \
  --aws-sigv4 "aws:amz:us-east-1:s3" \
  -d "Action=AssumeRole" \
  -d "Version=2011-06-15" \
  -d "DurationSeconds=3600"

Die Antwort ist ein XML-Dokument AssumeRoleResponse mit AccessKeyId, SecretAccessKey, SessionToken und Expiration. Verwenden Sie alle drei Werte bei nachfolgenden S3-Anfragen (das Sitzungstoken steht in X-Amz-Security-Token).

Die temporären Zugangsdaten erben die Richtlinien des Aufrufers; das Feld parent der Zugangsdaten ist der aufrufende Zugriffsschlüssel. Wurde ein Parameter Policy übergeben, wird er in der Sitzung gespeichert und als zusätzliche Einschränkung angewendet.

AssumeRoleWithWebIdentityCopy Anchor Link

Wird vom OIDC-Ablauf verwendet. Eine SigV4-Signatur ist nicht erforderlich, weil das JWT des Identitätsanbieters die Authentifizierung ist:

RustFS prüft das Token gegen den konfigurierten Anbieter (Signatur, Aussteller, Zielgruppe, Ablauf), ordnet die Claims groups und roles Namen von RustFS-Richtlinien zu und lehnt die Anfrage ab, wenn keine Richtlinien oder Gruppen zugeordnet werden können. Die Antwort ist ein XML-Dokument AssumeRoleWithWebIdentityResponse mit denselben Zugangsdatenfeldern plus SubjectFromWebIdentityToken.