Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Beispiele für identitätsbasierte Richtlinien für AWS Glue

Benutzer und Rollen haben standardmäßig nicht die Berechtigung, AWS-Glue-Ressourcen zu erstellen oder zu ändern. Sie können auch keine Aufgaben über die AWS Management Console, die AWS Command Line Interface (AWS CLI) oder die AWS-API ausführen. Ein IAM-Administrator muss IAM-Richtlinien erstellen, die Benutzern die Berechtigung erteilen, Aktionen für die Ressourcen auszuführen, die sie benötigen. Der Administrator kann dann die IAM-Richtlinien zu Rollen hinzufügen, und Benutzer können die Rollen annehmen.

Informationen dazu, wie Sie unter Verwendung dieser beispielhaften JSON-Richtliniendokumente eine identitätsbasierte IAM-Richtlinie erstellen, finden Sie unter Erstellen von IAM-Richtlinien im IAM-Benutzerhandbuch.

Einzelheiten zu den von AWS Glue definierten Aktionen und Ressourcentypen, einschließlich des Formats der ARNs für die einzelnen Ressourcentypen, finden Sie unter Aktionen, Ressourcen und Bedingungsschlüssel für AWS Glue in der Service-Autorisierungs-Referenz.

Bewährte Methoden für Richtlinien

Identitätsbasierte Richtlinien legen fest, ob jemand AWS-Glue-Ressourcen in Ihrem Konto erstellen, darauf zugreifen oder sie löschen kann. Dies kann zusätzliche Kosten für Ihr verursachen AWS-Konto. Befolgen Sie beim Erstellen oder Bearbeiten identitätsbasierter Richtlinien die folgenden Anleitungen und Empfehlungen:

Weitere Informationen zu bewährten Methoden in IAM finden Sie unter Bewährte Methoden für die Sicherheit in IAM im IAM-Benutzerhandbuch.

Berechtigungen auf Ressourcenebene gelten nur für bestimmte AWS Glue-Objekte

Eine differenziertere Kontrolle kann nur für bestimmte Objekte in AWS Glue definiert werden. Daher müssen Sie die IAM-Richtlinie Ihres Kunden so schreiben, dass API-Operationen, die Amazon-Ressourcennamen (ARNs) für die Resource-Anweisung zulassen, nicht mit API-Operationen gemischt werden, die keine ARNs zulassen.

Beispiel: Die folgende IAM-Richtlinie lässt API-Operationen für GetClassifier und GetJobRun zu. Sie definiert Resource als *, da AWS Glue keine ARNs für Classifier und Auftragsausführungen zulässt. Da ARNs für bestimmte API-Operationen wie z. B. GetDatabase und GetTable zulässig sind, können ARNs in der zweiten Hälfte der Richtlinie angegeben werden.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "glue:GetClassifier*",
                "glue:GetJobRun*"
            ],
            "Resource": "*"   
        },
        {
            "Effect": "Allow",
            "Action": [
                "glue:Get*"
            ],
            "Resource": [
                "arn:aws:glue:us-east-1:123456789012:catalog",
                "arn:aws:glue:us-east-1:123456789012:database/default",
                "arn:aws:glue:us-east-1:123456789012:table/default/e*1*",
                "arn:aws:glue:us-east-1:123456789012:connection/connection2"
            ]
        }
    ]
}

Eine Liste der AWS Glue-Objekte, die ARNs zulassen, finden Sie unter AWS GlueRessource angeben ARNs.

Verwenden der AWS-Glue-Konsole

Um auf die AWS-Glue-Konsole zuzugreifen, müssen Sie über einen Mindestsatz von Berechtigungen verfügen. Diese Berechtigungen müssen Ihnen das Auflisten und Anzeigen von Details zu den AWS-Glue-Ressourcen in Ihrem AWS-Konto-Konto gestatten. Wenn Sie eine identitätsbasierte Richtlinie erstellen, die strenger ist als die mindestens erforderlichen Berechtigungen, funktioniert die Konsole nicht wie vorgesehen für Entitäten (Benutzer oder Rollen) mit dieser Richtlinie.

