Esempi di policy basate sull'identità per Glue AWS - AWS Glue

Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

Esempi di policy basate sull'identità per Glue AWS

Per impostazione predefinita, gli utenti e i ruoli non sono autorizzati a creare o modificare le risorse AWS Glue. Inoltre, non possono eseguire attività utilizzando AWS Management Console, AWS Command Line Interface (AWS CLI) o AWS API. Per concedere agli utenti il permesso di eseguire azioni sulle risorse di cui hanno bisogno, un IAM amministratore può creare IAM policy. L'amministratore può quindi aggiungere le IAM politiche ai ruoli e gli utenti possono assumerli.

Per informazioni su come creare una politica IAM basata sull'identità utilizzando questi documenti di esempio, consulta Create JSON IAM policy (console) nella Guida per l'IAMutente.

Per i dettagli sulle azioni e sui tipi di risorse definiti da AWS Glue, incluso il formato di ARNs per ogni tipo di risorsa, vedere Azioni, risorse e chiavi di condizione per AWS Glue nel riferimento di autorizzazione del servizio.

Nota

Gli esempi forniti in questa sezione utilizzano tutti la Regione us-west-2. Puoi sostituirlo con la AWS regione che desideri utilizzare.

Best practice per le policy

Le politiche basate sull'identità determinano se qualcuno può creare, accedere o eliminare le risorse AWS Glue nel tuo account. Queste azioni possono comportare costi aggiuntivi per l' Account AWS. Quando crei o modifichi policy basate su identità, segui queste linee guida e raccomandazioni:

  • Inizia con le policy AWS gestite e passa alle autorizzazioni con privilegi minimi: per iniziare a concedere autorizzazioni a utenti e carichi di lavoro, utilizza le politiche gestite che concedono le autorizzazioni per molti casi d'uso comuni.AWS Sono disponibili nel tuo. Account AWS Ti consigliamo di ridurre ulteriormente le autorizzazioni definendo politiche gestite dai AWS clienti specifiche per i tuoi casi d'uso. Per ulteriori informazioni, consulta le politiche AWS gestite o le politiche AWS gestite per le funzioni lavorative nella Guida per l'IAMutente.

  • Applica le autorizzazioni con privilegi minimi: quando imposti le autorizzazioni con le IAM politiche, concedi solo le autorizzazioni necessarie per eseguire un'attività. Puoi farlo definendo le azioni che possono essere intraprese su risorse specifiche in condizioni specifiche, note anche come autorizzazioni con privilegi minimi. Per ulteriori informazioni sull'utilizzo per applicare le autorizzazioni, consulta Politiche e autorizzazioni nella Guida IAM per l'utente. IAM IAM

  • Utilizza le condizioni nelle IAM politiche per limitare ulteriormente l'accesso: puoi aggiungere una condizione alle tue politiche per limitare l'accesso ad azioni e risorse. Ad esempio, puoi scrivere una condizione di policy per specificare che tutte le richieste devono essere inviate utilizzandoSSL. È inoltre possibile utilizzare condizioni per concedere l'accesso alle azioni di servizio se vengono utilizzate tramite uno specifico Servizio AWS, ad esempio AWS CloudFormation. Per ulteriori informazioni, consulta Elementi IAM JSON della politica: Condizione nella Guida IAM per l'utente.

  • Usa IAM Access Analyzer per convalidare IAM le tue policy e garantire autorizzazioni sicure e funzionali: IAM Access Analyzer convalida le policy nuove ed esistenti in modo che aderiscano al linguaggio delle IAM policy () e alle best practice. JSON IAM IAMAccess Analyzer fornisce più di 100 controlli delle politiche e consigli pratici per aiutarti a creare policy sicure e funzionali. Per ulteriori informazioni, consulta Convalida delle politiche con IAM Access Analyzer nella Guida per l'utente. IAM

  • Richiedi l'autenticazione a più fattori (MFA): se hai uno scenario che richiede l'utilizzo di IAM utenti o di un utente root Account AWS, attiva questa opzione MFA per una maggiore sicurezza. Per richiedere MFA quando vengono richiamate API le operazioni, aggiungi MFA delle condizioni alle tue politiche. Per ulteriori informazioni, consulta Secure API access with MFA nella Guida IAM per l'utente.

