Anwendungsverzeichnisse mit Zugriffspunkten trennen

Einführung

Zwei Anwendungen benötigen gemeinsamen Speicher, sollen aber jeweils in ihrem eigenen Verzeichnis arbeiten. Konfiguriere EFS-Zugriffspunkte mit einer eigenen Wurzel und POSIX-Identität pro Mount und prüfe tatsächliche Dateien und Eigentümer.

Absolviere zuerst Dateien zwischen Anwendungsservern mit EFS teilen. Diese unabhängige VM enthält neue Hosts und ein Subnetz; das vorherige Dateisystem wird nicht wiederverwendet. Nutze Terminal für AWS CLI und SSH und AWS View zum Vergleichen der Uploads. Ein persönliches AWS-Konto ist nicht erforderlich.

Bezug zu Zertifizierungen

Konzeptdarstellung; tatsächliche IDs stehen in deiner frischen Umgebung.

Gemeinsames Dateisystem und NFS-Endpunkt vorbereiten

In diesem Schritt erstellst du Speicher und eingeschränkten Netzwerkzugriff für beide Anwendungen.

Arbeite in /home/labex/project und identifiziere das vorbereitete Netzwerk. AWS CLI ist eingerichtet:

cd /home/labex/project
aws sts \
  get-caller-identity
SUBNET_ID=$(jq -r .subnet_id resources.json)
APP_GROUP_ID=$(jq -r .application_group_id resources.json)
VPC_ID=$(jq -r .vpc_id resources.json)
echo "$SUBNET_ID"
echo "$APP_GROUP_ID"
echo "$VPC_ID"

Erstelle ein neues EFS-Dateisystem. Beide Anwendungen verwenden dieselbe Ressource; ihre Zugriffspunkte wählen verschiedene Verzeichnisse:

FS_ID=$(aws efs \
  create-file-system \
  --creation-token fs02-application-files \
  --encrypted \
  --tags Key=Name,Value=fs02-application-files \
  --query FileSystemId --output text)
echo "$FS_ID"

Erstelle eine eigene Speichergruppe:

EFS_GROUP_ID=$(aws ec2 \
  create-security-group \
  --group-name fs02-efs-access \
  --description 'NFS for the upload application servers' \
  --vpc-id "$VPC_ID" \
  --query GroupId --output text)
echo "$EFS_GROUP_ID"

Erlaube TCP 2049 aus der Anwendungsgruppe. Die Netzwerkregel erlaubt NFS-Verbindungen, wählt aber weder Verzeichnis noch Benutzeridentität:

aws ec2 \
  authorize-security-group-ingress \
  --group-id "$EFS_GROUP_ID" \
  --ip-permissions "IpProtocol=tcp,FromPort=2049,ToPort=2049,UserIdGroupPairs=[{GroupId=$APP_GROUP_ID}]"

Erstelle das Mount Target im vorbereiteten Subnetz:

MOUNT_TARGET_ID=$(aws efs \
  create-mount-target \
  --file-system-id "$FS_ID" \
  --subnet-id "$SUBNET_ID" \
  --security-groups "$EFS_GROUP_ID" \
  --query MountTargetId --output text)
echo "$MOUNT_TARGET_ID"

Prüfe die Zustände und warte bei beiden Ressourcen auf available:

aws efs \
  describe-file-systems \
  --file-system-id "$FS_ID" \
  --query 'FileSystems[].{ID:FileSystemId,State:LifeCycleState}'
aws efs \
  describe-mount-targets \
  --file-system-id "$FS_ID" \
  --query 'MountTargets[].{ID:MountTargetId,IP:IpAddress,State:LifeCycleState}'

Anwendungsspezifische Zugriffspunkte erstellen

In diesem Schritt definierst du Wurzel und Dateiidentität jedes Mounts.

Ein Zugriffspunkt ist ein anwendungsspezifischer EFS-Zugang. Seine Wurzel wird innerhalb des Mounts zu /, und sein POSIX-Benutzer ersetzt die Identität der Client-Dateioperationen. POSIX verwendet numerische UIDs für Benutzer und GIDs für Gruppen.

Erstelle den Zugriffspunkt für A:

AP_A_ID=$(aws efs \
  create-access-point \
  --file-system-id "$FS_ID" \
  --posix-user Uid=2001,Gid=2001 \
  --root-directory 'Path=/app-a,CreationInfo={OwnerUid=2001,OwnerGid=2001,Permissions=700}' \
  --tags Key=Name,Value=fs02-app-a \
  --query AccessPointId --output text)