Für Benutzer, die nur Aufrufe an die AWS CLI oder AWS-API durchführen, müssen Sie keine Mindestberechtigungen in der Konsole erteilen. Stattdessen sollten Sie nur Zugriff auf die Aktionen zulassen, die der API-Operation entsprechen, die die Benutzer ausführen möchten.

Um sicherzustellen, dass Benutzer und Rollen weiterhin die AWS-Glue-Konsole verwenden können, fügen Sie den Entitäten auch die von AWS Glue ConsoleAccess oder ReadOnly AWS-verwaltete Richtlinie hinzu. Weitere Informationen finden Sie unter Hinzufügen von Berechtigungen zu einem Benutzer im IAM-Benutzerhandbuch.

Damit ein Benutzer mit der AWS Glue-Konsole arbeiten kann, muss dieser über eine Mindestmenge an Berechtigungen verfügen, die es ihm erlauben, mit den AWS Glue-Ressourcen für ihr AWS-Konto zu arbeiten. Zusätzlich zu diesen AWS Glue-Berechtigungen erfordert die Konsole Berechtigungen von den folgenden Services:

Weitere Informationen zu den Berechtigungen, die Ihre Benutzer benötigen, um die AWS Glue-Konsole anzuzeigen und mit ihr zu arbeiten, finden Sie unter Schritt 3: Fügen Sie eine Richtlinie an Benutzer an, die auf AWS Glue zugreifen.

Wenn Sie eine IAM-Richtlinie erstellen, die strenger ist als die mindestens erforderlichen Berechtigungen, funktioniert die Konsole nicht wie vorgesehen für Benutzer mit dieser IAM-Richtlinie. Um sicherzustellen, dass diese Benutzer die AWS Glue-Konsole weiterhin verwenden können, fügen Sie dem Benutzer auch die AWSGlueConsoleFullAccess-verwaltete Richtlinie, wie in AWS verwaltete (vordefinierte) Richtlinien für AWS Glue beschrieben, an.

Gewähren der Berechtigung zur Anzeige der eigenen Berechtigungen für Benutzer

In diesem Beispiel wird gezeigt, wie Sie eine Richtlinie erstellen, die IAM-Benutzern die Berechtigung zum Anzeigen der eingebundenen Richtlinien und verwalteten Richtlinien gewährt, die ihrer Benutzeridentität angefügt sind. Diese Richtlinie enthält Berechtigungen für die Ausführung dieser Aktion auf der Konsole oder für die programmgesteuerte Ausführung über die AWS CLI oder die AWS-API.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "ViewOwnUserInfo",
            "Effect": "Allow",
            "Action": [
                "iam:GetUserPolicy",
                "iam:ListGroupsForUser",
                "iam:ListAttachedUserPolicies",
                "iam:ListUserPolicies",
                "iam:GetUser"
            ],
            "Resource": ["arn:aws:iam::*:user/${aws:username}"]
        },
        {
            "Sid": "NavigateInConsole",
            "Effect": "Allow",
            "Action": [
                "iam:GetGroupPolicy",
                "iam:GetPolicyVersion",
                "iam:GetPolicy",
                "iam:ListAttachedGroupPolicies",
                "iam:ListGroupPolicies",
                "iam:ListPolicyVersions",
                "iam:ListPolicies",
                "iam:ListUsers"
            ],
            "Resource": "*"
        }
    ]
}

Nur-Leseberechtigung für eine Tabelle erteilen

Die folgende Richtlinie gewährt Lesezugriff auf eine Tabelle books in der Datenbank db1. Weitere Informationen zur Verwendung von Amazon-Ressourcennamen (ARNs) finden Sie unter Datenkatalog ARNs.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "GetTablesActionOnBooks",
      "Effect": "Allow",
      "Action": [
        "glue:GetTables",
        "glue:GetTable"        
      ],
      "Resource": [
        "arn:aws:glue:us-west-2:123456789012:catalog",      
        "arn:aws:glue:us-west-2:123456789012:database/db1",
        "arn:aws:glue:us-west-2:123456789012:table/db1/books"
      ]
    }
  ]
}

