Stratégie d’attribution de refus pour les clusters managés Service Fabric
Les stratégies d’affectation de refus pour les clusters managés Service Fabric permettent aux clients de protéger les ressources de leurs clusters. La limitation de l’accès à certaines actions peut aider les utilisateurs à éviter les dommages par inadvertance à leurs clusters lorsqu’ils suppriment, désallouent, redémarrent ou réimaginent les groupes identiques de leurs clusters. Ces actions, lorsqu’elles sont effectuées directement dans le groupe de ressources d’infrastructure, peuvent entraîner la désynchronisation des ressources du cluster avec les données du cluster.
Les affectations de refus refusent l'accès en attachant un ensemble d'actions de refus à un utilisateur, un groupe ou un principal de service à une portée particulière. Pour en savoir plus sur les affectations de refus, consultez la documentation Contrôle d’accès en fonction du rôle (RBAC) Azure.
Cet article concerne les clusters managés Service Fabric, mais nous effectuons des légendes lorsque les informations se rapportent également aux clusters classiques.
Toutes les actions liées aux clusters managés doivent être effectuées via les API de ressources de cluster managé plutôt que directement sur le groupe de ressources d’infrastructure. L’utilisation des API de ressources garantit que les ressources du cluster sont synchronisées avec les données du cluster managé.
Consultez la section Bonnes pratiques pour obtenir des conseils sur les outils à utiliser pour parcourir les API de ressources appropriées.
Les actions suivantes sont bloquées lors de l’utilisation de clusters managés et ne s’appliquent pas aux clusters classiques.
- Suppressions de VMSS
- "Microsoft.Compute/virtualMachineScaleSets/delete"
- Réimages VMSS, redémarrages, désalloués
- "Microsoft.Compute/virtualMachineScaleSets/reimage/action"
- "Microsoft.Compute/virtualMachineScaleSets/restart/action"
- "Microsoft.Compute/virtualMachineScaleSets/deallocate/action"
- Suppressions de machines virtuelles
- "Microsoft.Compute/virtualMachineScaleSets/delete/action"
- Écritures et suppressions du compte de stockage
- « Microsoft.Storage/storageAccounts/delete »
- « Microsoft.Storage/storageAccounts/write »
- Suppression d’un groupe de ressources
- "Microsoft.Resources/subscriptions/resourceGroups/delete"
- Écritures de l’équilibreur de charge
- "Microsoft.Network/loadBalancers/write"
Voici quelques meilleures pratiques pour réduire la menace de désynchronisation des ressources de votre cluster :
- Au lieu de supprimer des groupes identiques de machines virtuelles directement dans le groupe de ressources managé, utilisez les API de niveau NodeType pour supprimer le NodeType ou le groupe identique de machines virtuelles. Les options incluent le panneau Nœud sur le portail Azure et Azure PowerShell.
- Utilisez les API appropriées pour redémarrer ou réinitialiser vos groupes identiques :
Lors de la gestion des ressources dans des clusters managés, utilisez des outils ARM ou ARM pour garantir l’utilisation des API de ressources appropriées.
| Utilitaire | ARM ou ARM-backed |
|---|---|
| ARM et modèles ARM | Oui |
| Bicep | Oui |
| Azure portal | Oui |
| Azure CLI | Oui |
| Azure PowerShell | Oui |
| PowerShell Service Fabric | Aucun |
| sfctl | Aucun |
Important
Lors de la gestion des ressources d’un cluster classique créé par les outils ARM ou ARM, continuez à utiliser ces outils. Il existe un risque d’erreur lors de la modification de la configuration des ressources créées dans ARM avec un outil non ARM (par exemple, à l’aide de Service Fabric PowerShell pour mettre à jour ou supprimer une ressource créée dans ARM).
- En savoir plus sur l’octroi de l’autorisation d’accès aux ressources sur des clusters managés