F5 402 : modèles cloud, IAM et frontières d’administration

Une architecture cloud associe fournisseur, infrastructure, système, configuration applicative et données. Les responsabilités dépendent du modèle retenu. Expliquez qui installe, met à jour, surveille et restaure chaque couche avant de choisir un outil ou une plateforme.

Le 402 demande de comparer les modèles cloud et d’appliquer des concepts IAM. Une VE hébergée dans un cloud ne transfère pas automatiquement toutes ses responsabilités au fournisseur. De même, un service de gestion d’identité ne définit pas à lui seul les permissions nécessaires pour modifier le routage ou la configuration BIG-IP.

Distinguez l’identité d’un administrateur, celle d’une automatisation et celle d’un client applicatif. Leurs permissions et modes d’authentification ne sont pas interchangeables. L’accès au compte cloud et l’accès à l’API BIG-IP peuvent relever de systèmes différents.

La documentation IAM AWS recommande notamment les credentials temporaires, les rôles et le moindre privilège. Appliquez ces concepts dans le contexte supporté par votre fournisseur, sans transposer une politique AWS mot pour mot à un autre système. Décrivez actions, ressources, conditions et relations de confiance.

Un workflow doit expliquer création, usage, rotation ou expiration et retrait des permissions. Les secrets ne doivent pas être inscrits dans une déclaration versionnée ou dans les logs du pipeline. Un compte technique administrateur global peut simplifier un test tout en élargissant fortement la portée d’une erreur.

Vérifiez les droits nécessaires à chaque étape : déploiement, association réseau, configuration applicative et collecte. Séparez une erreur d’authentification d’un refus d’autorisation. Une authentification réussie ne prouve pas que l’action suivante est permise.

Une automatisation crée une VM, puis échoue à configurer le service. Dessinez les identités utilisées pour les deux étapes. Identifiez les accès réseau, permissions cloud et permissions BIG-IP à vérifier, sans conclure que le même secret doit être utilisé partout.

Votre livrable est une matrice de permissions par étape avec une preuve et un propriétaire. Pour poursuivre, lisez le modèle d’orchestration par API et le cycle de provisioning.