Verwenden von Cloud-Objektspeicher in AWS

Die Best Practice, um Arbeitslasten in Ihrem EKS-Cluster den Zugriff auf Cloud-Services zu ermöglichen, besteht in der Verwendung von IAM-Rollen. Für ArcGIS Enterprise können Sie den Zugriff auf den Cloud-Objektspeicher und die Sicherungsspeicher der Organisation in AWS-S3-Buckets entweder über eine Pod-Identität oder über eine auf Knotengruppen basierte IAM-Rolle gewähren.

Es wird empfohlen, dass Ihre Organisation die Pod-Identität für die Authentifizierung von Kubernetes-Arbeitslasten verwendet, da dies die genaueste Kontrolle über die den Pods gewährten Berechtigungen ermöglicht. Falls Ihre Organisation zur Steuerung von Berechtigungen Knotengruppen basierte IAM-Rollen verwendet, wird empfohlen, bei einer Aktualisierung oder einem Upgrade auf die Verwendung von Pod-Identitäten umzustellen.

Verwenden der EKS-Pod-Identität

ArcGIS Enterprise on Kubernetes verwendet abhängig von den erforderlichen Berechtigungen für den Kubernetes-API-Server unterschiedliche Service-Konten für die einzelnen Arbeitslasten. Diese Service-Konten benötigen zudem unterschiedliche Berechtigungen für den Zugriff auf integrierte Cloud-Services. Mithilfe der Pod-Identität können Sie eine Zuordnung zwischen jedem Service-Konto und einer IAM-Rolle mit den erforderlichen Berechtigungen herstellen.

Wichtig

Bevor ArcGIS Enterprise on Kubernetes bereitgestellt oder andere Abhängigkeiten in AWS erstellt werden, muss das EKS Pod Identity Agent-Add-on im Cluster installiert werden. Anweisungen finden Sie unter Einrichten des Amazon EKS Pod Identity Agent.

IAM-Rollen und -Richtlinien

Bevor Sie ArcGIS Enterprise on Kubernetes mit einem AWS-S3-Cloud-Objektspeicher und einem Sicherungsspeicher bereitstellen und konfigurieren, richten Sie die folgenden IAM-Rollen und -Richtlinien ein:

Lese- und Schreibzugriff auf Cloud-Objektspeicher und Sicherungsspeicher

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "s3:PutObject",
                "s3:GetObject",
                "s3:ListBucket",
                "s3:DeleteObject",
                "s3:GetLifecycleConfiguration",
                "s3:PutLifecycleConfiguration",
                "s3:ListMultipartUploadParts",
                "s3:GetBucketLocation",
                "s3:AbortMultipartUpload"
            ],
            "Resource": [
                "arn:aws:s3:::<cloudObjectStoreBucket>/*",
                "arn:aws:s3:::<cloudObjectStoreBucket>",
                "arn:aws:s3:::<backupStoreBucket>/*",
                "arn:aws:s3:::<backupStoreBucket>"
            ]
        }
    ]
}

Lese- und Schreibzugriff auf den Cloud-Objektspeicher

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "s3:PutObject",
                "s3:GetObject",
                "s3:ListBucket",
                "s3:DeleteObject",
                "s3:GetLifecycleConfiguration",
                "s3:PutLifecycleConfiguration",
                "s3:ListMultipartUploadParts",
                "s3:GetBucketLocation",
                "s3:AbortMultipartUpload"
            ],
            "Resource": [
                "arn:aws:s3:::<cloudObjectStoreBucket>/*",
                "arn:aws:s3:::<cloudObjectStoreBucket>"
            ]
        }
    ]
}

Schreibgeschützter Zugriff auf den Cloud-Objektspeicher

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "s3:GetObject",
                "s3:ListBucket",
                "s3:GetBucketLocation"
            ],
            "Resource": [
                "arn:aws:s3:::<cloudObjectStoreBucket>/*",
                "arn:aws:s3:::<cloudObjectStoreBucket>"
            ]
        }
    ]
}

Hinweis:

Unter jeder IAM-Rolle können zusätzliche Richtlinien erstellt werden, um neben den Systemobjekt- und Sicherungsspeichern auch den Zugriff auf Benutzerspeicher-Buckets zu ermöglichen.

Zuordnungen von Pod-Identitäten

Fügen Sie innerhalb des EKS-Clusters Zuordnungen von Pod-Identitäten hinzu, um jedes Service-Konto der entsprechenden IAM-Rolle zuzuordnen. Anweisungen finden Sie im Abschnitt IAM-Rollen Kubernetes-Servicekonten zuweisen der AWS-Dokumentation.

