This post is for Day 4 of Mercari Advent Calendar 2025, brought to you by @whhygee from the Mercari Enablement Tools & Interfaces team.
At Mercari, the Enablement Tools and Interfaces team—responsible for developer experience and CI/CD—is building a service called Single Front Door (SFD). SFD provides developers with a single, unified interface to our Platform and helps us scale GitOps across thousands of components. We do this by combining our widely used internal command-line tool with various external services—such as Google Cloud services—to streamline the developer experience, enforce governance, maintain consistency, and make large-scale GitOps manageable.
We recently introduced a cloud-hosted Model Context Protocol (MCP) server as an additional interface, allowing developers to access all workflows and platform capabilities directly through AI-powered tools, including their integrated development environments (IDEs).
Concept
Mercari Group’s platform has grown up for years to run hundreds of production services and over 1600+ active repositories, wherein many tools—such as infrastructure-as-code repositories, abstraction framework for infrastructure configurations and application manifests, in-house CI/CD systems and many more—have been provided to support development. However, these components were missing a centralized interface. This forced developers to understand and interact with each of them separately, which demanded making changes in at least 5 repositories and completing about a dozen steps to release new services in production. Some examples of the most common interactions with the platform include:
- Commit ‘Infrastructure as Code’ for resource management
- Commit Kubernetes Manifests for service configurations
- Commit Protobuf definitions for intra-service communication
- Setup debug environments using external tools/services
- Commit edits to delete/manage cloud resources
This was reported as one of the pain points to development productivity. In response, we built “SFD” as a new unified interface for Mercari Group’s platform, so users no longer need to touch multiple tools directly when they want to perform common platform operations
Since Mercari relies heavily on GitOps, most operations involving platform tools could be performed through predefined workflows which modify files via templates. These workflows use developer credentials for making changesets on our repositories on their behalf. Users can just use SFD to trigger said workflows—either through our internal CLI tool or by directly chatting with an AI agent through their IDEs and an MCP server (example below)—which will then perform subsequent steps like making changes in configuration repositories on behalf of the users themselves.
System Design
A workflow triggered through SFD goes through the following lifecycle:
- Users authenticate to SFD’s through an OAuth flow and express intent through CLI prompts or natural human language input through AI chat in their IDEs.
- The user interface (CLI or IDE agent) sends a corresponding workflow request to the backend along with the OAuth token.
- Backend stores workflow metadata safely, then triggers a workflow using Argo Workflows.
- Argo Workflows spins up execution containers for each step of the workflow.
a. These steps are executed sequentially following a ‘Directed Acyclic Graph’ defined in the workflow definition. - Kubernetes containers for each step of the workflow execute business logic, creating changesets on GitHub or other relevant components.
Disclaimer: Logos are trademarks of their respective owners.
Challenges
Safeguarding GitOps at Scale
One of the most critical elements of a successful GitOps practice is the scope of access held by the committer. GitOps treats the Git repository as the definitive configuration and operational ledger wherein who (or what) is allowed to commit becomes just as important as what is being committed.
This means every commit has the potential to trigger real, automated changes—deployments, rollouts, environment modifications, policy shifts, and in some cases (as applicable to Mercari) full-scale infrastructure provisioning. Because of this, the credentials associated with each commit effectively serve as an execution token with potentially wide operational blast radius.
In this setup, we make sure each workflow’s changes are done by:
- Using the user’s own credentials, so self-triggered workflows don’t bypass human review.
- Limiting automations to only the action scopes they actually need.
The team’s solution was to start an OAuth flow using our organization’s GitHub App before triggering any workflow. This gives each user a temporary access token for the app, ensuring that workflows can only interact with the repositories and components the GitHub App is permitted to access—regardless of the user’s personal permissions—reducing the blast radius.
The token is then sent to the backend, where it is encrypted and stored in a centralized datastore. Each workflow job (running in separate container pods) retrieves this token during execution, so every changeset is created using the same credentials despite each job running in its own isolated environment.
Configuring IAM + RBAC to Provide Safe Access to External Services
Another major challenge was giving both our core backend services and our Argo Workflows job containers safe access to external systems—GCP services (Secret Manager, Datastore, KMS, Pub/Sub), GitHub, GetDX, and Slack—without embedding static credentials or granting broad permissions. This was critical because our architecture follows a zero-trust model, where each workload must prove its identity and only receives the minimum access it needs.
Argo Workflows helped us address this cleanly using GCP Identity and Access Management (IAM) and Kubernetes Role-Based Access Control (RBAC). Every workflow step runs under its own Kubernetes Service Account, which we map to a tightly scoped GCP Service Account through Workload Identity. This gives each step least-privileged access to GCP APIs (e.g., secretmanager.secretAccessor, pubsub.publisher, datastore.viewer) with no shared credentials or long-lived tokens.
Our backend services follow the same pattern: each service has its own identity, its own limited permissions, and no secrets injected into pods. RBAC controls what workloads can do inside the cluster, while IAM controls what they can do in GCP. Together, they enforce strong isolation and naturally support our zero-trust design.
Envisioned End State / Golden Path
In the end state we’re working toward, this service becomes a fully modular workflow engine, where every stage of the application lifecycle is built from reusable, well-defined building blocks. Each block represents a platform capability—service configuration, infrastructure provisioning, service mesh enablement, observability, CI/CD integration, and more—and teams can assemble them into workflows that meet their needs while still following platform standards.
Instead of writing custom automation for every service, developers simply use these prebuilt building blocks, which already package production-ready defaults: Terraform modules, Kubernetes manifests, service templates, logging/metrics pipelines, and so on.
This model is intentionally extensible. Platform teams can add new building blocks for their components whenever they want to expose their capabilities through SFD, promoting innersource by design. As the platform expands, so does the catalog of reusable steps—allowing workflows to evolve naturally while staying aligned with organizational best practices.
If you’d like to explore more great work by Mercari’s Engineering teams, be sure to check out our Engineering Portal.
Tomorrow’s article will be by @mattsuu. Merry Christmas!
