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 Glue AWS
Standardmäßig sind Benutzer und Rollen nicht berechtigt, AWS Glue-Ressourcen zu erstellen oder zu ändern. Sie können auch keine Aufgaben mithilfe der AWS Management Console, AWS Command Line Interface (AWS CLI) oder 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 (Konsole) im IAM-Benutzerhandbuch.
Einzelheiten zu den von AWS Glue definierten Aktionen und Ressourcentypen, einschließlich des Formats von ARNs für jeden der Ressourcentypen, finden Sie unter Aktionen, Ressourcen und Bedingungsschlüssel für AWS Glue in der Service Authorization Reference.
Anmerkung
Die Beispiele in diesem Abschnitt verwenden alle die us-west-2
-Region. Sie können dies durch die AWS Region ersetzen, die Sie verwenden möchten.
Themen
Berechtigungen auf Ressourcenebene gelten nur für bestimmte AWS Glue-Objekte
Gewähren der Berechtigung zur Anzeige der eigenen Berechtigungen für Benutzer
Vollständiger Zugriff auf eine Tabelle und alle Partitionen gewähren
Steuerung des Zugriffs über Namenspräfix und explizites Verweigern
Einstellungen über Bedingungsschlüssel oder Kontextschlüssel steuern
Einer Identität die Möglichkeit verweigern, Datenvorschau-Sitzungen zu erstellen
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:
-
Beginnen Sie mit AWS verwalteten Richtlinien und wechseln Sie zu Berechtigungen mit den geringsten Rechten — Verwenden Sie die AWS verwalteten Richtlinien, die Berechtigungen für viele gängige Anwendungsfälle gewähren, um damit zu beginnen, Ihren Benutzern und Workloads Berechtigungen zu gewähren. Sie sind in Ihrem verfügbar. AWS-Konto Wir empfehlen Ihnen, die Berechtigungen weiter zu reduzieren, indem Sie vom AWS Kunden verwaltete Richtlinien definieren, die speziell auf Ihre Anwendungsfälle zugeschnitten sind. Weitere Informationen finden Sie unter AWS -verwaltete Richtlinien oder AWS -verwaltete Richtlinien für Auftrags-Funktionen im IAM-Benutzerhandbuch.
-
Anwendung von Berechtigungen mit den geringsten Rechten – Wenn Sie mit IAM-Richtlinien Berechtigungen festlegen, gewähren Sie nur die Berechtigungen, die für die Durchführung einer Aufgabe erforderlich sind. Sie tun dies, indem Sie die Aktionen definieren, die für bestimmte Ressourcen unter bestimmten Bedingungen durchgeführt werden können, auch bekannt als die geringsten Berechtigungen. Weitere Informationen zur Verwendung von IAM zum Anwenden von Berechtigungen finden Sie unter Richtlinien und Berechtigungen in IAM im IAM-Benutzerhandbuch.
-
Verwenden von Bedingungen in IAM-Richtlinien zur weiteren Einschränkung des Zugriffs – Sie können Ihren Richtlinien eine Bedingung hinzufügen, um den Zugriff auf Aktionen und Ressourcen zu beschränken. Sie können beispielsweise eine Richtlinienbedingung schreiben, um festzulegen, dass alle Anforderungen mithilfe von SSL gesendet werden müssen. Sie können auch Bedingungen verwenden, um Zugriff auf Serviceaktionen zu gewähren, wenn diese für einen bestimmten Zweck verwendet werden AWS-Service, z. AWS CloudFormation B. Weitere Informationen finden Sie unter IAM-JSON-Richtlinienelemente: Bedingung im IAM-Benutzerhandbuch.
-
Verwenden von IAM Access Analyzer zur Validierung Ihrer IAM-Richtlinien, um sichere und funktionale Berechtigungen zu gewährleisten – IAM Access Analyzer validiert neue und vorhandene Richtlinien, damit die Richtlinien der IAM-Richtliniensprache (JSON) und den bewährten IAM-Methoden entsprechen. IAM Access Analyzer stellt mehr als 100 Richtlinienprüfungen und umsetzbare Empfehlungen zur Verfügung, damit Sie sichere und funktionale Richtlinien erstellen können. Weitere Informationen finden Sie unter Richtlinienvalidierung mit IAM Access Analyzer im IAM-Benutzerhandbuch.
-
Multi-Faktor-Authentifizierung (MFA) erforderlich — Wenn Sie ein Szenario haben, das IAM-Benutzer oder einen Root-Benutzer in Ihrem System erfordert AWS-Konto, aktivieren Sie MFA für zusätzliche Sicherheit. Um MFA beim Aufrufen von API-Vorgängen anzufordern, fügen Sie Ihren Richtlinien MFA-Bedingungen hinzu. Weitere Informationen finden Sie unter Sicherer API-Zugriff mit MFA im IAM-Benutzerhandbuch.
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 Resource Names (ARNs) für die Resource
Anweisung zulassen, nicht mit API-Vorgängen vermischt werden, die dies nicht zulassen ARNs.
Beispiel: Die folgende IAM-Richtlinie lässt API-Operationen für GetClassifier
und GetJobRun
zu. Sie definiert das Resource
als*
, weil Klassifikatoren und ARNs Jobausführungen AWS Glue nicht zulässig sind. Weil für bestimmte API-Operationen wie GetDatabase
und zulässig ARNs sindGetTable
, ARNs können sie in der zweiten Hälfte der Richtlinie angegeben werden.
Eine Liste der AWS Glue Objekte, die dies zulassen ARNs, finden Sie unterAWS GlueRessource angeben ARNs.
Verwenden der AWS Glue-Konsole
Um auf die AWS Glue-Konsole zugreifen zu können, benötigen Sie ein Mindestmaß an Berechtigungen. Diese Berechtigungen müssen es Ihnen ermöglichen, Details zu den AWS Glue-Ressourcen in Ihrem aufzulisten und anzuzeigen AWS-Konto. 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.
Sie müssen Benutzern, die nur die API AWS CLI oder die AWS API aufrufen, keine Mindestberechtigungen für die Konsole gewähren. 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 die AWS Glue-Konsole weiterhin verwenden können, fügen Sie den Entitäten auch die AWS Glue
- oder ConsoleAccess
AWS verwaltete Richtlinie hinzu. Weitere Informationen finden Sie unter Hinzufügen von Berechtigungen zu einem Benutzer im IAM-Benutzerhandbuch.ReadOnly
Damit ein Benutzer mit der AWS Glue Konsole arbeiten kann, muss er über Mindestberechtigungen verfügen, die es ihm ermöglichen, mit den AWS Glue Ressourcen für sein AWS Konto zu arbeiten. Zusätzlich zu diesen AWS Glue-Berechtigungen erfordert die Konsole Berechtigungen von den folgenden Services:
-
Amazon CloudWatch Logs-Berechtigungen zum Anzeigen von Protokollen.
-
AWS Identity and Access Management (IAM) -Berechtigungen zum Auflisten und Weitergeben von Rollen.
-
AWS CloudFormation Berechtigungen zum Arbeiten mit Stacks.
-
Amazon Elastic Compute Cloud (Amazon EC2) -Berechtigungen für Listen VPCs, Subnetze, Sicherheitsgruppen, Instances und andere Objekte.
-
Amazon Simple Storage Service (Amazon S3)-Berechtigungen zum Auflisten von Buckets und Objekten sowie zum Abrufen und Speichern von Skripts.
-
Amazon-Redshift-Berechtigungen für die Arbeit mit Clustern.
-
Amazon Relational Database Service (Amazon RDS)-Berechtigungen zum Auflisten von Instances.
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 beinhaltet Berechtigungen, um diese Aktion auf der Konsole oder programmgesteuert mithilfe der AWS CLI API oder durchzuführen. AWS
{ "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 Ressource Amazon Resource Names (ARNs) finden Sie unterDatenkatalog ARNs.
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
:
Filtern Sie Tabellen nach GetTables Berechtigungen
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).
Sie können die vorhergehende Richtlinie vereinfachen, indem Sie store*
angeben und so alle Tabellennamen einschließen, die mit store
beginnen.
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.
Wird kein Tabellen-ARN angegeben, ist ein Aufruf von GetTables
erfolgreich, aber es wird eine leere Liste zurückgegeben.
Wenn der Datenbank-ARN in der Richtlinie fehlt, schlägt ein Aufruf von GetTables
mit einer AccessDeniedException
fehl.
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.
Die vorhergehende Richtlinie kann in der Praxis vereinfacht werden.
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
Nehmen wir in diesem Beispiel an, dass die Datenbanken und Tabellen in Ihrem AWS Glue-Datenkatalog anhand von 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, UDFs Tabellen usw. zu gewähren, die das dev-
Präfix haben. Aber Sie gewähren Lesezugriff auf alle Elemente mit dem Präfix 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.
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.
Zugriff mit Tags verweigern
Ein anderer Ansatz einer Ressourcenrichtlinie besteht darin, den Zugriff auf Ressourcen ausdrücklich zu verweigern.
Wichtig
Eine explizite Verweigerungsrichtlinie funktioniert nicht für plurale APIs wie GetTriggers
.
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.
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:
-
ListCrawlers
-
ListDevEndpoints
-
ListJobs
-
ListTriggers
Und Sie können das Anfordern von Details zu einzelnen Ressourcen mit den folgenden API-Operationen gewähren:
-
BatchGetCrawlers
-
BatchGetDevEndpoints
-
BatchGetJobs
-
BatchGetTriggers
Um diesen Ansatz zu nutzen, können Sie als Administrator wie folgt vorgehen:
-
Hinzufügen von Tags zu Ihren Crawlern, Entwicklungsendpunkten, Aufträgen und Auslösern.
-
Verweigern des Benutzerzugriffs auf
Get
-API-Operationen wieGetCrawlers
,GetDevEndponts
,GetJobs
undGetTriggers
. -
Damit Benutzer herauszufinden können, auf welche markierten Ressourcen sie zugreifen können, lassen Sie den Benutzerzugriff auf
List
-API-Operationen wieListCrawlers
,ListDevEndponts
,ListJobs
undListTriggers
zu. -
Verweigern Sie Benutzern den Zugriff auf AWS Glue Tagging APIs, z. B.
TagResource
undUntagResource
. -
Gewähren des Benutzerzugriffs auf Ressourcendetails mit
BatchGet
-API-Operationen wieBatchGetCrawlers
,BatchGetDevEndponts
,BatchGetJobs
undBatchGetTriggers
.
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.
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 bietet drei IAM-Zustandsschlüssel glue:VpcIds
glue:SubnetIds
, undglue: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 Sie eine AWS Glue Netzwerkverbindung mit dem Namen "traffic-monitored-connection" mit den gewünschten Werten VpcId „vpc-id1234", und. SubnetIds 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.
Beschränken von Sitzungen auf 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. Zum 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. Zum 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 stellt für jede Rollensitzung einen Kontextschlüssel (glue:CredentialIssuingService=
glue.amazonaws.com
) bereit, AWS Glue der für den Job und den Entwickler-Endpunkt verfügbar ist. Auf diese Weise können Sie Sicherheitskontrollen für die von AWS Glue Skripten ausgeführten Aktionen implementieren. AWS Gluestellt für jede Rollensitzung, in AWS Glue der im Namen des Kunden (nicht über einen job/dev Endpunkt, sondern direkt durch den AWS Serviceglue:RoleAssumedBy=glue.amazonaws.com
) ein anderer Service angerufen wird, einen weiteren Kontextschlüssel () bereit. AWS Glue
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. Dadurch wird sichergestellt, dass bestimmte Aktionen davon allowed/denied abhängen, ob die Rollensitzung für eine AWS Glue Job-Laufzeitumgebung verwendet wird.
{ "Effect": "Allow", "Action": "s3:GetObject", "Resource": "arn:aws:s3:::amzn-s3-demo-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*" ] }