IAM granulaire et plans de contrôle séparés pour le premier Google Cloud de LiveRamp

Une première fondation cloud est une occasion unique de décider comment les réseaux sont segmentés, comment les environnements sont séparés et qui peut faire quoi. Les équipes qui sautent cette étape se retrouvent avec des projets créés au cas par cas, des réseaux plats et des liaisons IAM que personne ne sait expliquer, et le coût de la correction augmente à chaque charge de travail déployée par-dessus.

LiveRamp avait des équipes d'ingénierie dans plusieurs régions du monde qui devaient toutes accéder à la nouvelle plateforme, et des charges de travail qui tourneraient sur Kubernetes dès le départ. La fondation devait satisfaire quatre exigences à la fois : l'accessibilité pour ces équipes, la scalabilité pour les charges de travail, une sécurité adaptée à des données clients et l'administrabilité pour le groupe qui l'exploiterait.

SEYA a examiné l'architecture existante avec l'équipe de LiveRamp et identifié les points où cette conception freinerait le passage à Google Cloud. De là, nous avons proposé une architecture cible alignée sur les pratiques recommandées par Google Cloud pour les organisations, le réseau et l'identité.

La conception a été validée avec LiveRamp avant la construction, de sorte que les travaux de réseau, de GKE et d'IAM qui ont suivi ont mis en œuvre un plan que les architectes du client avaient déjà examiné.

SEYA a mis en œuvre une conception réseau articulée autour d'un VPC de services communs pour les services exploités de manière centralisée, de VPC de transit pour le routage entre environnements, et de VPC hôtes distincts pour la production et le hors production. Le VPN assure la connectivité vers le parc et l'appairage VPC relie les réseaux qui doivent communiquer.

Les plans de contrôle GKE ont été séparés des nœuds de travail au sein d'un VPC partagé, de sorte que le trafic d'administration des clusters et le trafic applicatif sont isolés, et que l'équipe plateforme maîtrise le réseau dans lequel chaque cluster s'installe.

SEYA a défini la structure d'organisation Google Cloud avec des environnements distincts, et un modèle IAM assez granulaire pour que des équipes de différentes régions travaillent de façon autonome sans permissions étendues. Des rôles personnalisés ont été créés pour les services gérés par Google et pour les piles applicatives de LiveRamp, afin que l'accès suive la fonction plutôt qu'un rôle par défaut. Une plateforme d'observabilité opérationnelle sur Google Cloud a complété la fondation.

Pour un CTO ou un responsable plateforme, la valeur d'une telle fondation tient aux questions qu'elle règle définitivement. Les services partagés ont un seul foyer. La production et le hors production sont des lieux différents avec des permissions différentes. Tout nouveau projet hérite du modèle de réseau et d'identité au lieu d'en inventer un.

Séparer les plans de contrôle GKE des nœuds de travail dans un VPC partagé donne au groupe plateforme la maîtrise de l'endroit où les clusters se rattachent et de la circulation de leur trafic, tandis que les équipes applicatives gardent la propriété de ce qui tourne à l'intérieur.

Un IAM granulaire avec des rôles personnalisés signifie qu'un ingénieur d'une région donnée peut recevoir exactement l'accès que sa fonction exige sur un service géré par Google ou une pile applicative, et que cet accès peut être revu et révoqué sans toucher personne d'autre.