Diese Richtlinie gewährt Lesezugriff auf eine Tabelle mit dem Namen books in der Datenbank namens db1. Zum Erteilen der Berechtigung Get zu einer Tabelle ist auch die Berechtigung für den Katalog und die Datenbankressourcen erforderlich.

Die folgende Richtlinie gewährt die Mindestberechtigungen zum Erstellen der Tabelle tb1 in der Datenbank db1:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "glue:CreateTable"
      ],
      "Resource": [
        "arn:aws:glue:us-west-2:123456789012:table/db1/tbl1",
        "arn:aws:glue:us-west-2:123456789012:database/db1",
        "arn:aws:glue:us-west-2:123456789012:catalog"        
      ]
    }
  ]
}

Tabellen nach GetTables-Berechtigung filtern

Angenommen, es gibt drei Tabellen customers , stores und store_sales in der Datenbank db1. Die folgende Richtlinie gewährt GetTables die Berechtigung für stores und store_sales, aber nicht für customers. Wenn Sie GetTables mit dieser Richtlinie aufrufen, enthält das Ergebnis nur die beiden autorisierten Tabellen (die Tabelle customers wird nicht zurückgegeben).

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "GetTablesExample",
            "Effect": "Allow",
            "Action": [
                "glue:GetTables"
            ],
            "Resource": [
                "arn:aws:glue:us-west-2:123456789012:catalog",            
                "arn:aws:glue:us-west-2:123456789012:database/db1",
                "arn:aws:glue:us-west-2:123456789012:table/db1/store_sales",
                "arn:aws:glue:us-west-2:123456789012:table/db1/stores"
            ]
        }
    ]
}

Sie können die vorhergehende Richtlinie vereinfachen, indem Sie store* angeben und so alle Tabellennamen einschließen, die mit store beginnen.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "GetTablesExample2",
            "Effect": "Allow",
            "Action": [
                "glue:GetTables"
            ],
            "Resource": [
                "arn:aws:glue:us-west-2:123456789012:catalog",            
                "arn:aws:glue:us-west-2:123456789012:database/db1",
                "arn:aws:glue:us-west-2:123456789012:table/db1/store*"
            ]
        }
    ]
}

