Sommaire
En définissant sa stratégie IAM et le cadre d’autonomie des équipes qui travaillent sur le cloud, il n’est pas toujours simple de trouver le bon curseur entre autonomie, efficacité et sécurité.
Les bonnes pratiques nous recommandent de respecter le principe Least privilege. Cependant un cadre trop strict revient à freiner les équipes et les pousse à trouver des solutions de contournement qui deviennent parfois des nouvelles failles de sécurité.
Avec PAM sur Google Cloud, ne serait-il pas possible de réconcilier Least privilege tout en ayant la possibilité d’avoir un cadre flexible ?
Qu’est ce que PAM ?
P.A.M. pour Privileged Access Manager est un service intégré à Google Cloud qui nous propose un workflow d’attribution de droit temporaire avec :
- Création de "profil" d’accès permettant de cibler finement les rôles que l’on veut donner temporairement et les personnes pouvant les demander
- Une interface permettant aux personnes habilitées de demander cet accès temporaire
- Audit et envoi d’emails pour les demandes d’accès et la validation des demandes
Fonctionnement
Je vous propose de présenter le fonctionnement par l’exemple, avec un cas d’utilisation inspiré d’un cas réel :
En tant qu’équipe plateforme, je souhaite pouvoir autoriser l’équipe de développement à réaliser des opérations d’administration exceptionnelles en production. Par défaut, les droits en écriture sur le projet sont donnés uniquement au compte de service de la CI/CD qui déploie les ressources via Infrastructure as Code.
Pour l’exemple, je vais partir du principe que les opérations de production sont uniquement des suppressions de bucket. En pratique, on ajoutera les rôles prédéfinis correspondant aux dites opérations.
Création du profil d’accès
Dans IAM & Admin > PAM > Entitlements > Create :
À partir du moment où l’entitlement est créé, l'équipe de développement peut y accéder pour faire sa demande de droit temporaire :
Les admins recevront un email avec un lien permettant de rapidement valider ou refuser la demande.
Le rôle sera assigné automatiquement avec une IAM condition l’identifiant comme un rôle PAM et avec une expiration :
Le rôle sera supprimé complètement lors de l’expiration de la demande d’accès.
Role & Permissions
Un certain nombre de prérequis sont nécessaires en terme de rôles:
- roles/privilegedaccessmanager.serviceAgent: Pour le compte de service agent PAM, service-org-<project_number>@gcp-sa-pam.iam.gserviceaccount.com notamment pour avoir la permission resourcemanager.projects.setIamPolicy.
- roles/privilegedaccessmanager.admin: Pour créer des entitlements sur le projet.
- roles/privilegedaccessmanager.viewer et être membre des requesters: Pour pouvoir faire une demande d’accès.
À noter que pour les requesters, il est possible d’utiliser des utilisateurs, groupes ou comptes de service et pour les approvers uniquement des utilisateurs et groupes.
Il n’est pas possible de créer un entitlement avec les rôles basiques (ce qui n’est pas forcément un mal).
Audit
Tous les événements de demande d’accès, validation ou refus, ainsi que les modifications sur les entitlements apparaissent dans les logs d’audits et accessibles dans l’interface PAM :
Il est possible d’ajouter à un entitlement des notifications supplémentaires par mail lors des demandes/validations d’accès, à des emails autres que ceux qui valident.
What else ?
Il est également possible de configurer un entitlement pour ne pas nécessiter de validation, étonnant ?
Et bien pas forcément :
Ne pas avoir de droit élevé sur un projet, c’est une sécurité pour s’éviter soit même une erreur, il n’est pas souhaitable d’avoir les droits admin en permanence même si je suis censé avoir le droit de faire certaines opérations.
Supprimer une table BigQuery en production en partant du principe que c’était celle sur le projet de dev et bien ça peut arriver. Mieux vaut ne pas être Bigquery Admin en production et se donner ce droit temporairement, uniquement quand on en a besoin.
Infrastructure as code
Dans l’idéal, les entitlements devraient être managées via Infrastructure As Code, un exemple avec Terraform pour pouvoir permettre à une équipe Data (data-engineer-team) de demander temporairement le rôle BigQuery Admint:
resource "google_privileged_access_manager_entitlement" "bigquery_admin_entitlement" {
provider = google-beta
entitlement_id = "bigquery-admin-entitlement"
location = "global"
max_request_duration = "3600s"
parent = "projects/${var.project_id}"
requester_justification_config {
unstructured {}
}
eligible_users {
principals = ["group:data-engineer-team@xxxdomain.fr"]
}
privileged_access {
gcp_iam_access {
role_bindings {
role = "roles/bigquery.admin"
}
resource = "//cloudresourcemanager.googleapis.com/projects/${var.project_id}"
resource_type = "cloudresourcemanager.googleapis.com/Project"
}
}
additional_notification_targets {
admin_email_recipients = ["data-security-team@xxxdomain.fr"]
}
approval_workflow {
manual_approvals {
require_approver_justification = true
steps {
approvals_needed = 1
approvers {
principals = ["group:data-admin-team@xxxdomain.fr"]
}
}
}
}
}
Conclusion
Simple et efficace, PAM simplifie et favorise le least privilege, principalement car ce nouveau service nous enlève le besoin d’avoir des droits importants pour des opérations ponctuelles.
Il est également possible d’utiliser PAM pour les droits folders et organisations de la même manière.
À noter qu’il est possible de réduire le scope du rôle attribué via PAM en ajoutant une IAM condition et éventuellement les tags mais il n’est pas possible d’attribuer des rôles au niveau ressource.
Attention tout de même à ce que cet outil supplémentaire ne soit pas utilisé pour créer une stratégie IAM trop compliquée à administrer et à auditer :
- PAM ne doit pas être utilisé pour appliquer une stratégie least privilege trop restrictive : Ne pas donner assez droit en s’appuyant sur PAM reviendrait à sur-solliciter les administrateurs qui pourraient avoir tendance à valider sans challenger.
- Déterminer les droits possibles d’un utilisateur sera plus compliqué car il faudra consulter IAM mais aussi les entitlements. Plus simple est la stratégie, plus simple en est l’auditabilité.
