Esempi di policy basate sull'identità per Glue AWS

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à.

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à.

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 l'API. Per concedere agli utenti l'autorizzazione a eseguire operazioni sulle risorse di cui hanno bisogno, un amministratore IAM può creare policy IAM. L'amministratore può quindi aggiungere le policy IAM ai ruoli e gli utenti possono assumere i ruoli.

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

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.

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 operazioni possono comportare costi aggiuntivi per l' Account AWS. Quando crei o modifichi policy basate su identità, segui queste linee guida e raccomandazioni:

Per maggiori informazioni sulle best practice in IAM, consulta Best practice di sicurezza in IAM nella Guida per l'utente di IAM.

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 policy IAM del tuo cliente in modo che le operazioni API che consentono Amazon Resource Names (ARNs) per l'Resourceistruzione non vengano mescolate con le operazioni API che non lo consentono ARNs.

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

{
    "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 consentono ARNs, vediSpecificando AWS Glue 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 AWS CLI o l' AWS API. Al contrario, concedi l'accesso solo alle operazioni che corrispondono all'operazione API 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 Aggiunta di autorizzazioni a un utente nella Guida per l'utente IAM.

Affinché un utente possa lavorare con 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:

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

Se decidi di creare una policy IAM più restrittiva delle autorizzazioni minime richieste, la console non funzionerà come previsto per gli utenti con tale policy IAM. 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 in che modo è possibile creare una policy che consente agli utenti IAM di visualizzare le policy inline e gestite che sono cpllegate alla relativa identità utente. Questa politica include le autorizzazioni per completare questa azione sulla console o utilizzando l'API o a livello di codice. AWS CLI 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": "*"
        }
    ]
}

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 viene fornito nessun ARN di tabella, una chiamata a GetTables si conclude correttamente 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 la policy non contiene l'ARN del database, una chiamata a GetTables ha esito negativo e restituisce AccessDeniedException:

{
    "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 politica IAM 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'operazione dell'API GetTriggers plurale per elencare i trigger in quanto questa operazione non supporta il filtro sui tag.

Per dare accesso a TomGetTriggers, il 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 con l'operazione API GetTriggers. La seconda sezione consente a Tom di accedere alle operazioni API che sono contrassegnate con il valore Tom. 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.

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

Utilizzo di tag con operazioni API in elenco e in batch

Un terzo approccio per scrivere una policy basata sulle risorse consiste nel consentire l'accesso alle risorse utilizzando un'operazione API List per elencare le risorse corrispondenti a un dato valore di tag. Quindi, si utilizza l'operazione API Batch corrispondente per consentire l'accesso ai dettagli delle risorse specifiche. Con questo approccio, l'amministratore non ha bisogno di consentire l'accesso alle operazioni API GetCrawlers, GetDevEndpoints, GetJobs o GetTriggers plurali. Puoi invece consentire la possibilità di elencare le risorse con le seguenti operazioni API:

Puoi inoltre consentire la possibilità di ottenere i dettagli delle singole risorse con le seguenti operazioni API:

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

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 con il tag Tom, l'amministratore può aggiungere i tag ai trigger per Tom, rifiutare l'accesso all'operazione API GetTriggers a tutti gli utenti e consentire l'accesso di tutti gli utenti a ListTriggers e BatchGetTriggers.

Di seguito è riportata la politica delle risorse che il AWS Glue l'amministratore concede a Tom. Nella prima sezione della politica, AWS Glue Le operazioni API 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 glue:VpcIds di condizione IAM eglue:SecurityGroupIds. glue:SubnetIds Quando si concedono le autorizzazioni per creare e aggiornare i processi, è possibile utilizzare le chiavi di condizione nelle policy IAM. È possibile utilizzare questa impostazione per garantire che i processi o le sessioni non vengano creati (o aggiornati) per essere eseguiti al di fuori dell'ambiente VPC desiderato. Le informazioni sulle impostazioni del VPC non sono un input diretto dalla CreateJob richiesta, ma sono dedotte 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

Specifica la condizione delle chiavi di condizione per le operazioni CreateJob e UpdateJobnella policy IAM.

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

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

Limitazione delle sessioni su VPCs

Per imporre l'esecuzione delle sessioni create all'interno di un VPC specificato, puoi limitare l'autorizzazione del ruolo aggiungendo un effetto Deny all'operazione glue:CreateSession, a condizione che glue:vpc-id non sia uguale a vpc-<123>. Per esempio:

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

È inoltre possibile imporre l'esecuzione delle sessioni create all'interno di un VPC aggiungendo un effetto Deny all'operazione glue:CreateSession a condizione che glue:vpc-id sia nullo. 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 policy IAM e collegarla 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 policy IAM 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*"
      ]
 }