Taming the Multi-Cloud Identity Beast: Why Unified SSO is Essential and How MechCloud Simplifies It

The modern engineering landscape is increasingly multi-cloud. Whether driven by redundancy, specialized services, or geographic reach, many organizations manage resources across AWS, Azure, and GCP simultaneously. On paper, this strategy is the pinnacle of resilience. In practice, it can lead to a significant administrative surface area, particularly when it comes to Identity and Access Management (IAM).

If you have ever tried to set up a unified Single Sign-On (SSO) experience across all three major providers, you know the effort involved. You are not just configuring one system; you are reconciling three fundamentally different philosophies of security. In this post, we explore why native cloud SSO involves such high levels of complexity and how you can use MechCloud and oauth2-proxy to create a seamless, secure, and developer-friendly login experience in minutes.

Streamlining the Multi-Cloud Experience

AWS, Azure, and GCP offer incredibly sophisticated SSO capabilities. AWS has IAM Identity Center, GCP has Cloud Identity, and Microsoft has Azure Entra ID. Each is a robust, enterprise-grade solution designed to provide deep, granular control within their respective ecosystems. However, when an organization scales across all three, the sheer depth of these individual platforms can create a management challenge.

The AWS IAM Identity Center Architecture

Setting up AWS IAM Identity Center (formerly AWS SSO) is a comprehensive process. First, you must manage AWS Organizations, which involves coordinating a management account. Then, you define permission sets - highly detailed templates that must be mapped to specific users or groups across every account in your organization.

If your primary identity source is Azure AD or Okta, you engage in a detailed SAML 2.0 integration involving XML metadata exchanges, certificate rotations, and SCIM provisioning. Your DevOps team becomes responsible for maintaining a complex chain of configurations.

Navigating Google Cloud Identity

For organizations rooted in the Microsoft ecosystem, integrating identities into GCP often involves deploying Google Cloud Directory Sync (GCDS) - an additional component requiring ongoing management and monitoring.

Google’s Workload Identity Federation is best-in-class for secure, keyless access. However, implementing it correctly requires deep understanding of workload identity pools and providers, and crafting specific IAM policies for external identities to interact with GCP resources.

Enterprise Identity with Azure Entra ID

Azure Entra ID is the foundation of identity for a vast number of enterprises. Extending that identity to gate access across a multi-cloud estate introduces layers of administrative detail - managing Enterprise Applications and App Registrations, each with its own client secrets, certificates, and API permissions.

The result is that DevOps engineers often find themselves acting as specialized Identity Architects, spending significant bandwidth syncing groups, rotating keys, and ensuring consistent policies across multiple portals.

Enter MechCloud: The Orchestration Layer

MechCloud was built to complement these powerful cloud ecosystems. Instead of replacing the identity systems you already trust, it acts as a unified orchestration layer that simplifies how you interact with them.

The core philosophy is to decouple authentication (who you are) from infrastructure management (what you are doing). MechCloud leverages the OpenID Connect (OIDC) standard, allowing you to use your existing identity provider as the single source of truth for your entire multi-cloud estate.

The Technical Bridge: oauth2-proxy

The bridge between your users and MechCloud is a lightweight tool called oauth2-proxy.

By deploying it within your network, you ensure that authentication remains under your control. The browser communicates with MechCloud, which delegates identity verification to the oauth2-proxy sitting in your environment.

Your oauth2-proxy instance must be exposed to the internet. This is required because the MechCloud backend needs to interact with the proxy to validate session cookies. This ensures every request comes from a legitimately authenticated user.

From a privacy and security perspective, MechCloud only sees the session cookies generated by your oauth2-proxy - nothing more. Your user passwords and primary OIDC credentials never touch the MechCloud backend directly during the login process.

Getting Started: Tenant Configuration

MechCloud handles initial tenant creation through its support team. To get started, share your intended tenant administrator email and the URL where your oauth2-proxy will be hosted. Reach out to support@mechcloud.io and the team will create a unique tenant mapping for you.

If you wish to use a custom domain, the support team will configure the backend to recognize it.

Step-by-Step: Setting Up the Identity Gateway

Suppose your company uses the domain cloudops.io and the support team has assigned you the mapping tenant1. You want your team to access MechCloud at mechcloud.cloudops.io.

1. Register an Application in Your OIDC Provider

If using Azure Entra ID:

