Comprendre la terminologie des formulaires de données et les processus d'authentification | Par Kabir Akande | Mai 2024 |

Comprendre les terminologies Dataform et le flux d'authentification : Dataform, un service GCP, rationalise les pipelines de données en intégrant les meilleures pratiques d'ingénierie et en automatisant l'orchestration des flux de travail. En organisant le code dans des espaces de travail, en gérant les configurations et en définissant des environnements, Dataform permet une transformation efficace des données et une sortie de données structurée. Cet article examine les terminologies clés de Dataform, notamment les espaces de travail de développement, les configurations de version et les configurations de flux de travail, et explore le processus d'authentification à l'aide de comptes de service et d'usurpation d'identité.

MLOps: Data Pipeline Orchestration

MLOps : orchestration du pipeline de données

A Comprehensive Guide to Dataform Terminologies and Authentication Flow

Un guide complet sur les terminologies des formulaires de données et le flux d'authentification

Part 1 of Dataform 101: Fundamentals of a Single Repo, Multi-Environment Dataform with Least-Privilege Access Control and Infrastructure as Code Setup

Partie 1 du formulaire de données 101 : principes fondamentaux d'un formulaire de données multi-environnement et dépôt unique avec contrôle d'accès au moindre privilège et infrastructure en tant que configuration de code

Introduction

Introduction

Dataform is an innovative service offered by Google Cloud Platform (GCP) that empowers teams to develop and operationalize sophisticated, SQL-based data pipelines. This groundbreaking platform seamlessly integrates software engineering best practices into the data pipeline lifecycle, unlocking a world of possibilities, including testing, environments, version control, dependency management, orchestration, and automated documentation. Essentially, Dataform serves as a serverless, SQL workflow orchestration engine within the GCP ecosystem. It ingests raw data, transforms it with the utmost engineering rigor, and produces meticulously structured data ready for consumption.

Dataform est un service innovant proposé par Google Cloud Platform (GCP) qui permet aux équipes de développer et de mettre en œuvre des pipelines de données sophistiqués basés sur SQL. Cette plateforme révolutionnaire intègre de manière transparente les meilleures pratiques d'ingénierie logicielle dans le cycle de vie du pipeline de données, ouvrant ainsi un monde de possibilités, notamment les tests, les environnements, le contrôle de version, la gestion des dépendances, l'orchestration et la documentation automatisée. Essentiellement, Dataform sert de moteur d'orchestration de flux de travail SQL sans serveur au sein de l'écosystème GCP. Il ingère des données brutes, les transforme avec la plus grande rigueur technique et produit des données méticuleusement structurées, prêtes à être consommées.

Dataform Terminologies

Terminologies des formulaires de données

Navigating the world of Dataform can be a daunting task, especially for those new to its terminologies. To bridge this knowledge gap, let's delve into some key terms that will serve as a compass on your Dataform journey:

Naviguer dans le monde de Dataform peut être une tâche ardue, en particulier pour ceux qui découvrent ses terminologies. Pour combler ce manque de connaissances, examinons quelques termes clés qui vous serviront de boussole dans votre parcours Dataform :

Development Workspaces:

Espaces de travail de développement :

Similar to local GitHub branches, Dataform development workspaces provide an editable copy of the main Dataform repository code. Within these workspaces, code development and experimentation flourish. When the time comes to share your masterpiece with the world, simply commit and push your changes, and voilà, a remote branch will emerge, mirroring your development workspace.

Semblables aux branches GitHub locales, les espaces de travail de développement Dataform fournissent une copie modifiable du code principal du référentiel Dataform. Au sein de ces espaces de travail, le développement et l’expérimentation de codes fleurissent. Lorsque vient le temps de partager votre chef-d’œuvre avec le monde, validez et poussez simplement vos modifications, et voilà, une branche distante émergera, reflétant votre espace de travail de développement.

Release Configuration:

Configuration de la version :