In ähnlicher Weise wird bei Verwendung von /db1/* zum Einschließen aller Tabellen in db1 durch die folgende Richtlinie GetTables Zugriff auf alle Tabellen in db1 gewährt.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "GetTablesReturnAll",
            "Effect": "Allow",
            "Action": [
                "glue:GetTables"
            ],
            "Resource": [
                "arn:aws:glue:us-west-2:123456789012:catalog",            
                "arn:aws:glue:us-west-2:123456789012:database/db1",
                "arn:aws:glue:us-west-2:123456789012:table/db1/*"
            ]
        }
    ]
}

Wird kein Tabellen-ARN angegeben, ist ein Aufruf von GetTables erfolgreich, aber es wird eine leere Liste zurückgegeben.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "GetTablesEmptyResults",
            "Effect": "Allow",
            "Action": [
                "glue:GetTables"
            ],
            "Resource": [
                "arn:aws:glue:us-west-2:123456789012:catalog",            
                "arn:aws:glue:us-west-2:123456789012:database/db1"
            ]
        }
    ]
}

Wenn der Datenbank-ARN in der Richtlinie fehlt, schlägt ein Aufruf von GetTables mit einer AccessDeniedException fehl.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "GetTablesAccessDeny",
            "Effect": "Allow",
            "Action": [
                "glue:GetTables"
            ],
            "Resource": [
                "arn:aws:glue:us-west-2:123456789012:catalog",            
                "arn:aws:glue:us-west-2:123456789012:table/db1/*"
            ]
        }
    ]
}

Vollständiger Zugriff auf eine Tabelle und alle Partitionen gewähren

Die folgende Richtlinie gewährt alle Berechtigungen für eine Tabelle mit dem Namen books in der Datenbank db1. Dazu gehören Lese- und Schreibrechte für die Tabelle selbst, die archivierten Versionen und alle Partitionen.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "FullAccessOnTable",
            "Effect": "Allow",
            "Action": [
                "glue:CreateTable",
                "glue:GetTable",
                "glue:GetTables",                
                "glue:UpdateTable",
                "glue:DeleteTable",
                "glue:BatchDeleteTable",
                "glue:GetTableVersion",
                "glue:GetTableVersions",
                "glue:DeleteTableVersion",
                "glue:BatchDeleteTableVersion",
                "glue:CreatePartition",
                "glue:BatchCreatePartition",
                "glue:GetPartition",
                "glue:GetPartitions",
                "glue:BatchGetPartition",
                "glue:UpdatePartition",
                "glue:DeletePartition",
                "glue:BatchDeletePartition"
            ],
            "Resource": [
                        "arn:aws:glue:us-west-2:123456789012:catalog",
                        "arn:aws:glue:us-west-2:123456789012:database/db1",
                        "arn:aws:glue:us-west-2:123456789012:table/db1/books" 
                        ]
        }
    ]
}

Die vorhergehende Richtlinie kann in der Praxis vereinfacht werden.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "FullAccessOnTable",
            "Effect": "Allow",
            "Action": [
                "glue:*Table*",
                "glue:*Partition*"
            ],
            "Resource": [
                "arn:aws:glue:us-west-2:123456789012:catalog",            
                "arn:aws:glue:us-west-2:123456789012:database/db1",
                "arn:aws:glue:us-west-2:123456789012:table/db1/books"
            ]
        }
    ]
}

Beachten Sie, dass die minimale Granularität der differenzierten Zugriffskontrolle auf Tabellenebene liegt. Das bedeutet, dass Sie einem Benutzer keinen Zugriff auf einige Partitionen in einer Tabelle gewähren können, aber nicht auf andere, oder auf einige Tabellenspalten, aber nicht auf andere. Ein Benutzer hat entweder Zugriff auf die gesamte oder auf keinen Teil der Tabelle.

Steuerung des Zugriffs über Namenspräfix und explizites Verweigern

In diesem Beispiel nehmen wir an, dass die Datenbanken und Tabellen in AWS Glue mit Namenspräfixen organisiert sind. Die Datenbanken in der Entwicklungsphase haben das Namenspräfix dev- und die in Produktion haben das Namenspräfix prod-. Sie können die folgende Richtlinie verwenden, um Entwicklern vollen Zugriff auf alle Datenbanken, Tabellen, UDFs usw. zu gewähren, die das Präfix dev- tragen. Aber Sie gewähren Lesezugriff auf alle Elemente mit dem Präfix prod-.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "DevAndProdFullAccess",
            "Effect": "Allow",
            "Action": [
                "glue:*Database*",
                "glue:*Table*",
                "glue:*Partition*",
                "glue:*UserDefinedFunction*",
                "glue:*Connection*"
            ],
            "Resource": [
                "arn:aws:glue:us-west-2:123456789012:catalog",
                "arn:aws:glue:us-west-2:123456789012:database/dev-*",
                "arn:aws:glue:us-west-2:123456789012:database/prod-*",
                "arn:aws:glue:us-west-2:123456789012:table/dev-*/*",
                "arn:aws:glue:us-west-2:123456789012:table/*/dev-*",
                "arn:aws:glue:us-west-2:123456789012:table/prod-*/*",
                "arn:aws:glue:us-west-2:123456789012:table/*/prod-*",
                "arn:aws:glue:us-west-2:123456789012:userDefinedFunction/dev-*/*",
                "arn:aws:glue:us-west-2:123456789012:userDefinedFunction/*/dev-*",
                "arn:aws:glue:us-west-2:123456789012:userDefinedFunction/prod-*/*",
                "arn:aws:glue:us-west-2:123456789012:userDefinedFunction/*/prod-*",
                "arn:aws:glue:us-west-2:123456789012:connection/dev-*",
                "arn:aws:glue:us-west-2:123456789012:connection/prod-*"
            ]
        },
        {
            "Sid": "ProdWriteDeny",
            "Effect": "Deny",
            "Action": [
                "glue:*Create*",
                "glue:*Update*",
                "glue:*Delete*"
            ],
            "Resource": [
                "arn:aws:glue:us-west-2:123456789012:database/prod-*",
                "arn:aws:glue:us-west-2:123456789012:table/prod-*/*",
                "arn:aws:glue:us-west-2:123456789012:table/*/prod-*",
                "arn:aws:glue:us-west-2:123456789012:userDefinedFunction/prod-*/*",
                "arn:aws:glue:us-west-2:123456789012:userDefinedFunction/*/prod-*",
                "arn:aws:glue:us-west-2:123456789012:connection/prod-*"
            ]
        }
    ]
}

