Understanding the Use Case for Playwright MCP with Google Login
To automate operations on pages requiring Google login, such as Looker Studio, developers often integrate tools like Playwright MCP into their workflows. In this scenario, n8n workflows serve as the central automation engine. The challenge arises when these workflows need to manage Google logins for multiple teams, ensuring proper authentication and isolation.
One of the initial solutions considered was running Playwright MCP as a sidecar within the same Cloud Run instance as n8n. While this approach simplifies deployment, it introduces security risks. For instance, the Playwright MCP service becomes accessible to n8n without additional authentication, exposing logged-in sessions to unauthorized access.
Challenges with the Sidecar Approach
Although the sidecar method might seem straightforward, it has significant security and scalability gaps. For example, the Playwright MCP service, running on localhost, holds the Google login session without requiring authentication. This setup creates vulnerabilities by allowing any process inside the instance to access sensitive session data.
Furthermore, the sidecar approach does not adequately address the need for team-specific isolation. Since n8n is often shared across multiple teams, managing distinct login sessions for each team becomes cumbersome. Additionally, scaling challenges may arise, as multiple instances of the service could disrupt session continuity by redirecting user traffic to different instances.
Implementing a Defense-in-Depth Strategy
To overcome these limitations, a comprehensive defense-in-depth strategy was implemented. This approach involves splitting the Playwright MCP service into a separate Cloud Run service to decouple it from the n8n instance. This separation allows for better control over authentication and traffic routing.
Key components of the strategy include using internal ingress settings, per-team API keys, and an auth proxy service. The auth proxy verifies API keys, routes traffic based on the requested path, and attaches an ID token for authentication. These measures ensure secure communication between n8n and Playwright MCP while maintaining team-specific isolation.
Configuring Cloud Run and IAM Roles for Security
To enhance security, Cloud Run services are configured with ingress settings set to internal. This restricts access to services within the same VPC. Additionally, IAM roles such as roles/run.invoker are granted exclusively to the auth proxy's service account, limiting access to the Playwright MCP service.
By setting the maxScale parameter to 1 for the Playwright MCP service, session continuity is preserved. This prevents traffic from being redirected to multiple instances, which could disrupt ongoing sessions. Combined with VPC access and egress control, these measures form a robust security framework.
Practical Steps for Implementation
To replicate this setup, follow these steps:
- Separate the Playwright MCP service from the n8n instance by deploying it as a distinct Cloud Run service.
- Configure ingress settings to internal for both n8n and Playwright MCP services to restrict access to the VPC.
- Set up an auth proxy service to verify API keys and route traffic based on team-specific paths.
- Grant the roles/run.invoker IAM role only to the auth proxy's service account for secure service-to-service communication.
- Set the maxScale parameter to 1 for the Playwright MCP service to maintain session consistency across instances.
These steps provide a structured framework for securely automating Google login operations in n8n workflows using Playwright MCP. By addressing authentication and isolation challenges, this configuration ensures a scalable and secure solution.