Dataform seamlessly blends .sqlx scripts with JavaScript (.js) for data transformations and logic. To ensure the codebase is standardized and reproducible, Dataform employs a compilation process that transforms it into a machine-readable JSON config file. The orchestrator behind this compilation process is none other than release configuration. At a predetermined time, Dataform will diligently check out the code from a remote repository (which can be configured to target any branch) and weave its transformation magic, generating the JSON config file.

Dataform combine de manière transparente les scripts .sqlx avec JavaScript (.js) pour les transformations de données et la logique. Pour garantir que la base de code est standardisée et reproductible, Dataform utilise un processus de compilation qui la transforme en un fichier de configuration JSON lisible par machine. L'orchestrateur derrière ce processus de compilation n'est autre que la configuration de la version. À un moment prédéterminé, Dataform extraira avec diligence le code d'un référentiel distant (qui peut être configuré pour cibler n'importe quelle branche) et tissera sa magie de transformation, générant le fichier de configuration JSON.

Workflow Configuration:

Configuration du flux de travail :

The output of release configuration – the JSON config file – serves as the foundation for workflow configuration. This configuration dictates when the config file should be executed, who should execute it, and where the config file's output should reside.

Le résultat de la configuration de la version – le fichier de configuration JSON – sert de base à la configuration du flux de travail. Cette configuration dicte quand le fichier de configuration doit être exécuté, qui doit l'exécuter et où doit résider la sortie du fichier de configuration.

Since workflow configuration relies heavily on the JSON config file generated by release configuration, it's imperative to ensure that it runs after release configuration. This ensures that the latest changes are reflected in the BigQuery (BQ) tables without delay. If scheduled simultaneously, workflow configuration may utilize the previous compilation, resulting in a lag in reflecting the most up-to-date changes in the BQ tables until the next workflow configuration run.

Étant donné que la configuration du workflow repose en grande partie sur le fichier de configuration JSON généré par la configuration de la version, il est impératif de garantir qu'il s'exécute après la configuration de la version. Cela garantit que les dernières modifications sont reflétées sans délai dans les tables BigQuery (BQ). Si elle est planifiée simultanément, la configuration du flux de travail peut utiliser la compilation précédente, ce qui entraîne un décalage dans la prise en compte des modifications les plus récentes dans les tables BQ jusqu'à la prochaine exécution de la configuration du flux de travail.

Environments:

Environnements:

One of Dataform's most sought-after features is its ability to manifest code into multiple environments, such as development, staging, and production. This flexibility poses a question: should repositories be created in multiple environments or consolidated into a single environment? Google, in its infinite wisdom, has weighed the pros and cons in its Dataform best practices section. This article will demonstrate how to configure Dataform for staging and production environments, with data materialized into both environments from a single repository.

L'une des fonctionnalités les plus recherchées de Dataform est sa capacité à manifester le code dans plusieurs environnements, tels que le développement, la préparation et la production. Cette flexibilité pose une question : les référentiels doivent-ils être créés dans plusieurs environnements ou consolidés dans un seul environnement ? Google, dans son infinie sagesse, a pesé le pour et le contre dans sa section des meilleures pratiques Dataform. Cet article montrera comment configurer Dataform pour les environnements de transfert et de production, avec des données matérialisées dans les deux environnements à partir d'un seul référentiel.

Authentication

Authentification

Authentication within Dataform can be a labyrinthine maze, especially when navigating multiple environments. To shed light on this intricate matter, we will delve into the specifics of staging and production environments.

L'authentification dans Dataform peut être un labyrinthe labyrinthique, en particulier lorsque vous naviguez dans plusieurs environnements. Pour faire la lumière sur cette question complexe, nous approfondirons les spécificités des environnements de préparation et de production.

Dataform Authentication Flow:

Flux d'authentification par formulaire de données :

The diagram below captures the intricate dance of authentication within Dataform:

Le diagramme ci-dessous capture la danse complexe de l'authentification dans Dataform :

[Image of Dataform authentication flow]