Die zweite Anweisung in der vorhergehenden Richtlinie verwendet explizit deny. Sie können explizit deny verwenden, um beliebige allow-Berechtigungen zu überschreiben, die dem Prinzipal erteilt werden. Auf diese Weise können Sie den Zugriff auf kritische Ressourcen sperren und verhindern, dass eine andere Richtlinie versehentlich Zugriff auf diese gewährt.

Auch wenn die erste Anweisung im vorherigen Beispiel Vollzugriff auf prod--Ressourcen gewährt, widerruft die zweite Anweisung explizit den Schreibzugriff auf sie, sodass nur Lesezugriff auf prod--Ressourcen besteht.

Zugriffssteuerung gewähren mit Tags

Angenommen, Sie möchten den Zugriff auf einen t2-Auslöser auf einen bestimmten Benutzer mit dem Namen Tom in Ihrem Konto einschränken. Alle anderen Benutzer, einschließlich Sam, haben Zugriff auf den Auslöser t1. Die Auslöser t1 und t2 haben die folgenden Eigenschaften.

aws glue get-triggers
{
    "Triggers": [
        {
            "State": "CREATED",
            "Type": "SCHEDULED",
            "Name": "t1",
            "Actions": [
                {
                    "JobName": "j1"
                }
            ],
            "Schedule": "cron(0 0/1 * * ? *)"
        },
        {
            "State": "CREATED",
            "Type": "SCHEDULED",
            "Name": "t2",
            "Actions": [
                {
                    "JobName": "j1"
                }
            ],
            "Schedule": "cron(0 0/1 * * ? *)"
        }
    ]
}

Der AWS Glue-Administrator hat den Tag-Wert Tom (aws:ResourceTag/Name": "Tom") an den Auslöser t2 angehängt. Außerdem hat der AWS Glue-Administrator Tom eine IAM-Richtlinie mit einer auf dem Tag basierenden Bedingungsanweisung zugewiesen. Dies hat zur Folge, dass Tom nur AWS Glue-Operationen verwenden kann, die auf Ressourcen mit dem Tag-Wert Tom einwirken.

{
    "Version": "2012-10-17",
    "Statement": [
        {
         "Effect": "Allow",
         "Action": "glue:*",
         "Resource": "*",
         "Condition": {
             "StringEquals": {
                "aws:ResourceTag/Name": "Tom"
              }
          }
         }
    ]
}

Wenn Tom versucht, auf den Auslöser t1 zuzugreifen, erhält er die Meldung, dass ihm der Zugriff verweigert wurde. Er kann aber den Auslöser t2 erfolgreich abrufen.

aws glue get-trigger --name t1

An error occurred (AccessDeniedException) when calling the GetTrigger operation: User: Tom is not authorized to perform: glue:GetTrigger on resource: arn:aws:glue:us-east-1:123456789012:trigger/t1

aws glue get-trigger --name t2
{
    "Trigger": {
        "State": "CREATED",
        "Type": "SCHEDULED",
        "Name": "t2",
        "Actions": [
            {
                "JobName": "j1"
            }
        ],
        "Schedule": "cron(0 0/1 * * ? *)"
    }
}

Tom kann den pluralen GetTriggers-API-Vorgang zum Auflisten von Auslösern nicht verwenden, da dieser Vorgang keine Filterung nach Tags unterstützt.

Um Tom Zugriff auf GetTriggers zu gewähren, erstellt der AWS Glue-Administrator eine Richtlinie, die die Berechtigungen in zwei Abschnitte unterteilt. Ein Abschnitt gewährt Tom Zugriff auf alle Auslöser mit der GetTriggers-API-Operation. Der zweite Abschnitt gewährt Tom Zugriff auf API-Operationen, die mit dem Wert Tom markiert sind. Mit dieser Richtlinie wird Tom sowohl Zugriff auf GetTriggers als auch auf GetTrigger gewährt, um auf den Auslöser t2 zuzugreifen.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "glue:GetTriggers",
            "Resource": "*"
        },
        {
            "Effect": "Allow",
            "Action": "glue:*",
            "Resource": "*",
            "Condition": {
                "StringEquals": {
                    "aws:ResourceTag/Name": "Tom"
                }
            }
        }
    ]
}

