Combien de temps dois-je attendre après avoir appliqué une stratégie AWS IAM avant qu'elle ne soit valide?
J'ajoute et supprime des stratégies utilisateur AWS IAM par programme et j'obtiens des résultats incohérents de l'application de ces stratégies.
Par exemple, cela peut réussir ou non (j'utilise le Java 1.6.6 SDK):
- Commencez avec un utilisateur qui peut lire à partir d'un compartiment particulier
- Effacer les politiques des utilisateurs (lister les politiques puis appeler "deleteUserPolicy" pour chacune)
- Attendez que l'utilisateur n'ait aucune stratégie utilisateur (appelez "listUserPolicies" jusqu'à ce qu'il renvoie un ensemble vide)
- Tentative de lecture à partir du compartiment (cela devrait échouer)
Si je mets un point d'arrêt entre # 3 et # 4 et que j'attends quelques secondes, l'utilisateur ne peut pas lire depuis le bucket, ce que j'attends. Si je supprime des points d'arrêt, l'utilisateur peut lire dans le compartiment, ce qui est faux.
(Ceci est également incohérent lorsque je ajoute une politique puis accède à une ressource)
Je voudrais savoir quand un changement de politique a eu un effet sur le composant (S3, SQS, etc.), pas seulement sur le système IAM. Existe-t-il un moyen d'obtenir un reçu ou un accusé de réception de cela? Ou peut-être qu'il y a un certain temps à attendre?
Existe-t-il de la documentation sur les aspects internes de l'application des politiques?
(Pour info j'ai copié ma question depuis https://forums.aws.Amazon.com/thread.jspa?threadID=140383&tstart= )
L'expression "presque immédiatement" est utilisée 5 fois dans le IAM FAQ , et est, bien sûr, quelque peu subjective.
Étant donné qu'AWS est un système distribué mondialement, vos modifications doivent se propager et le système dans son ensemble semble être conçu pour favoriser la disponibilité et la tolérance de partition par opposition à cohérence immédiate.
Je ne sais pas si vous l'avez envisagé, mais il est tout à fait dans les limites de la possibilité que vous puissiez réellement, à l'étape 4 de votre flux, voir une séquence de réussite, d'échec, de réussite, de réussite, d'échec, d'échec, d'échec, échouer ... parce que ni un seau ni un objet dans un seau ne sont en fait une seule chose en un seul endroit, comme en témoigne le modèle cohérence mixte d'actions différentes dans S3, où de nouveaux objets sont immédiatement- cohérente tandis que les écrasements et les suppressions sont finalement cohérents ... donc le concept d'une politique ayant "eu un effet" ou non sur le compartiment ou un objet n'est pas un concept entièrement significatif puisque l'application de la politique est, elle-même, presque certainement , un événement distribué.
Pour confirmer une telle application des politiques, AWS devrait exposer la capacité (au moins indirecte) d'interroger chaque entité qui a une copie répliquée de cette politique pour voir si elle avait la version actuelle ou non ... ce qui serait potentiellement impraticable ou difficile à dire pour le moins dans un système aussi massif que S3, qui a grandi au-delà d'une stupéfiante 2 trillions d'objets, et sert des charges de pointe dépassant 1,1 million de requêtes par seconde .
Les réponses officielles d'AWS à ce message sur le forum fournissent plus d'informations:
Bien que les modifications que vous apportez aux entités IAM soient immédiatement reflétées dans les API IAM, le reflet global des informations peut prendre un certain temps. Dans la plupart des cas, les modifications que vous apportez se reflètent en moins d'une minute. Les conditions du réseau peuvent parfois augmenter le délai et certains services peuvent mettre en cache certaines informations non d'identification qui prennent du temps à expirer et à être remplacées.
La réponse qui l'accompagnait à ce qu'il fallait faire en attendant était "réessayer".
Nous vous recommandons une nouvelle tentative de boucle après un léger retard initial, car dans la plupart des cas, vous verrez vos modifications reflétées assez rapidement. Si vous dormez, votre code attendra beaucoup trop longtemps dans la plupart des cas, et peut-être pas assez longtemps pour les rares exceptions.
Nous surveillons activement les performances du système de réplication. Mais comme S3, nous ne garantissons qu'une cohérence éventuelle, pas une limite supérieure particulière.
J'ai une réponse beaucoup moins scientifique ici ... mais je pense que cela aidera certaines autres personnes à se sentir moins folles :). Je n'arrêtais pas de penser que les choses ne fonctionnaient pas alors qu'elles prenaient juste plus de temps que prévu.
Hier soir, j'ajoutais une politique en ligne pour permettre à un hôte d'obtenir des paramètres du gestionnaire de système. Je pensais que cela ne fonctionnait pas, car plusieurs minutes après le changement (peut-être environ 5), mes commandes CLI échouaient toujours. Ensuite, ils ont commencé à travailler. C'était donc un retard assez important.
Tout à l'heure, j'ai supprimé cette politique et il a fallu 2 à 3 minutes (suffisamment pour google ceci et lire quelques autres pages) avant que mon hôte ne perde l'accès.
En général, les choses sont assez rapides pour moi aussi, mais si vous êtes sûr que quelque chose devrait fonctionner et que ce n'est pas le cas, faites-vous une faveur et attendez 10 minutes. Malheureusement, cela rend l'automatisation après les changements d'IAM plus difficile que je ne le pensais!