In der folgenden Tabelle sind die erforderlichen IAM-Rollen für die einzelnen Service-Konten aufgeführt:

Service-Konto	IAM-Rolle
arcgis-admin-serviceaccount	Lese- und Schreibzugriff auf Cloud-Objekt- und Sicherungsspeicher
arcgis-disasterrecovery-serviceaccount	Lese- und Schreibzugriff auf Cloud-Objekt- und Sicherungsspeicher
arcgis-spatiotemporalindex-serviceaccount	Lese- und Schreibzugriff auf Cloud-Objekt- und Sicherungsspeicher
arcgis-cloudservice-readwrite-serviceaccount	Lese- und Schreibzugriff auf den Cloud-Objektspeicher
arcgis-cloudservice-readonly-serviceaccount	Schreibgeschützter Zugriff auf den Cloud-Objektspeicher

Die Namen der Service-Konten in der Tabelle entsprechen dem Standard-Site-Namen arcgis. Wenn Sie einen anderen Site-Namen konfiguriert haben, wird dieser Name anstelle von arcgis als Präfix für das Service-Konto verwendet. Überprüfen Sie Ihre aktuellen Einstellungen für die Organisation, falls Sie sich bezüglich des Namens Ihrer Organisation nicht sicher sind.

Verwenden einer auf Knotengruppen basierte IAM-Rolle

Falls Sie die Pod-Identität nicht verwenden können, kann ArcGIS Enterprise on Kubernetes auch eine IAM-Rolle verwenden, die der Knotengruppe des Kubernetes-Clusters zugewiesen ist, um Berechtigungen den Zugriff auf Cloud-Services zu gewähren.

Achtung:

Wenn Sie eine auf einer Knotengruppe basierte IAM-Rolle verwenden, verfügen alle auf diesen Knoten ausgeführten Arbeitslasten über die gleichen Berechtigungen. Dies führt dazu, dass einige Arbeitslasten über nicht benötigte Berechtigungen verfügen.

Um eine auf Knotengruppen basierte IAM-Rolle zu verwenden, erstellen Sie eine einzelne kombinierte Lese- und Schreibrichtlinie:

{
 "Version": "2012-10-17",
 "Statement": [
     {
         "Effect": "Allow",
         "Action": [
             "s3:PutObject",
             "s3:GetObject",
             "s3:ListBucket",
             "s3:DeleteObject",
             "s3:GetLifecycleConfiguration",
             "s3:PutLifecycleConfiguration",
             "s3:ListMultipartUploadParts",
             "s3:GetBucketLocation",
             "s3:AbortMultipartUpload"
         ],
         "Resource": [
             "arn:aws:s3:::<systemObjectStoreBucket>/*",
             "arn:aws:s3:::<systemObjectStoreBucket>",
             "arn:aws:s3:::<backupStoreBucket>/*",
             "arn:aws:s3:::<backupStoreBucket>"
         ]
     }
 ]
}

Migration zur EKS-Pod-Identität

Organisationen, die eine auf Knotengruppen basierte IAM-Rolle verwenden, sollten im Rahmen einer Aktualisierung oder eines Upgrades der Organisation die Umstellung auf die EKS-Pod-Identität einplanen. Dadurch werden Betriebsunterbrechungen auf ein Minimum reduziert, da alle Pods nach dem Erstellen der Zuordnungen der Pod-Identitäten neu gestartet werden müssen. Pods werden bei Aktualisierungen und Upgrades der Organisation automatisch neu gestartet.

Führen Sie die folgenden Schritte aus, um auf die Verwendung von Pod-Identitäten zur Verwaltung von Berechtigungen zu migireren:

Installieren Sie das EKS Pod Identity Agent-Add-on.
Erstellen Sie die erforderlichen Zuordnungen der IAM-Rollen und Pod-Identitäten.
Führen Sie ein Upgrade von ArcGIS Enterprise durch.
Stellen Sie sicher, dass die Services und kritischen Workflows einwandfrei funktionieren.
Entfernen Sie die IAM-Richtlinie aus der IAM-Rolle der Knotengruppe, die den Zugriff auf den S3-Speicher ermöglicht.
Überprüfen Sie erneut, ob die Services und kritischen Arbeitslasten funktionieren.

Sollte bei diesem Schritt ein Problem festgestellt werden, fügen Sie die ursprüngliche IAM-Richtlinie erneut zur IAM-Rolle der Knotengruppe hinzu. Auf diese Weise können Sie die Funktionalität wiederherstellen, während Sie die Überprüfung des Add-on-Status, der IAM-Rollen und -Richtlinien für die Pod-Identität sowie der Zuordnungen der Pod-Identität fortsetzen.