Zugriff mit Tags verweigern

Ein anderer Ansatz einer Ressourcenrichtlinie besteht darin, den Zugriff auf Ressourcen ausdrücklich zu verweigern.

In der folgenden Beispielrichtlinie sind alle AWS Glue-Auftragsvorgänge zulässig. Die zweite Effect-Aussage verweigert jedoch ausdrücklich den Zugriff auf Aufträge, die mit dem Team-Schlüssel und dem Special-Wert gekennzeichnet sind.

Wenn ein Administrator einer Identität die folgende Richtlinie zuordnet, kann die Identität auf alle Aufträge zugreifen, mit Ausnahme derjenigen, die mit dem Team-Schlüssel und dem Special-Wert gekennzeichnet sind.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "glue:*",
      "Resource": "arn:aws:glue:us-east-1:123456789012:job/*"
    },
    {
      "Effect": "Deny",
      "Action": "glue:*",
      "Resource": "arn:aws:glue:us-east-1:123456789012:job/*",
      "Condition": {
        "StringEquals": {
          "aws:ResourceTag/Team": "Special"
        }
      }
    }
  ]
}

Verwendung von Tags mit Listen- und Batch-API-Vorgängen

Ein dritter Ansatz für das Schreiben einer Ressourcenrichtlinie besteht darin, den Zugriff auf Ressourcen mithilfe einer List-API-Operation zum Auflisten von Ressourcen für einen Tag-Wert zuzulassen. Anschließend verwenden Sie die entsprechende Batch-API-Operation, um Zugriff auf Details zu spezifischen Ressourcen zu gewähren. Bei diesem Ansatz muss der Administrator nicht den Zugriff auf die pluralen API-Operationen GetCrawlers, GetDevEndpoints, GetJobs oder GetTriggers zulassen. Stattdessen können Sie das Auflisten der Ressourcen mit den folgenden API-Operationen gewähren:

Und Sie können das Anfordern von Details zu einzelnen Ressourcen mit den folgenden API-Operationen gewähren:

Um diesen Ansatz zu nutzen, können Sie als Administrator wie folgt vorgehen:

Wenn Sie beispielsweise die ListCrawlers-Operation aufrufen, geben Sie einen Tag-Wert ein, der dem Benutzernamen entspricht. Das Ergebnis ist dann eine Liste der Crawler, die mti den angegebenen Tag-Werten übereinstimmen. Stellen Sie BatchGetCrawlers die Liste mit den Namen der Crawler zur Verfügung, um detaillierte Informationen zu jedem Crawler mit dem angegebenen Tag zu erhalten.

Wenn es Tom beispielsweise möglich sein soll, Details zu Auslösern abzurufen, die mit Tom markiert sind, kann der Administrator Tags zu Auslösern für Tom hinzufügen, allen Benutzern den Zugriff auf die GetTriggers-API-Operation verweigern und allen Benutzern den Zugriff auf ListTriggers und BatchGetTriggers gewähren.