Per ulteriori informazioni sulle best practice inIAM, consulta la sezione Procedure consigliate in materia di sicurezza IAM nella Guida IAM per l'utente.

Le autorizzazioni a livello di risorsa si applicano solo a specifiche AWS Glue objects

È possibile definire un controllo granulare solo per oggetti specifici in AWS Glue. Pertanto, devi scrivere la IAM politica del tuo cliente in modo che API le operazioni che consentono Amazon Resource Names (ARNs) per l'Resourceistruzione non vengano mescolate con API operazioni che non lo consentonoARNs.

Ad esempio, la seguente IAM politica consente API operazioni per GetClassifier eGetJobRun. Definisce Resource come * perché AWS Glue non consente ARNs classificatori e cicli di lavoro. Perché ARNs sono consentiti per API operazioni specifiche come GetDatabase eGetTable, ARNs possono essere specificati nella seconda metà della politica.

{ "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" ] } ] }

Per un elenco di AWS Glue oggetti che lo consentonoARNs, vediAWS GlueSpecificare la risorsa ARNs.

Utilizzo della console AWS Glue

Per accedere alla console AWS Glue, devi disporre di un set minimo di autorizzazioni. Queste autorizzazioni devono consentirti di elencare e visualizzare i dettagli sulle risorse AWS Glue presenti nel tuo Account AWS. Se crei una policy basata sull'identità più restrittiva rispetto alle autorizzazioni minime richieste, la console non funzionerà nel modo previsto per le entità (utenti o ruoli) associate a tale policy.

Non è necessario concedere autorizzazioni minime per la console agli utenti che effettuano chiamate solo verso il AWS CLI o il. AWS API Consenti invece l'accesso solo alle azioni che corrispondono all'APIoperazione che stanno cercando di eseguire.

Per garantire che utenti e ruoli possano ancora utilizzare la console AWS Glue, collega anche AWS Glue ConsoleAccess o la policy ReadOnly AWS gestita alle entità. Per ulteriori informazioni, consulta Aggiungere autorizzazioni a un utente nella Guida per l'IAMutente.

Per consentire a un utente di utilizzare il AWS Glue console, quell'utente deve disporre di un set minimo di autorizzazioni che gli consenta di lavorare con AWS Glue risorse per il proprio AWS account. Oltre a queste AWS Glue autorizzazioni, la console richiede le autorizzazioni dei seguenti servizi:

  • Autorizzazioni Amazon CloudWatch Logs per visualizzare i log.

  • AWS Identity and Access Management (IAM) autorizzazioni per elencare e trasferire ruoli.

  • AWS CloudFormation autorizzazioni per lavorare con gli stack.

  • Autorizzazioni Amazon Elastic Compute Cloud (AmazonEC2) per elenchiVPCs, sottoreti, gruppi di sicurezza, istanze e altri oggetti.

  • Autorizzazioni Amazon Simple Storage Service (Amazon S3) per elencare bucket e oggetti e per recuperare e salvare script.

  • Autorizzazioni Amazon Redshift necessarie per l'utilizzo dei cluster.

  • Autorizzazioni Amazon Relational Database Service (RDSAmazon) per elencare le istanze.

Per ulteriori informazioni sulle autorizzazioni necessarie agli utenti per visualizzare e utilizzare il AWS Glue console, vediFase 3: Allegare una policy agli utenti o ai gruppi che accedono AWS Glue.

Se crei una IAM politica più restrittiva delle autorizzazioni minime richieste, la console non funzionerà come previsto per gli utenti con quella IAM politica. Per garantire che tali utenti possano ancora utilizzare il AWS Glue console, allega anche la policy AWSGlueConsoleFullAccess gestita come descritto inAWS politiche gestite (predefinite) per AWS Glue.

Consentire agli utenti di visualizzare le loro autorizzazioni

Questo esempio mostra come è possibile creare una politica che consenta IAM agli utenti di visualizzare le politiche in linea e gestite allegate alla propria identità utente. Questa politica include le autorizzazioni per completare questa azione sulla console o utilizzando o a livello di codice. AWS CLI 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": "*" } ] }

Concessione di autorizzazioni di sola lettura a una tabella

