Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.
Uso de alias de almacenamiento de la política de permisos verificados de Amazon en las operaciones de la API
Cualquier operación de permisos verificados de Amazon que acepte un policyStoreId parámetro, como IsAuthorized, y IsAuthorizedWithToken GetPolicyStore, puede aceptar el nombre de un alias de la tienda de políticas en lugar del ID de la tienda de políticas.
importante
Cuando utilices un alias de un almacén de políticas como valor de un policyStoreId parámetro, debes incluir el policy-store-alias/ prefijo. Por ejemplo, usepolicy-store-alias/example-policy-store, noexample-policy-store.
Uso de los alias del almacén de políticas en Operations
El siguiente IsAuthorized comando usa un alias de almacén de políticas con el nombre example-policy-store para identificar un almacén de políticas.
nota
No puede usar un alias de almacén de políticas en lugar del policyStoreId campo de la DeletePolicyStore operación.
Uso de los alias del almacén de políticas en Across Regiones de AWS
Uno de los usos más potentes de los alias es en aplicaciones que se ejecutan en múltiples Regiones de AWS. Por ejemplo, es posible que tenga una aplicación global que utilice diferentes almacenes de políticas en cada región.
-
En us-east-1, quieres usar.
PSEXAMPLEabcdefg111111 -
En eu-west-1, quieres usar.
PSEXAMPLEabcdefg222222
Puedes crear una versión diferente de tu aplicación en cada región o usar un diccionario o una sentencia switch para seleccionar el almacén de políticas adecuado para cada región. Sin embargo, es mucho más fácil crear un alias de almacén de políticas con el mismo nombre de alias de almacén de políticas en cada región. Recuerde que el nombre del alias del almacén de políticas distingue entre mayúsculas y minúsculas.
Luego, usa el alias del almacén de políticas en tu código. Cuando tu código se ejecute en cada región, el alias del almacén de políticas hará referencia al almacén de políticas asociado en esa región.
Sin embargo, existe el riesgo de que se elimine el alias del almacén de políticas. En ese caso, los intentos de la aplicación de usar el nombre del alias del almacén de políticas fallarán y es posible que tengas que volver a crear o actualizar el alias del almacén de políticas. Para mitigar este riesgo, ten cuidado a la hora de dar permiso a los directores para que administren los alias del almacén de políticas que utilizas en tu aplicación.
Los alias del almacén de políticas no son un mecanismo de control del tráfico
Un alias de almacén de políticas es un nombre estable y fácil de usar para un almacén de políticas. No es un mecanismo para desplazar, dividir o ponderar el tráfico de autorización entre los almacenes de políticas. Si está familiarizado con las funciones que dirigen el tráfico entre las versiones de un recurso, como los alias de Lambda, tenga en cuenta que los alias de los almacenes de políticas no se comportan de la misma manera. Por diseño, un alias de almacén de políticas se parece más a un alias de AWS KMS clave: proporciona un nombre duradero para un recurso, no una capa de enrutamiento delante de él.
Por este motivo, no proporcionamos una UpdatePolicyStoreAlias operación de forma intencionada. Para cambiar el almacén de políticas al que apunta el alias de un almacén de políticas, debes eliminar el alias del almacén de políticas y crear un nuevo alias de almacén de políticas que tenga el mismo nombre y se dirija a un almacén de políticas diferente. No se trata de una operación atómica y no ofrece las garantías que ofrecería un mecanismo de control del tráfico.
Cuando cambias el almacén de políticas en el que se resuelve el alias de un almacén de políticas, el cambio no se aplica en todas partes al mismo tiempo:
-
La asignación actualizada debe propagarse desde el plano de control al plano de datos que evalúa las solicitudes de autorización. La asignación no se propaga de forma instantánea.
-
Como la resolución de los alias de los almacenes de políticas es, en última instancia, coherente y se puede almacenar en caché, existe una ventana de transición después de un cambio. Durante este período, el almacén de políticas asociado anteriormente atiende algunas solicitudes y el almacén de políticas recién asociado atiende otras solicitudes. La duración de esta ventana es indeterminada.
Durante este período, su aplicación puede recibir las decisiones de autorización de cualquiera de los almacenes de políticas. Como los distintos almacenes de políticas pueden contener políticas, entidades y esquemas diferentes, la misma solicitud puede generar decisiones diferentes según el almacén de políticas que la reciba. Por lo tanto, los alias de los almacenes de políticas no pueden proporcionar una separación atómica entre los almacenes de políticas y no sustituyen a una estrategia de implementación o administración del tráfico.
No utilices los alias como mecanismo de transición
No cree una infraestructura como código de nivel superior ni una primitiva de implementación que redirija el alias de un almacén de políticas para cambiar el tráfico de autorización de un almacén de políticas a otro. Como el cambio no es atómico, las solicitudes se pueden autorizar en ambos almacenes de políticas al mismo tiempo durante un período indeterminado. Esto puede llevar a decisiones de autorización incoherentes. Para cambiar de almacén de políticas de forma segura, consulteRealizar cambios en el almacén de políticas sin tiempo de inactividad.
Realizar cambios en el almacén de políticas sin tiempo de inactividad
Como los alias de los almacenes de políticas no proporcionan una separación atómica (consulteLos alias del almacén de políticas no son un mecanismo de control del tráfico), le recomendamos que evite migrar de un almacén de políticas a otro redirigiendo el alias del almacén de políticas. En su lugar, controla la migración desde tu aplicación para poder validar el nuevo almacén de políticas y revertirlo al instante si es necesario. El siguiente enfoque le permite cambiar de almacén de políticas sin tiempo de inactividad:
-
Cree el nuevo almacén de políticas y asígnele su propio alias de almacén de políticas, de modo que el almacén de políticas actual y el nuevo almacén de políticas tengan cada uno un nombre distinto y estable. Por ejemplo, siga
policy-store-alias/example-policy-storeapuntando a su almacén de políticas actual ypolicy-store-alias/example-policy-store-2créelo para el nuevo almacén de políticas. No reutilices ni cambies el alias de un único almacén de políticas para realizar el cambio. -
Replique sus políticas, esquemas y cualquier otra configuración en el nuevo almacén de políticas y ejecútelo en paralelo con el almacén de políticas actual.
-
Agregue un valor de configuración o un indicador de función a su aplicación (por ejemplo, mediante el uso de AppConfig) que determine qué alias del almacén de políticas es el más autorizado para las decisiones de autorización. No confíes en cambiar el alias en sí mismo para cambiar el tráfico.
-
Ejecute el nuevo almacén de políticas en modo oculto. Envíe el mismo almacén de políticas
IsAuthorizedoIsAuthorizedWithTokenuna solicitud a ambos almacenes de políticas y compare las decisiones. Registra e investiga cualquier discrepancia hasta que el nuevo almacén de políticas te dé las decisiones que esperabas. -
Usa el indicador de función para cambiar las decisiones de autorización al nuevo alias del almacén de políticas de forma gradual, por ejemplo, mediante una implementación gradual en todos los hosts de aplicaciones o segmentos de usuarios. Supervisa las decisiones de autorización y las tasas de error a medida que avanzas.
-
Usa el indicador de función para volver inmediatamente al alias original del almacén de políticas si detectas un problema. Como la aplicación controla el cambio, la reversión es instantánea y no depende de la propagación del alias.
-
Elimine el antiguo almacén de políticas y su alias de almacén de políticas una vez que el nuevo almacén de políticas esté completamente validado y sirva a todo el tráfico.
Este patrón le da a la aplicación, en lugar de a la propagación de alias, el control sobre qué almacén de políticas atiende cada solicitud. Ese control es lo que hace que la migración sea segura y reversible, y evita la ventana de transición que supondría cambiar el alias de un almacén de políticas.