Hier ist die Ressourcen-Richtlinie, die der AWS Glue-Administrator Tom gewährt. Im ersten Teil der Richtlinie werden AWS Glue-API-Operationen für GetTriggers verweigert. Im zweiten Teil der Richtlinie wird ListTriggers für alle Ressourcen gewährt. Im dritten Teil wird den durch Tom markierten Ressourcen jedoch Zugriff mit BatchGetTriggers-Zugriff gewährt.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Deny",
            "Action": "glue:GetTriggers",
            "Resource": "*"
        },
        {
            "Effect": "Allow",
            "Action": [
                "glue:ListTriggers"
            ],
            "Resource": [
                "*"
            ]
        },
        {
            "Effect": "Allow",
            "Action": [
                "glue:BatchGetTriggers"
            ],
            "Resource": [
                "*"
            ],
            "Condition": {
                "StringEquals": {
                    "aws:ResourceTag/Name": "Tom"
                }
            }
        }
    ]
}

Unter Verwendung der gleichen Auslöser wie im vorherigen Beispiel kann Tom auf den Auslöser t2, aber nicht auf den Auslöser t1 zugreifen. Das folgende Beispiel zeigt die Ergebnisse, wenn Tom versucht, mit BatchGetTriggers auf t1 und t2 zuzugreifen.

aws glue batch-get-triggers --trigger-names t2
{
    "Triggers": {
        "State": "CREATED",
        "Type": "SCHEDULED",
        "Name": "t2",
        "Actions": [
            {
                "JobName": "j2"
            }
        ],
        "Schedule": "cron(0 0/1 * * ? *)"
    }
}

aws glue batch-get-triggers  --trigger-names t1

An error occurred (AccessDeniedException) when calling the BatchGetTriggers operation: No access to any requested resource.

Das folgende Beispiel zeigt die Ergebnisse, wenn Tom in demselben BatchGetTriggers-Aufruf versucht, sowohl auf den Auslöser t2 als auch auf den Auslöser t3 (nicht vorhanden) zuzugreifen. Beachten Sie, dass nur t2 zurückgegeben wird, da Tom Zugriff auf Auslöser t2 hat und dieser vorhanden ist. Obwohl Tom auf Auslöser t3 zugreifen darf, wird t3 in der Antwort in einer Liste von "TriggersNotFound": [] zurückgegeben, da Auslöser t3 nicht vorhanden ist.

aws glue batch-get-triggers --trigger-names t2 t3
{
    "Triggers": {
        "State": "CREATED",
        "Type": "SCHEDULED",
        "Name": "t2",
        "Actions": [
            {
                "JobName": "j2"
            }
        ],
        "TriggersNotFound": ["t3"],
        "Schedule": "cron(0 0/1 * * ? *)"
    }
}

Einstellungen über Bedingungsschlüssel oder Kontextschlüssel steuern

Sie können Bedingungsschlüssel oder Kontextschlüssel verwenden, wenn Sie Berechtigungen zum Erstellen und Aktualisieren von Aufträgen erteilen. In diesen Abschnitten werden die Schlüssel behandelt:

Steuern von Richtlinien, die Einstellungen über Bedingungsschlüssel steuern

AWS Glue liefert drei IAM-Bedingungsschlüssel – glue:VpcIds, glue:SubnetIds und glue:SecurityGroupIds. Sie können die Bedingungsschlüssel in IAM-Richtlinien verwenden, wenn Sie Berechtigungen zum Erstellen und Aktualisieren von Aufträgen erteilen. Mit dieser Einstellung können Sie sicherstellen, dass Aufträge oder Sitzungen nicht für die Ausführung außerhalb einer gewünschten VPC-Umgebung erstellt (oder aktualisiert) werden. Die Informationen zu den VPC-Einstellungen stammen nicht direkt aus der CreateJob-Anfrage, sondern werden aus dem Auftragsfeld „connections“ abgeleitet, das auf eine AWS Glue-Verbindung verweist.

Beispielverwendung

Erstellen einer AWS Glue-Netzwerktypverbindung mit dem Namen „traffic-monitored-connection“ mit der gewünschten VpcId „vpc-id1234", SubnetIds und SecurityGroupIds.