• Go to the Azure Portal and navigate to Microsoft Entra ID > App registrations > New registration
• Name it “MechCloud SSO”
• For the Redirect URI, select “Web” and enter: https://mechcloud.cloudops.io/oauth2/callback
• Note your Application (client) ID and Directory (tenant) ID
• Create a new Client Secret and save the value securely

2. Configure DNS Settings

Create a CNAME record for mechcloud.cloudops.io pointing to portal.mechcloud.io. This ensures users visiting your custom domain are directed to the MechCloud management layer, which identifies your specific tenant based on the incoming hostname.

3. Prepare the oauth2-proxy Docker Environment

Below is a production-ready docker-compose.yml snippet:

services:
  mechcloud-oauth2-proxy:
    image: quay.io/oauth2-proxy/oauth2-proxy:latest
    container_name: oauth2-proxy
    command:
      - --email-domain=*
      - --cookie-domain=.cloudops.io
    environment:
      OAUTH2_PROXY_HTTP_ADDRESS: "0.0.0.0:5000"
      OAUTH2_PROXY_SET_XAUTHREQUEST: "true"
      OAUTH2_PROXY_PROVIDER: "oidc"
      OAUTH2_PROXY_DISPLAY_NAME: "Customer OIDC"
      OAUTH2_PROXY_CLIENT_ID: "YOUR_CLIENT_ID"
      OAUTH2_PROXY_CLIENT_SECRET: "YOUR_CLIENT_SECRET"
      OAUTH2_PROXY_COOKIE_SECRET: "YOUR_SECURE_COOKIE_SECRET"
      OAUTH2_PROXY_REDIRECT_URL: "https://mechcloud.cloudops.io/oauth2/callback"
      OAUTH2_PROXY_OIDC_ISSUER_URL: "https://id.cloudops.io/"
      OAUTH2_PROXY_OIDC_EXTRA_AUDIENCES: "https://id.cloudops.io/userinfo,https://mechcloud.cloudops.io/"
      OAUTH2_PROXY_SKIP_JWT_BEARER_TOKENS: "true"
      OAUTH2_PROXY_SET_AUTHORIZATION_HEADER: "true"
    restart: always
    network_mode: host

Once this container is running and exposed to the internet, the MechCloud support team can finalize your tenant configuration.

Credential-less Onboarding: The Power of Identity Federation

Traditionally, onboarding a cloud account into a management tool meant creating and storing long-lived secrets like AWS Access Keys or GCP Service Account keys. These secrets represent a major security liability if leaked or mismanaged.

MechCloud eliminates this risk by leveraging identity federation across all major cloud providers. You never have to share or store sensitive secrets on the MechCloud platform.

Establishing Trust with Your OIDC Provider

MechCloud does not require your cloud accounts to trust our platform directly. Instead, you establish a trust relationship between your cloud provider and your own OIDC provider:

• AWS with IAM Roles - You create an IAM role that trusts your OIDC provider as an Identity Provider (IdP). MechCloud leverages the OIDC token to exchange it for short-lived AWS session credentials.
• GCP via Workload Identity Federation - You configure a Workload Identity Pool that trusts your OIDC provider. MechCloud uses your provider tokens to securely impersonate a GCP service account without needing a Service Account JSON key.
• Azure Federated Credentials - You set up federated identity credentials for your Service Principal that trust your OIDC provider.

MechCloud functions as a stateless orchestration layer. We store no credentials, and we never hold a permanent trust relationship with your cloud accounts.

The Operational Advantage

1. Unified Offboarding - When a developer leaves, you disable their account in your OIDC provider. This immediately breaks the oauth2-proxy chain, severing access to MechCloud and all connected cloud accounts.
2. Cohesive Security Policies - Instead of managing different MFA requirements and session policies for three clouds, enforce your corporate security standards in your OIDC provider once.
3. Enhanced Developer Workflow - MechCloud provides a consistent interface across AWS, Azure, and GCP. Whether provisioning a VM in AWS or a database in Azure, the experience is unified.

Conclusion

A multi-cloud strategy is a powerful way to build resilient global infrastructure. While the identity systems provided by AWS, Azure, and GCP are robust and feature-rich, the variety of their configurations can lead to complexity. By using MechCloud as your orchestration layer and oauth2-proxy as your identity gatekeeper, you can simplify these workflows and focus on building and scaling your applications.

Reach out to support@mechcloud.io to set up your tenant and experience a more streamlined approach to cloud management. Join our Discord community to share your workflow and connect with other multi-cloud teams.