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 gestite dal cliente
Puoi creare le tue politiche IAM personalizzate per consentire le autorizzazioni per CodeCommit azioni e risorse. Puoi associare queste policy personalizzate agli utenti o ai gruppi IAM che richiedono tali autorizzazioni. Puoi anche creare politiche IAM personalizzate per l'integrazione tra CodeCommit e altri AWS servizi.
Esempi di politiche di identità gestite dal cliente
L'esempio seguente: le politiche IAM concedono le autorizzazioni per varie CodeCommit azioni. Usali per limitare CodeCommit l'accesso per i tuoi utenti e ruoli IAM. Queste policy controllano la capacità di eseguire azioni con la CodeCommit console, l'API, AWS gli SDK o il AWS CLI.
Nota
Tutti gli esempi utilizzano la Regione Stati Uniti occidentali (Oregon) (us-west-2) e contengono ID account fittizi.
Esempi
Esempio 1: consenti a un utente di eseguire CodeCommit operazioni in un unico Regione AWS
La seguente politica di autorizzazione utilizza un carattere jolly ("codecommit:*") per consentire agli utenti di eseguire tutte le CodeCommit azioni nella regione us-east-2 e non da altre. Regioni AWS
Esempio 2: consenti a un utente di usare Git per un singolo repository
In CodeCommit, le autorizzazioni della policy GitPull IAM si applicano a qualsiasi comando del client Git da cui vengono recuperati i dati CodeCommit, inclusi git fetchgit clone, e così via. Allo stesso modo, le autorizzazioni della policy GitPush IAM si applicano a qualsiasi comando client Git a cui vengono inviati i dati. CodeCommit Ad esempio, se l'autorizzazione della policy GitPush IAM è impostata suAllow, un utente può richiedere l'eliminazione di un ramo utilizzando il protocollo Git. Tale push non è influenzato dalle autorizzazioni applicate all'DeleteBranchoperazione per quell'utente IAM. L'DeleteBranchautorizzazione si applica alle azioni eseguite con la console AWS CLI, gli SDK e l'API, ma non il protocollo Git.
L'esempio seguente consente all'utente specificato di eseguire il pull e il push al CodeCommit repository denominato: MyDemoRepo
Esempio 3: consentire a un utente che si connette da un intervallo di indirizzi IP specificato di accedere a un repository
Puoi creare una policy che consente agli utenti di connettersi a un repository CodeCommit se il loro indirizzo IP rientra in un determinato intervallo di indirizzi IP. Sono disponibili due approcci altrettanto validi a questo scopo. È possibile creare una Deny policy che impedisca CodeCommit le operazioni se l'indirizzo IP dell'utente non si trova all'interno di un blocco specifico oppure è possibile creare una Allow policy che consenta CodeCommit le operazioni se l'indirizzo IP dell'utente si trova all'interno di un blocco specifico.
Puoi creare una policy Deny che rifiuta l'accesso a tutti gli utenti non inclusi in un determinato intervallo di indirizzi IP. Ad esempio, puoi collegare la policy gestita AWSCodeCommitPowerUser e una policy gestita dal cliente a tutti gli utenti che richiedono l'accesso al repository. Il seguente criterio di esempio nega tutte le CodeCommit autorizzazioni agli utenti i cui indirizzi IP non rientrano nel blocco di indirizzi IP specificato di 203.0.113. 0/16:
La seguente policy di esempio consente all'utente specificato di accedere a un CodeCommit repository denominato MyDemoRepo con le autorizzazioni equivalenti della policy AWSCodeCommitPowerUser gestita solo se il suo indirizzo IP si trova all'interno del blocco di indirizzi specificato di 203.0.113. 0/16:
Esempio 4: negare o consentire azioni sulle filiali
Puoi creare una policy che rifiuta agli utenti le autorizzazioni per eseguire le operazioni specificate su uno o più rami. In alternativa, puoi creare una policy che consente di eseguire operazioni su uno o più rami che altrimenti non sarebbero consentite in altri rami di un repository. Puoi utilizzare queste policy con le policy gestite (predefinite) appropriate. Per ulteriori informazioni, consulta Limita i push e le unioni alle filiali in AWS CodeCommit.
Ad esempio, puoi creare una Deny policy che neghi agli utenti la possibilità di apportare modifiche a un ramo denominato main, inclusa l'eliminazione di quel ramo, in un repository denominato. MyDemoRepo Puoi usare questa policy con la policy gestita AWSCodeCommitPowerUser. Gli utenti con queste due politiche applicate sarebbero in grado di creare ed eliminare rami, creare richieste pull e tutte le altre azioni consentite da AWSCodeCommitPowerUser, ma non sarebbero in grado di inviare modifiche al ramo denominato main, aggiungere o modificare un file nel ramo principale nella CodeCommit console o unire rami o una richiesta pull nel ramo principale. Poiché la policy Deny viene applicata a GitPush, devi includervi un'istruzione Null per consentire l'analisi della validità delle chiamate GitPush iniziali quando gli utenti eseguono push dai loro repository locali.
Suggerimento
Se desideri creare una policy che si applichi a tutti i rami denominati main in tutti i repository del tuo account Amazon Web ServicesResource, specifica un asterisco (*) anziché un ARN del repository.
La seguente policy di esempio consente a un utente di apportare modifiche a un ramo denominato main in tutti i repository di un account Amazon Web Services. Non consente modifiche ad altre filiali. È possibile utilizzare questa policy con la policy AWSCodeCommitReadOnly gestita per consentire i push automatici al repository nel branch principale. Poiché l'effetto è Allow, questa policy di esempio non funzionerebbe con le policy gestite come AWSCodeCommitPowerUser.
Esempio 5: negare o consentire azioni sui repository con tag
È possibile creare una policy che consenta o neghi le azioni sui repository in base ai AWS tag associati a tali repository e quindi applicare tali policy ai gruppi IAM configurati per la gestione degli utenti IAM. Ad esempio, puoi creare una policy che neghi tutte le CodeCommit azioni su qualsiasi repository con la chiave del AWS tag Status e il valore chiave Secret, quindi applicare tale policy al gruppo IAM che hai creato per gli sviluppatori generici (). Developers Devi quindi assicurarti che gli sviluppatori che lavorano su quei repository con tag non siano membri di quel Developers gruppo generale, ma appartengano invece a un gruppo IAM diverso a cui non è applicata la politica restrittiva (). SecretDevelopers
L'esempio seguente nega tutte le CodeCommit azioni sui repository contrassegnati con la chiave Status e il valore chiave Secret:
È possibile perfezionare ulteriormente questa strategia specificando i repository specifici, anziché tutti i repository, come risorse. Puoi anche creare politiche che consentano CodeCommit azioni su tutti i repository che non sono contrassegnati con tag specifici. Ad esempio, la seguente politica consente l'equivalente delle AWSCodeCommitPowerUser autorizzazioni per CodeCommit le azioni, tranne per il fatto che consente solo CodeCommit azioni sui repository non contrassegnati con i tag specificati:
Nota
Questo esempio di politica include solo azioni per. CodeCommit Non include azioni per altri AWS servizi inclusi nella politica AWSCodeCommitPowerUser gestita. Per ulteriori informazioni, consulta AWS politica gestita: AWSCodeCommitPowerUser..