Geben Sie die Bedingungsschlüssel-Bedingung für die CreateJob-und UpdateJob-Aktion in der IAM-Richtlinie.

{
  "Effect": "Allow",
  "Action": [
    "glue:CreateJob",
    "glue:UpdateJob"
  ],
  "Resource": [
    "*"
  ],
  "Condition": {
    "ForAnyValue:StringLike": {
      "glue:VpcIds": [
        "vpc-id1234"
      ]
    }
  }
}

Sie können eine ähnliche IAM-Richtlinie erstellen, um das Erstellen eines AWS Glue-Auftrags ohne Angabe von Verbindungsinformationen zu verhindern.

Einschränken von Sitzungen in VPCs

Um die Ausführung erstellter Sitzungen innerhalb einer bestimmten VPC zu erzwingen, schränken Sie die Rollenberechtigung ein, indem Sie einen Deny-Effekt auf die glue:CreateSession-Aktion hinzufügen, mit der Bedingung, dass „glue:vpc-id“ nicht gleich „vpc-<123>“ ist. Beispiel:

"Effect": "Deny",
"Action": [
    "glue:CreateSession"
 ],
"Condition": {
    "StringNotEquals" : {"glue:VpcIds" : ["vpc-123"]} 
}               
               

Sie können auch erzwingen, dass erstellte Sitzungen innerhalb einer VPC ausgeführt werden, indem Sie einen Deny-Effekt auf die glue:CreateSession-Aktion mit der Bedingung hinzufügen, dass das glue:vpc-id Null ist. Beispiel:

{
    "Effect": "Deny",
    "Action": [
        "glue:CreateSession"
    ],
      "Condition": {
        "Null": {"glue:VpcIds": true}
    }
}, 
{
    "Effect": "Allow",
    "Action": [
        "glue:CreateSession"
    ],
    "Resource": ["*"]
}             
               

Steuern von Richtlinien, die Einstellungen über Kontextschlüssel steuern

AWS Glue bietet einen Kontextschlüssel (glue:CredentialIssuingService= glue.amazonaws.com) zu jeder Rollensitzung die, AWS Glue dem Auftrags- und Entwicklerendpunkt zur Verfügung stellt. So können Sie Sicherheitskontrollen für die von AWS Glue-Skripten durchgeführten Aktionen implementieren. AWS Glue stellt einen weiteren Kontextschlüssel (glue:RoleAssumedBy=glue.amazonaws.com) für jede Rollensitzung bereit, wobei AWS Glue im Namen des Kunden einen anderen AWS-Service aufruft (nicht über einen Auftrags-/Entwicklungsendpunkt, sondern direkt über den AWS Glue-Service).

Beispielverwendung

Geben Sie die bedingte Berechtigung in einer IAM-Richtlinie an und fügen Sie diese an die Rolle an, die von einem AWS Glue-Auftrag verwendet wird. Dies stellt sicher, dass bestimmte Aktionen erlaubt/verweigert werden, basierend darauf, ob die Rollensitzung für eine AWS Glue-Auftragsausführungsumgebung verwendet wird.

{
    "Effect": "Allow",
    "Action": "s3:GetObject",
    "Resource": "arn:aws:s3:::confidential-bucket/*",
    "Condition": {
        "StringEquals": {
            "glue:CredentialIssuingService": "glue.amazonaws.com"
        }
    }
}

Einer Identität die Möglichkeit verweigern, Datenvorschau-Sitzungen zu erstellen

Dieser Abschnitt enthält ein Beispiel für eine IAM-Richtlinie, mit der einer Identität die Möglichkeit verweigert wird, Datenvorschau-Sitzungen zu erstellen. Verknüpfen Sie diese Richtlinie mit der Identität, die unabhängig von der Rolle ist, die die Datenvorschau-Sitzung während ihrer Ausführung verwendet.

{
    "Sid": "DatapreviewDeny",
    "Effect": "Deny",
     "Action": [
           "glue:CreateSession"
     ],
     "Resource": [
          "arn:aws:glue:*:*:session/glue-studio-datapreview*"
      ]
 }