echo "$AP_A_ID"

Fehlt /app-a, legt CreationInfo Eigentümer und Rechte fest. 700 erlaubt dem Eigentümer Lesen, Schreiben und Durchqueren des Verzeichnisses und gewährt dies anderen Benutzern nicht. UID/GID des Zugriffspunkts entsprechen dem Eigentümer.

Erstelle einen zweiten Zugriffspunkt mit anderer Wurzel und Identität:

AP_B_ID=$(aws efs \
  create-access-point \
  --file-system-id "$FS_ID" \
  --posix-user Uid=2002,Gid=2002 \
  --root-directory 'Path=/app-b,CreationInfo={OwnerUid=2002,OwnerGid=2002,Permissions=700}' \
  --tags Key=Name,Value=fs02-app-b \
  --query AccessPointId --output text)
echo "$AP_B_ID"

Prüfe beide Definitionen:

aws efs \
  describe-access-points \
  --file-system-id "$FS_ID" \
  --query 'AccessPoints[].{ID:AccessPointId,Root:RootDirectory.Path,User:PosixUser,Creation:RootDirectory.CreationInfo}'

Die Wurzeln sind /app-a und /app-b, die Identitäten 2001:2001 und 2002:2002. Der nächste Schritt prüft das Verhalten; passende Konfiguration allein belegt die Grenze nicht.

Ein Zugriffspunkt begrenzt Wurzel und Identität des Mounts, der ihn auswählt. Allein verhindert er nicht, dass ein berechtigter Client einen anderen auswählt. In Produktion können IAM und Dateisystemrichtlinien die erlaubten Zugriffspunkte begrenzen. Hier geht es um Verzeichnisse und POSIX-Verhalten.

Getrennte Verzeichnisse und erzwungene Eigentümer prüfen

In diesem Schritt mountest du beide Zugriffspunkte und zeigst, dass identische Namen verschiedene Dateien bezeichnen.

Mounte As Zugriffspunkt auf A. Zugriffspunkt-Mounts erfordern TLS:

ssh -F ssh_config application-a \
  "sudo mkdir -p /srv/shared && sudo mount -t efs -o tls,stunnel,lookupcache=positive,accesspoint=${AP_A_ID} ${FS_ID}:/ /srv/shared"

lookupcache=positive fragt zuvor fehlende Namen erneut beim Server ab, wenn eine andere Anwendung sie erstellt. Das macht die kurze Übung beobachtbar; Cacheänderungen in Produktion benötigen eine eigene Leistungsbewertung. Siehe Linux-NFS-Verzeichniscache.

Mounte Bs Zugriffspunkt auf B:

ssh -F ssh_config application-b \
  "sudo mkdir -p /srv/shared && sudo mount -t efs -o tls,stunnel,lookupcache=positive,accesspoint=${AP_B_ID} ${FS_ID}:/ /srv/shared"

Beide lokalen Pfade sind /srv/shared, repräsentieren aber /app-a auf A und /app-b auf B. Richte die Anwendungen direkt auf ihre Zugriffspunktwurzel aus:

ssh -F ssh_config application-a \
  'printf "{\"upload_directory\":\"/srv/shared\"}\n" | sudo tee /etc/uploads-app/config.json'
ssh -F ssh_config application-b \
  'printf "{\"upload_directory\":\"/srv/shared\"}\n" | sudo tee /etc/uploads-app/config.json'

Schreibe private.txt über A und versuche über B zu lesen:

curl -i -X PUT --data-binary 'Private upload for application A' \
  http://127.0.0.1:8081/uploads/private.txt
curl -i http://127.0.0.1:8082/uploads/private.txt

A liefert 201 Created, B 404 Not Found. Erstelle jetzt Bs eigene Datei mit demselben Namen:

curl -i -X PUT --data-binary 'Private upload for application B' \
  http://127.0.0.1:8082/uploads/private.txt
curl -i http://127.0.0.1:8081/uploads/private.txt
curl -i http://127.0.0.1:8082/uploads/private.txt

A liefert weiterhin seinen Inhalt, B seinen eigenen. Wähle private.txt und Read upload auf beiden AWS-View-Karten.

Prüfe die tatsächlichen Mounts und Dateiidentitäten:

ssh -F ssh_config application-a 'findmnt -t nfs4 /srv/shared; stat -c "%i %u:%g" /srv/shared/private.txt'
ssh -F ssh_config application-b 'findmnt -t nfs4 /srv/shared; stat -c "%i %u:%g" /srv/shared/private.txt'