[Image du flux d'authentification Dataform]

Machine User:

Utilisateur de la machine :

Dataform requires credentials to access GitHub when retrieving code stored on a remote repository. While using individual credentials is an option, the recommended path is to employ a machine user within an organization. This strategy ensures that Dataform's pipeline orchestration remains independent of individual identities and is not susceptible to their departure or whims. Setting up a machine user involves creating an identity that is not tied to an individual and using it to establish a GitHub account. For Dataform, a personal access token (PAT) is generated for the machine user account and safely tucked away as a secret in GCP's secret manager. The machine user should also be added as an outside collaborator to the Dataform remote repository with read and write access. We will unravel how Dataform is configured to access this secret in the Terraform code. If the user opts to use their own identity instead of a machine user, a token should be generated using the steps outlined here.

Dataform nécessite des informations d'identification pour accéder à GitHub lors de la récupération du code stocké sur un référentiel distant. Bien que l’utilisation d’informations d’identification individuelles soit une option, la voie recommandée consiste à employer un utilisateur de machine au sein d’une organisation. Cette stratégie garantit que l'orchestration du pipeline de Dataform reste indépendante des identités individuelles et n'est pas sensible à leur départ ou à leurs caprices. La configuration d'un utilisateur de machine implique de créer une identité qui n'est pas liée à un individu et de l'utiliser pour créer un compte GitHub. Pour Dataform, un jeton d'accès personnel (PAT) est généré pour le compte utilisateur de la machine et conservé en toute sécurité en tant que secret dans le gestionnaire de secrets de GCP. L'utilisateur de la machine doit également être ajouté en tant que collaborateur externe au référentiel distant Dataform avec un accès en lecture et en écriture. Nous découvrirons comment Dataform est configuré pour accéder à ce secret dans le code Terraform. Si l'utilisateur choisit d'utiliser sa propre identité au lieu d'un utilisateur de machine, un jeton doit être généré en suivant les étapes décrites ici.

GitHub Authentication Flow:

Flux d'authentification GitHub :

Dataform leverages its default service account for implementation. When a Dataform action is initiated, it commences with the default service account. Assuming you have created a machine user, added them as a collaborator to the remote repository, and securely stored their PAT as a secret in GCP's secret manager, let's delve into the authentication process:

Dataform exploite son compte de service par défaut pour la mise en œuvre. Lorsqu'une action Dataform est lancée, elle commence avec le compte de service par défaut. En supposant que vous ayez créé un utilisateur machine, que vous l'ayez ajouté en tant que collaborateur au référentiel distant et que vous ayez stocké en toute sécurité son PAT en tant que secret dans le gestionnaire de secrets de GCP, examinons le processus d'authentification :

1. Extracting the Secret: The default service account requires the secretAccessor role to extract the secret from the secret manager.
2. Impersonating the Machine User: Armed with the secret, the default service account can now impersonate the machine user. Since the machine user is a collaborator on the remote Git repository, the default service account inherits access to the repository.

[Image of GitHub authentication workflow]

Extraction du secret : le compte de service par défaut nécessite le rôle secretAccessor pour extraire le secret du gestionnaire de secrets. Usurpation de l'utilisateur de la machine : armé du secret, le compte de service par défaut peut désormais usurper l'identité de l'utilisateur de la machine. Étant donné que l'utilisateur de la machine est un collaborateur du référentiel Git distant, le compte de service par défaut hérite de l'accès au référentiel. [Image du workflow d'authentification GitHub]

Development Workspace Authentication:

Authentification de l'espace de travail de développement :

When execution is initiated from the development workspace, the default service account assumes the identity of the staging environment's custom service account to manifest the output within the staging environment. To successfully impersonate the staging environment's custom service account, the default service account must possess the iam.serviceAccountTokenCreator role. This role empowers the default service account to craft a short-lived token, akin to the PAT used to impersonate the machine user, for the staging custom service account and, thus, impersonate it. Consequently, the staging custom service account inherits all the necessary permissions to modify BQ tables, which are then inherited by the default service account when it impersonates the staging custom service account.