La policy seguente consente di concedere autorizzazioni di sola lettura per una tabella books nel database db1. Per ulteriori informazioni sulla risorsa Amazon Resource Names (ARNs), consultaCatalogo dati 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" ] } ] }

Questa policy consente di concedere autorizzazioni di sola lettura per una tabella books nel database denominato db1. Per concedere l'autorizzazione Get a una tabella è richiesta anche l'autorizzazione alle risorse del database e del catalogo.

La policy seguente concede il livello minimo di autorizzazioni necessarie per creare una tabella tb1 nel database 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" ] } ] }

Filtra le tabelle per GetTables autorizzazione

Supponiamo che ci siano tre tabelle (customers, stores e store_sales) nel database db1. La policy seguente concede l'autorizzazione GetTables a stores e store_sales, ma non a customers. Quando chiami GetTables con questa policy, il risultato contiene solo le due tabelle autorizzate (la tabella customers non viene restituita).

{ "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" ] } ] }

È possibile semplificare la policy precedente utilizzando store* per includere qualsiasi nome di tabella che inizi con store:

{ "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*" ] } ] }

Analogamente, utilizzando /db1/* per includere tutte le tabelle incluse nella cartella db1, la policy seguente concede l'autorizzazione GetTables a tutte le tabelle presenti in db1.

{ "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/*" ] } ] }

Se non ARN viene fornita alcuna tabella, una chiamata a GetTables ha esito positivo, ma restituisce un elenco vuoto.

{ "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" ] } ] }

Se il database non ARN è presente nella policy, una chiamata a ha GetTables esito negativo con unAccessDeniedException.

{ "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/*" ] } ] }

Concessione di accesso completo a una tabella e a tutte le partizioni

La policy seguente concede tutte le autorizzazioni su una tabella denominata books nel database db1. Questo include le autorizzazioni di lettura e scrittura sulla tabella stessa, sulle versioni archiviate e su tutte le partizioni.

{ "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" ] } ] }

Nella pratica, la policy precedente può essere semplificata:

{ "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" ] } ] }

tieni presente che il livello minimo di granularità del controllo degli accessi è a livello di tabella. Questo significa che non è possibile concedere a un utente l'accesso ad alcune partizioni in una tabella, ma non ad altre, o ad alcune colonne ma non ad altre. Un utente ha accesso a tutte le parti di una tabella o a nessuna.

Controllo degli accessi per nome prefisso e diniego esplicito

In questo esempio, supponiamo che i database e le tabelle del tuo AWS Glue Data Catalog siano organizzati utilizzando prefissi di nome. I database nella fase di sviluppo hanno il nome prefisso dev- e quelli in produzione hanno il nome prefisso prod-. È possibile utilizzare la seguente politica per concedere agli sviluppatori l'accesso completo a tutti i database, le tabelle e così via che hanno il prefisso. UDFs dev- Tuttavia, puoi anche concedere l'accesso in sola lettura a tutti gli elementi con il prefisso 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-*" ] } ] }

La seconda istruzione nella policy precedente utilizza il codice esplicito deny. Puoi utilizzare il codice esplicito deny per sovrascrivere qualsiasi autorizzazione allow concessa al principale. Questo consente di bloccare l'accesso a risorse critiche e a impedire a un'altra policy di concedere accidentalmente l'accesso a esse.

Nell'esempio precedente, anche se la prima istruzione concede l'accesso completo alle risorse prod-, la seconda istruzione revoca esplicitamente l'accesso in scrittura, mantenendo solo l'accesso in lettura alle risorse prod-.

Autorizzazione dell'accesso utilizzando tag

Supporre ad esempio che si voglia limitare l'accesso al trigger t2 a un utente specifico denominato Tom nel proprio account. Tutti gli altri utenti, tra cui Sam, hanno accesso al trigger t1. I trigger t1 e t2 hanno le seguenti proprietà.

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 * * ? *)" } ] }

Il AWS Glue l'amministratore ha aggiunto un valore di tag Tom (aws:ResourceTag/Name": "Tom") al triggert2. Il AWS Glue L'amministratore ha anche dato a Tom una IAM politica con una dichiarazione di condizione basata sul tag. Di conseguenza, Tom può usare solo un AWS Glue operazione che agisce sulle risorse con il valore del tagTom.

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

Quando Tom cerca di accedere al trigger t1 riceve un messaggio di accesso rifiutato. Allo stesso tempo, può recuperare regolarmente il trigger t2.

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 non può usare l'GetTriggersAPIoperazione plurale per elencare i trigger perché questa operazione non supporta il filtraggio sui tag.

Per dare accesso a Tom, il GetTriggers AWS Glue l'amministratore crea una politica che divide le autorizzazioni in due sezioni. Una sezione consente a Tom di accedere a tutti i trigger dell'operazione. GetTriggers API La seconda sezione consente a Tom di accedere alle API operazioni contrassegnate con il valoreTom. Con questa policy, a Tom è consentito l'accesso GetTriggers e GetTrigger al trigger t2.

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

Negazione dell'accesso utilizzando tag

Un altro approccio per una policy delle risorse consiste nel negare in modo esplicito l'accesso alle risorse.

Importante

Una politica di rifiuto esplicita non funziona per API operazioni plurali come. GetTriggers

Nel seguente esempio di politica, tutti AWS Glue le operazioni di lavoro sono consentite. Tuttavia, la seconda dichiarazione Effect nega esplicitamente l'accesso ai processi contrassegnati con la chiave Team e il valore Special.

Quando un amministratore collega le seguenti policy a un'identità, questa può accedere a tutti i processi tranne quelli contrassegnati con la chiave Team e il valore Special.

{ "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" } } } ] }

Usa i tag con API operazioni a elenco e in batch

Un terzo approccio alla scrittura di una politica delle risorse consiste nel consentire l'accesso alle risorse utilizzando un'ListAPIoperazione per elencare le risorse per un valore di tag. Quindi, utilizzate l'BatchAPIoperazione corrispondente per consentire l'accesso ai dettagli di risorse specifiche. Con questo approccio, l'amministratore non deve consentire l'accesso al pluraleGetCrawlers, GetDevEndpointsGetJobs, o GetTriggers API alle operazioni. È invece possibile consentire la possibilità di elencare le risorse con le seguenti API operazioni:

  • ListCrawlers

  • ListDevEndpoints

  • ListJobs

  • ListTriggers

Inoltre, puoi consentire la possibilità di ottenere dettagli sulle singole risorse con le seguenti API operazioni:

  • BatchGetCrawlers

  • BatchGetDevEndpoints

  • BatchGetJobs

  • BatchGetTriggers

In qualità di amministratore, per l'utilizzo di questo approccio, è possibile:

  1. Aggiungere i tag a crawler, endpoint di sviluppo, processi e trigger.

  2. Negare l'accesso degli utenti a Get API operazioni comeGetCrawlers, GetDevEndpontsGetJobs, eGetTriggers.

  3. Per consentire agli utenti di scoprire a quali risorse etichettate hanno accesso, consenti agli utenti di accedere a List API operazioni comeListCrawlers, ListDevEndpontsListJobs, eListTriggers.

  4. Negare l'accesso degli utenti a AWS Glue etichettaturaAPIs, ad esempio eTagResource. UntagResource

  5. Consenti agli utenti di accedere ai dettagli delle risorse con BatchGet API operazioni comeBatchGetCrawlers, BatchGetDevEndpontsBatchGetJobs, eBatchGetTriggers.

Ad esempio, quando si richiama l'operazione ListCrawlers, fornire un valore di tag che corrisponda al nome dell'utente. Quindi il risultato è un elenco di crawler corrispondenti ai valori di tag forniti. Fornisci l'elenco dei nomi a BatchGetCrawlers per ottenere informazioni dettagliate su ogni crawler con il tag specificato.

Ad esempio, se Tom deve essere in grado di recuperare solo i dettagli dei trigger etichettati conTom, l'amministratore può aggiungere tag ai trigger perTom, negare l'accesso all'GetTriggersAPIoperazione a tutti gli utenti e consentire l'accesso a tutti gli utenti a e. ListTriggers BatchGetTriggers

Di seguito è riportata la politica delle risorse che il AWS Glue l'amministratore concede a Tom. Nella prima sezione della politica, AWS Glue APIle operazioni sono negate perGetTriggers. Nella seconda sezione della policy, ListTriggers è consentito per tutte le risorse. Tuttavia, nella terza sezione, tali risorse con il tag Tom possono eseguire l'accesso BatchGetTriggers.

{ "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" } } } ] }

Usando gli stessi trigger dell'esempio precedente, Tom può accedere al trigger t2, ma non al trigger t1. L'esempio seguente mostra i risultati quando Tom cerca di accedere a t1 e t2 con BatchGetTriggers.

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.

L'esempio seguente mostra i risultati quando Tom cerca di accedere al trigger t2 e t3 (che non esiste) nella stessa chiamata BatchGetTriggers. Nota che poiché Tom ha accesso al trigger t2 esistente, viene restituito solo t2. Sebbene a Tom sia consentito accedere al trigger t3, il trigger t3 non esiste e pertanto t3 viene restituito nella risposta in un elenco di "TriggersNotFound": [].

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 * * ? *)" } }

Controllo delle impostazioni utilizzando le chiavi di condizione o di contesto

Quando si concedono le autorizzazioni per creare e aggiornare i processi, è possibile utilizzare le chiavi di condizione o le chiavi di contesto. Queste sezioni trattano le chiavi:

Policy di controllo che controllano le impostazioni utilizzando le chiavi di condizione

AWS Glue fornisce tre chiavi di IAM condizione glue:VpcIdsglue:SubnetIds, eglue:SecurityGroupIds. È possibile utilizzare le chiavi condizionali nelle IAM politiche per concedere le autorizzazioni per creare e aggiornare lavori. È possibile utilizzare questa impostazione per garantire che i lavori o le sessioni non vengano creati (o aggiornati) per essere eseguiti al di fuori dell'ambiente desideratoVPC. Le informazioni sull'VPCimpostazione non sono un input diretto dalla CreateJob richiesta, ma sono desunte dal campo «connessioni» del lavoro che punta a un AWS Glue connessione.

Esempio di utilizzo

Crea un AWS Glue tipo di connessione di rete denominata "traffic-monitored-connection" con il VpcId «vpc-id1234" desiderato, e. SubnetIds SecurityGroupIds

Specificare la condizione dei tasti condizionali per l'azione and nella politicaCreateJob. UpdateJob IAM

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

È possibile creare una IAM politica simile per vietare la creazione di un AWS Glue lavoro senza specificare le informazioni di connessione.

Limitazione delle sessioni su VPCs

<123>Per imporre l'esecuzione delle sessioni create entro un determinato periodoVPC, si limita l'autorizzazione del ruolo aggiungendo un Deny effetto sull'glue:CreateSessionazione a condizione che glue:vpc-id non sia uguale a vpc-. Per esempio:

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

È inoltre possibile imporre l'esecuzione delle sessioni create all'interno di a VPC aggiungendo un Deny effetto sull'glue:CreateSessionazione a condizione che sia nulla. glue:vpc-id Per esempio:

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

Policy di controllo che controllano le impostazioni utilizzando le chiavi di contesto

AWS Glue fornisce una chiave di contesto (glue:CredentialIssuingService= glue.amazonaws.com) per ogni sessione di ruolo che AWS Glue mette a disposizione dell'endpoint job e developer. Ciò consente di implementare controlli di sicurezza per le azioni intraprese da AWS Glue script. AWS Glue fornisce un'altra chiave di contesto (glue:RoleAssumedBy=glue.amazonaws.com) per ogni sessione di ruolo in cui AWS Glue effettua una chiamata a un altro AWS servizio per conto del cliente (non tramite un endpoint job/dev, ma direttamente dal AWS Glue servizio).

Esempio di utilizzo

Specificare l'autorizzazione condizionale in una IAM politica e associarla al ruolo che deve essere utilizzato da un AWS Glue lavoro. Ciò garantisce che determinate azioni siano consentite/negate a seconda che la sessione di ruolo venga utilizzata per un AWS Glue ambiente di esecuzione del lavoro.

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

Negare a un'identità la possibilità di creare sessioni di anteprima dei dati

Questa sezione contiene un esempio di IAM policy utilizzato per negare a un'identità la possibilità di creare sessioni di anteprima dei dati. Collega questa policy all'identità, che è distinta dal ruolo utilizzato dalla sessione di anteprima dei dati durante la sua esecuzione.

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