RBAC à 2 couches avec Google Groups

Lier des rôles IAM directement à des utilisateurs individuels crée deux problèmes qui se cumulent : une charge de gestion (IAM doit être mis à jour à chaque arrivée, départ ou changement de rôle) et une confusion lors des audits (expliquer pourquoi une personne spécifique dispose de Data Editor sur un dataset spécifique).

Le pattern à deux couches sépare ce qui est possible de qui le fait.

Les deux couches

Couche 1 : les rôles IAM prédéfinis définissent quelles actions sont possibles sur les ressources BigQuery.

Les trois rôles à utiliser pour les équipes data :

roles/bigquery.dataViewer — lecture des tables et vues, mais ne permet pas d’exécuter des requêtes sans avoir également jobUser
roles/bigquery.dataEditor — lecture, écriture et suppression des données de tables
roles/bigquery.dataOwner — contrôle total, y compris les paramètres de partage

Notez la distinction entre accès aux données et accès au calcul. dataViewer permet à un principal de voir les données — cela ne lui permet pas d’exécuter des requêtes. roles/bigquery.jobUser est nécessaire pour créer et exécuter des jobs de requête. C’est une confusion fréquente : les utilisateurs avec seulement Data Viewer peuvent parcourir les tables dans la console mais ne peuvent pas les interroger. Accordez toujours les deux, ou utilisez roles/bigquery.user (qui regroupe la création de jobs et les droits de listage des datasets).

Couche 2 : les Google Groups représentent des fonctions, pas des individus.

Groupes typiques pour une équipe data :

data-loaders@votredomaine.com — comptes de service et humains qui écrivent les données brutes dans les zones d’atterrissage
data-engineers@votredomaine.com — ceux qui transforment et modélisent les données, avec accès en écriture aux datasets intermédiaires et mart
data-analysts@votredomaine.com — ceux qui interrogent les tables de production sans les modifier

Le groupe est l’unité de gestion des permissions. Les individus sont membres des groupes.

Liaison des rôles aux groupes

# Accorder aux analystes un accès lecteur sur les datasets de production uniquement
gcloud projects add-iam-policy-binding YOUR_PROJECT_ID \
  --member="group:data-analysts@votredomaine.com" \
  --role="roles/bigquery.dataViewer" \
  --condition='expression=resource.name.startsWith("projects/YOUR_PROJECT_ID/datasets/prod_"),title=prod-datasets-only'

La condition IAM restreint le rôle aux datasets dont les noms commencent par prod_. Les analystes ont accès aux données de production sans pouvoir lire les datasets de développement — même si les deux se trouvent dans le même projet. C’est une alternative pratique à la séparation des environnements en différents projets, bien que le projet par environnement soit la solution la plus complète.

Pour la création de jobs, accordez au niveau du projet sans condition :

gcloud projects add-iam-policy-binding YOUR_PROJECT_ID \
  --member="group:data-analysts@votredomaine.com" \
  --role="roles/bigquery.jobUser"

Gérer l’appartenance, pas les liaisons

L’avantage opérationnel : quand quelqu’un rejoint l’équipe, ajoutez-le au groupe approprié. Quand il part, retirez-le du groupe. Quand il passe d’analyste à ingénieur, déplacez-le d’un groupe à l’autre.

Les liaisons IAM elles-mêmes — les connexions entre rôles et groupes — ne changent jamais. Pas de mise à jour de la policy IAM à chaque onboarding. Pas de recherche de permissions obsolètes à chaque départ.

Les audits deviennent également gérables. « Qui a un accès en écriture sur les datasets de production ? » se répond en consultant l’appartenance au groupe data-engineers@votredomaine.com, et non en parcourant les liaisons IAM de dizaines d’utilisateurs.

Considérations sur la structure des groupes

Commencez simplement. Trois groupes couvrent la plupart des équipes data :

data-loaders     →  dataEditor sur les datasets bruts
data-engineers   →  dataEditor sur tous les datasets, jobUser sur le projet
data-analysts    →  dataViewer sur les datasets prod, jobUser sur le projet

Ajoutez des groupes au fur et à mesure que vous identifiez un besoin réel de profils de permissions différents — pas de manière spéculative. Des structures de groupes trop segmentées deviennent leur propre charge de maintenance. L’objectif est d’avoir suffisamment de groupes pour que l’appartenance décrive la fonction d’une personne, et suffisamment peu pour pouvoir expliquer la structure à un nouveau membre de l’équipe en cinq minutes.

Pour les comptes de service, les groupes ne sont pas la bonne abstraction. Les comptes de service représentent des workloads individuels et doivent être gérés individuellement avec le pattern de compte de service par workload.

La version Terraform

Si vous gérez l’IAM en tant que code (et vous devriez), la liaison ressemble à ceci :

resource "google_project_iam_member" "analysts_job_user" {
  project = var.project_id
  role    = "roles/bigquery.jobUser"
  member  = "group:data-analysts@${var.domain}"
}

resource "google_project_iam_member" "analysts_data_viewer" {
  project   = var.project_id
  role      = "roles/bigquery.dataViewer"
  member    = "group:data-analysts@${var.domain}"

  condition {
    title       = "prod-datasets-only"
    expression  = "resource.name.startsWith(\"projects/${var.project_id}/datasets/prod_\")"
  }
}

Définir les liaisons dans Terraform les rend révisables, auditables et reproductibles. Les modifications passent par une revue de code. Les nouveaux membres de l’équipe reçoivent exactement les permissions que leur rôle requiert — ni plus, ni moins.