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à.
Utilizzando la politica delle autorizzazioni verificate di Amazon, memorizza gli alias nelle operazioni API
Qualsiasi operazione di Amazon Verified Permissions che accetta un policyStoreId parametro, ad esempio IsAuthorized, e IsAuthorizedWithToken GetPolicyStore, può accettare un nome alias di policy store al posto dell'ID del policy store.
Importante
Quando utilizzi un alias del policy store come valore di un policyStoreId parametro, devi includere il prefisso. policy-store-alias/ Ad esempio, usapolicy-store-alias/example-policy-store, not. example-policy-store
Utilizzo degli alias del Policy store in Operations
Il IsAuthorized comando seguente utilizza un alias di policy store con il nome example-policy-store per identificare un policy store.
Nota
Non è possibile utilizzare un alias del policy store al posto del policyStoreId campo per l'DeletePolicyStoreoperazione.
Utilizzo degli alias del Policy store Across Regioni AWS
Uno degli usi più efficaci degli alias è nelle applicazioni eseguite in più Regioni AWS. Ad esempio, potresti avere un'applicazione globale che utilizza diversi archivi di policy in ogni regione.
-
In us-east-1, vuoi usare.
PSEXAMPLEabcdefg111111 -
In eu-west-1, vuoi usare.
PSEXAMPLEabcdefg222222
È possibile creare una versione diversa dell'applicazione in ciascuna regione o utilizzare un dizionario o un'istruzione switch per selezionare il policy store giusto per ciascuna regione. Ma è molto più semplice creare un alias del policy store con lo stesso nome alias del policy store in ogni regione. Ricorda che il nome dell'alias del policy store fa distinzione tra maiuscole e minuscole.
Quindi, usa l'alias del policy store nel tuo codice. Quando il codice viene eseguito in ciascuna regione, l'alias del policy store farà riferimento al policy store associato in quella regione.
Tuttavia, esiste il rischio che l'alias del policy store venga eliminato. In tal caso, i tentativi dell'applicazione di utilizzare il nome alias del policy store falliranno e potrebbe essere necessario ricreare o aggiornare l'alias del policy store. Per mitigare questo rischio, fai attenzione a concedere ai principali l'autorizzazione a gestire gli alias del policy store che utilizzi nell'applicazione.
Gli alias del Policy Store non sono un meccanismo di controllo del traffico
Un alias del policy store è un nome stabile e descrittivo per un policy store. Non è un meccanismo per spostare, suddividere o ponderare il traffico di autorizzazioni tra i policy store. Se conosci le funzionalità che indirizzano il traffico tra le versioni di una risorsa, come gli alias Lambda, tieni presente che gli alias dei policy store non si comportano allo stesso modo. In base alla progettazione, l'alias di un policy store è più vicino a un alias AWS KMS chiave: fornisce un nome duraturo per una risorsa, non un livello di routing che la precede.
Per questo motivo, intenzionalmente non forniamo un'operazione. UpdatePolicyStoreAlias Per modificare il policy store a cui fa riferimento un alias del policy store, è necessario eliminare l'alias del policy store e creare un nuovo alias del policy store con lo stesso nome e destinato a un policy store diverso. Non si tratta di un'operazione atomica e non fornisce le garanzie offerte da un meccanismo di controllo del traffico.
Quando si modifica il policy store in cui viene risolto l'alias del policy store, la modifica non ha effetto ovunque nello stesso istante:
-
La mappatura aggiornata deve propagarsi dal piano di controllo al piano dati che valuta le richieste di autorizzazione. La mappatura non si propaga istantaneamente.
-
Poiché la risoluzione degli alias del policy store è alla fine coerente e può essere memorizzata nella cache, dopo una modifica esiste una finestra di transizione. Durante questa finestra, il policy store associato in precedenza soddisfa alcune richieste e il nuovo policy store associato gestisce altre richieste. La lunghezza di questa finestra è indeterminata.
Durante questa finestra, l'applicazione può ricevere decisioni di autorizzazione da entrambi i policy store. Poiché diversi archivi di policy possono contenere policy, entità e schemi diversi, la stessa richiesta può produrre decisioni diverse a seconda del policy store utilizzato. Gli alias dei policy store non possono quindi fornire una separazione atomica tra i policy store e non sostituiscono una strategia di distribuzione o di gestione del traffico.
Non utilizzare gli alias come meccanismo di interruzione
Non create un'infrastruttura come codice o una primitiva di distribuzione di livello superiore che ripunti l'alias di un policy store per trasferire il traffico di autorizzazione da un policy store a un altro. Poiché la modifica non è atomica, le richieste possono essere autorizzate su entrambi i policy store contemporaneamente per un periodo indeterminato. Ciò può portare a decisioni di autorizzazione non coerenti. Per cambiare i policy store in modo sicuro, consultaEsecuzione di modifiche all'archivio delle politiche senza tempi di inattività.
Esecuzione di modifiche all'archivio delle politiche senza tempi di inattività
Poiché gli alias dei policy store non forniscono un limite atomico (vedereGli alias del Policy Store non sono un meccanismo di controllo del traffico), si consiglia di evitare la migrazione da un policy store a un altro indicando nuovamente un alias del policy store. Controllate invece la migrazione dall'interno dell'applicazione in modo da poter convalidare il nuovo policy store e ripristinarlo immediatamente, se necessario. L'approccio seguente consente di cambiare i policy store senza tempi di inattività:
-
Create il nuovo policy store e assegnategli il proprio alias, in modo che il policy store corrente e il nuovo policy store abbiano ciascuno un nome distinto e stabile. Ad esempio, continua a
policy-store-alias/example-policy-storepuntare al tuo attuale policy store e creapolicy-store-alias/example-policy-store-2per il nuovo policy store. Non riutilizzare o reindirizzare un singolo alias del policy store per eseguire il passaggio. -
Replica le policy, lo schema e qualsiasi altra configurazione nel nuovo policy store ed eseguilo parallelamente al policy store corrente.
-
Aggiungi un valore di configurazione o un flag di funzionalità all'applicazione (ad esempio, utilizzando AppConfig) che determini quale alias del policy store è autorevole per le decisioni di autorizzazione. Non affidatevi alla modifica dell'alias stesso per cambiare traffico.
-
Esegui il nuovo policy store in modalità shadow. Invia lo stesso documento
IsAuthorizedoIsAuthorizedWithTokenrichiedi a entrambi gli archivi di policy e confronta le decisioni. Registra ed esamina eventuali discrepanze finché il nuovo archivio di policy non restituirà le decisioni previste. -
Utilizzate il feature flag per spostare gradualmente le decisioni di autorizzazione sul nuovo alias del policy store, ad esempio in un'implementazione graduale tra gli host delle applicazioni o i segmenti di utenti. Monitora le decisioni di autorizzazione e i tassi di errore man mano che procedi.
-
Utilizza il flag di funzionalità per tornare immediatamente all'alias originale del policy store se rilevi un problema. Poiché l'applicazione controlla lo switch, il rollback è istantaneo e non dipende dalla propagazione degli alias.
-
Disattiva il vecchio policy store e il relativo policy store dopo che il nuovo policy store è stato completamente convalidato e serve tutto il traffico.
Questo modello consente all'applicazione, anziché alla propagazione degli alias, di controllare quale policy store serve ogni richiesta. Questo controllo è ciò che rende la migrazione sicura e reversibile ed evita la finestra di transizione che introdurrebbe il riposizionamento di un alias del policy store.