Lorsque l'exécution est lancée à partir de l'espace de travail de développement, le compte de service par défaut assume l'identité du compte de service personnalisé de l'environnement intermédiaire pour manifester la sortie dans l'environnement intermédiaire. Pour réussir à emprunter l'identité du compte de service personnalisé de l'environnement intermédiaire, le compte de service par défaut doit posséder le rôle iam.serviceAccountTokenCreator. Ce rôle permet au compte de service par défaut de créer un jeton de courte durée, semblable au PAT utilisé pour usurper l'identité de l'utilisateur de la machine, pour le compte de service personnalisé intermédiaire et, ainsi, d'usurper son identité. Par conséquent, le compte de service personnalisé intermédiaire hérite de toutes les autorisations nécessaires pour modifier les tables BQ, qui sont ensuite héritées par le compte de service par défaut lorsqu'il emprunte l'identité du compte de service personnalisé intermédiaire.

Workflow Configuration Authentication:

Authentification de la configuration du flux de travail :

After successfully retrieving the code from the repository, release configuration generates a compiled config JSON file, which workflow configurations utilize to generate data. To commit this data to production BQ tables, the default service account requires the iam.serviceAccountTokenCreator role on the production custom service account. Similar to the process employed for the staging custom service account, the production service account is granted all the necessary permissions to modify production environment BQ tables, which are inherited by the default service account when it impersonates the production custom service account.

Après avoir récupéré avec succès le code du référentiel, la configuration de la version génère un fichier de configuration JSON compilé, que les configurations de flux de travail utilisent pour générer des données. Pour valider ces données dans les tables BQ de production, le compte de service par défaut nécessite le rôle iam.serviceAccountTokenCreator sur le compte de service personnalisé de production. Semblable au processus utilisé pour le compte de service personnalisé intermédiaire, le compte de service de production se voit accorder toutes les autorisations nécessaires pour modifier les tables BQ de l'environnement de production, qui sont héritées par le compte de service par défaut lorsqu'il emprunte l'identité du compte de service personnalisé de production.

Conclusion

Conclusion

In summary, the default service account plays a pivotal role in Dataform's authentication architecture. It assumes the identity of the machine user to authenticate with GitHub as a collaborator, leveraging the machine user's PAT. It also authenticates with the staging and production environments by impersonating their respective custom service accounts using short-lived tokens generated with the serviceAccountTokenCreator role. Armed with this newfound understanding, we can confidently embark on the journey of provisioning Dataform within GCP using Terraform. Stay tuned for Part 2 of this article, where we will tackle this very subject. In the meantime, feel free to explore the code repository for further insights.

En résumé, le compte de service par défaut joue un rôle central dans l'architecture d'authentification de Dataform. Il assume l'identité de l'utilisateur de la machine pour s'authentifier auprès de GitHub en tant que collaborateur, en tirant parti du PAT de l'utilisateur de la machine. Il s'authentifie également auprès des environnements de transfert et de production en empruntant l'identité de leurs comptes de service personnalisés respectifs à l'aide de jetons de courte durée générés avec le rôle serviceAccountTokenCreator. Forts de cette nouvelle compréhension, nous pouvons nous lancer en toute confiance dans le processus de provisionnement de Dataform au sein de GCP à l'aide de Terraform. Restez à l'écoute pour la partie 2 de cet article, où nous aborderons ce sujet même. En attendant, n'hésitez pas à explorer le référentiel de code pour plus d'informations.

References:

Les références:

• [Dataform: Google Cloud](https://cloud.google.com/dataform?hl=en)
• [Dataform Migration: Google Cloud](https://cloud.google.com/dataform/docs/migration)
• [Dataform Best Practices: Google Cloud](https://cloud.google.com/dataform/docs/best-practices)

[Formulaire de données : Google Cloud](https://cloud.google.com/dataform?hl=en)[Migration de formulaires de données : Google Cloud](https://cloud.google.com/dataform/docs/migration)[Meilleur formulaire de données Pratiques : Google Cloud](https://cloud.google.com/dataform/docs/best-practices)