Die inodes unterscheiden sich, die Eigentümer sind 2001:2001 und 2002:2002. Die Anwendung läuft als labex, der Server wendet jedoch die Zugriffspunktidentität an.

Auch ein root-Schreibzugriff über As Mount verwendet diese Identität:

ssh -F ssh_config application-a \
  'printf "Access-point identity also applies to root callers\n" | sudo tee /srv/shared/root-caller.txt; stat -c "%u:%g" /srv/shared/root-caller.txt'

Der Eigentümer ist 2001:2001. EFS benötigt keine lokalen Konten namens 2001 oder 2002, um numerische Identitäten anzuwenden.

As Mount zeigt /app-a, nicht die gesamte EFS-Wurzel. Bs Geschwisterverzeichnis ist kein Unterverzeichnis dieses Mounts:

ssh -F ssh_config application-a 'ls -a /srv/shared'
ssh -F ssh_config application-a 'cat /srv/shared/app-b/private.txt'

Der letzte Befehl liefert No such file or directory, obwohl B seine vorhandene Datei lesen kann. Unabhängige Wurzeln und verschiedene Inhalte belegen die Trennung. .. vom lokalen Mountpunkt führt in das lokale Elternverzeichnis, nicht zum EFS-Geschwisterverzeichnis.

Derselbe Name hat in zwei Wurzeln verschiedene Inhalte. IDs variieren zwischen Umgebungen.

Zugriffspunkte und gemeinsamen Speicher entfernen

In diesem Schritt gibst du die Mounts frei und entfernst nur eigene Speicherressourcen.

Stelle vor dem Aushängen die lokalen Verzeichnisse wieder her:

ssh -F ssh_config application-a \
  'printf "{\"upload_directory\":\"/srv/uploads\"}\n" | sudo tee /etc/uploads-app/config.json'
ssh -F ssh_config application-b \
  'printf "{\"upload_directory\":\"/srv/uploads\"}\n" | sudo tee /etc/uploads-app/config.json'
ssh -F ssh_config application-a 'sudo umount /srv/shared'
ssh -F ssh_config application-b 'sudo umount /srv/shared'

Lösche beide Zugriffspunkte und prüfe, dass keiner verbleibt:

aws efs \
  delete-access-point \
  --access-point-id "$AP_A_ID"
aws efs \
  delete-access-point \
  --access-point-id "$AP_B_ID"
aws efs \
  describe-access-points \
  --file-system-id "$FS_ID"

AccessPoints soll leer sein. Das Löschen entfernt nur die Zugangskonfiguration, nicht die Dateien im Verzeichnis. Jetzt entfernst du das gesamte temporäre Dateisystem mit seinen Daten:

aws efs \
  delete-mount-target \
  --mount-target-id "$MOUNT_TARGET_ID"
aws efs \
  describe-mount-targets \
  --file-system-id "$FS_ID"

Warte auf leere MountTargets, bevor du fortfährst:

aws efs \
  delete-file-system \
  --file-system-id "$FS_ID"
aws ec2 \
  delete-security-group \
  --group-id "$EFS_GROUP_ID"

Bestätige erfolgreiche leere Dienstantworten für deine benannten Ressourcen:

aws efs \
  describe-file-systems \
  --query 'FileSystems[?Name==`fs02-application-files`].FileSystemId'
aws ec2 \
  describe-security-groups \
  --filters Name=group-name,Values=fs02-efs-access \
  --query 'SecurityGroups[].GroupId'

Beide Listen sind leer. Behalte vorbereitete Server, Gruppen und Subnetz und führe die Prüfung aus.

Zusammenfassung

Zwei Zugriffspunkte wählten verschiedene Wurzeln und POSIX-Identitäten in einem EFS-Dateisystem. Gleiche Namen enthielten unterschiedliche Daten, und der Server erzwang Eigentümer auch für root-Clients. Danach hast du Mounts, Zugriffspunkte, Netzwerkendpunkt und temporäres Dateisystem entfernt.

Netzwerkzugriff, Mount-Auswahl und Verzeichnisrechte sind unterschiedliche Ebenen. Die nächste Übung verwendet sie zur Diagnose einer EFS-Verbindung.

Weitere Informationen bietet die AWS-Dokumentation: Wurzelverzeichnisse, Identitäten und Berechtigungsumfang von Zugriffspunkten.