Contrôle d'accès basé sur les rôles

Aperçu

Le système implémente un modèle RBAC complet pour gérer le contrôle d'accès sur différentes ressources et actions. Il se compose de rôles, de politiques et d'attributions de rôles utilisateur.

Composants principaux

Ressources

Le système définit les ressources protégées suivantes :

• Audit
• DevPod
• Image
• Payment
• Pubkey
• Registry
• Region
• Resource
• Serverless
• Storage
• Team
• Role
• UserRole

Actions

Actions disponibles sur les ressources :

• List (Lister)
• Get (Obtenir)
• Create (Créer)
• Update (Mettre à jour)
• Delete (Supprimer)

Système de rôles

Un rôle est une collection de permissions qui définit quelles actions un utilisateur peut effectuer sur des ressources spécifiques. Les rôles aident à organiser et gérer les droits d'accès efficacement en regroupant les permissions connexes.

Rôles prédéfinis

1. AccountAdmin

   • Accès complet aux ressources au niveau du compte
   • Peut gérer les membres de l'équipe
   • Peut configurer les paramètres du compte

2. Developer

   • Peut gérer les DevPods
   • Peut gérer les ressources Serverless
   • Peut gérer les Images
   • Peut gérer le Storage (Créer/Lire uniquement)

3. Auditor

   • Accès en lecture seule aux journaux d'audit

4. Finance

   • Accès complet aux fonctions de paiement

5. Ops

   • Accès en lecture aux DevPods et Serverless
   • Accès complet aux Images, Storage, Pubkey et Resources

Politiques

Les politiques sont les éléments de base fondamentaux du contrôle d'accès qui définissent des permissions spécifiques. Chaque politique représente une règle qui accorde la permission d'effectuer certaines actions sur des ressources spécifiques.

Structure de politique

• Resource : Ressource cible
• Action : Action autorisée

Attribution de politique

• Les politiques sont attribuées aux rôles via le mappage RolePolicy
• Plusieurs politiques peuvent être attribuées à un seul rôle
• Les attributions de politique sont uniques par rôle

Contrôle des permissions utilisateur

Le système implémente le contrôle des permissions via un modèle à trois niveaux : Utilisateurs, Rôles et Politiques. Les rôles agissent comme un pont entre les utilisateurs et les politiques, fournissant un moyen flexible et gérable de contrôler les droits d'accès.

Flux de contrôle

1. Attribution utilisateur

   • Les utilisateurs se voient attribuer un ou plusieurs rôles
   • Les attributions de rôles sont spécifiques à chaque compte
   • Un utilisateur peut avoir différents rôles dans différents comptes

2. Rôle comme pont

   • Les rôles servent de conteneurs pour les collections de politiques
   • Chaque rôle définit un ensemble spécifique de responsabilités
   • Les rôles rendent la gestion des permissions plus maintenable

3. Application de politique

   • Les politiques définissent les permissions réelles
   • Chaque requête est validée contre les politiques des rôles de l'utilisateur
   • L'accès n'est accordé que si une politique correspondante existe

Processus d'autorisation

1. Traitement de la requête

   • Extraire les informations du compte
   • Identifier la ressource cible et l'action
   • Vérifier les rôles et politiques de l'utilisateur

2. Vérification des permissions

   • Les rôles spécifiques au compte sont validés par rapport au compte cible
   • La correspondance de politique considère à la fois les correspondances exactes et les jokers

3. Contrôle d'accès

   • Accès accordé si un rôle attribué a une politique correspondante
   • Les requêtes refusées renvoient des résultats vides plutôt que des erreurs
   • La journalisation d'audit se produit après la validation RBAC

Meilleures pratiques

1. Gestion des rôles

   • Utilisez des rôles prédéfinis lorsque c'est possible
   • Créez des rôles personnalisés avec les permissions minimales requises
   • Examinez régulièrement les attributions de rôles

2. Considérations de sécurité

   • Validez toujours le contexte du compte
   • Implémentez des restrictions d'interface utilisateur basées sur les rôles
   • Maintenez des journaux d'audit pour les changements de rôles

3. Performance

   • Les attributions de rôles et de politiques sont mises en cache
   • Opérations par lots disponibles pour les attributions en masse
   • Requêtes de base de données optimisées pour les vérifications de permissions