The modern engineering landscape is increasingly multi-cloud. Whether driven by a desire for redundancy, specialized services, or geographic reach, many organizations find themselves managing resources across AWS, Azure, and Google Cloud Platform (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 will 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 of these 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 for engineering teams to navigate.
The AWS IAM Identity Center Architecture
Setting up AWS IAM Identity Center (formerly AWS SSO) is a comprehensive process that reflects the platform's focus on security at scale. First, you must manage AWS Organizations, which involves coordinating a management account. Then, you define permission sets. These sets are highly detailed templates that allow for precise access control, but they must be mapped to specific users or groups across every account in your organization. If you are managing a large-scale environment with dozens or hundreds of accounts, this mapping process requires careful planning and execution.
Furthermore, if your primary identity source is Azure AD or Okta, you engage in a detailed SAML 2.0 integration. This involves managing XML metadata exchanges, certificate rotations, and SCIM provisioning. These steps ensure that identity lifecycle management is consistent, but they also mean your DevOps team is responsible for maintaining a complex chain of configurations to ensure that access remains both secure and up to date.
Navigating Google Cloud Identity
Google Cloud Platform (GCP) provides powerful identity features through Google Workspace and Cloud Identity. For organizations rooted in the Microsoft ecosystem, integrating these identities into GCP often involves deploying Google Cloud Directory Sync (GCDS). This tool is essential for keeping directories in sync, but it represents an additional component within your infrastructure that requires ongoing management and monitoring.
Google's modern Workload Identity Federation is a best-in-class standard for secure, keyless access. However, implementing it correctly requires a deep understanding of workload identity pools and providers. Crafting the specific IAM policies needed to allow external identities to securely interact with GCP resources is a sophisticated task. For teams focused on rapid application delivery, navigating these advanced security configurations can become a time-intensive part of the deployment cycle.
Enterprise Identity with Azure Entra ID
Azure Entra ID is the foundation of identity for a vast number of enterprises. While it provides an excellent source of truth, extending that identity to gate access across a multi-cloud estate introduces layers of administrative detail. This involves managing Enterprise Applications and App Registrations, each with its own set of client secrets, certificates, and API permissions.
The result is that DevOps engineers often find themselves acting as specialized Identity Architects. They spend a significant portion of their bandwidth syncing groups, rotating keys, and ensuring consistent policies across multiple portals. This level of detail is a testament to the power of these platforms, but it can also lead to fragmented workflows that challenge even the most experienced teams.
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. As a third-party platform designed to work alongside these major providers, our goal is to help you get the most out of your multi-cloud strategy by reducing the administrative overhead associated with identity.
The core philosophy of MechCloud is to decouple authentication (who you are) from infrastructure management (what you are doing). To achieve this, 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
As shown in our architectural diagram, the bridge between your users and MechCloud is a lightweight tool called oauth2-proxy.
By deploying oauth2-proxy within your network, you ensure that authentication remains under your control. The browser communicates with MechCloud, which in turn delegates the identity verification to the oauth2-proxy sitting in your environment.
It is critical to note that your oauth2-proxy instance must be exposed to the internet. This is a requirement because the MechCloud backend needs to interact with the proxy to validate session cookies. This interaction ensures that every request is coming from a legitimately authenticated user and allows MechCloud to provide a seamless management experience while your OIDC provider remains the ultimate gatekeeper.
From a privacy and security perspective, MechCloud only sees the session cookies generated by your oauth2-proxy and nothing more. Your user passwords and primary OIDC credentials never touch the MechCloud backend directly during the login process.
Getting Started: Tenant Configuration
To ensure a secure and properly architected foundation, MechCloud handles the initial tenant creation through its support team. Organizations do not need to navigate a complex self-service portal for initial setup.
To get started, an organization simply needs to share their intended tenant administrator email and the URL where their oauth2-proxy will be hosted. Once these details are ready, reach out to the MechCloud support team at support@mechcloud.io. Our team will create a unique tenant mapping for you (e.g., tenant1). While this mapping defines your environment internally, you can access the portal via your custom domain.
If you wish to use a custom domain, the support team will configure the backend to recognize it. This high-touch approach guarantees that your multi-cloud management environment is solid and secure from day one.
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. Here is how you set up a secure, containerized SSO flow.
1. Register an Application in Your OIDC Provider
First, you need to register an application in your provider (e.g., Azure Entra ID or Okta). 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/callbackNote your Application (client) ID and Directory (tenant) ID.
Create a new Client Secret and save the value securely.
2. Configure DNS Settings for Your Custom Domain
To enable access via mechcloud.cloudops.io, you must configure your DNS server. This step is essential for routing traffic correctly between your users and the MechCloud backend.
- CNAME Record for Portal: Create a
CNAMErecord formechcloud.cloudops.iopointing to the global MechCloud portal address:portal.mechcloud.io. This ensures that users visiting your custom domain are directed to the MechCloud management layer, which then identifies your specific tenant based on the incoming hostname.
Ensuring this DNS record is properly propagated allows MechCloud to initiate the session validation handshake with your local proxy.
3. Prepare the oauth2-proxy Docker Environment
Below is a production-ready docker-compose.yml snippet. This configuration ensures that authentication headers are correctly set and that the proxy can communicate with the necessary identity endpoints. Ensure all URLs are updated to match your domain.
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](https://mechcloud.cloudops.io/oauth2/callback)"
OAUTH2_PROXY_OIDC_ISSUER_URL: "[https://id.cloudops.io/](https://id.cloudops.io/)"
OAUTH2_PROXY_OIDC_EXTRA_AUDIENCES: "[https://id.cloudops.io/userinfo,https://mechcloud.cloudops.io/](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
The core strength of the MechCloud platform is its security posture. 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 they are ever leaked or mismanaged.
MechCloud eliminates this risk by leveraging identity federation across all major cloud providers. This ensures that you never have to share or store sensitive secrets on the MechCloud platform.
Establishing Trust with Your OIDC Provider
Crucially, MechCloud does not require your cloud accounts to trust our platform directly. Instead, you establish a trust relationship between your cloud provider (AWS, Azure, or GCP) and your own OIDC provider (e.g., Azure Entra ID or Okta).
AWS with IAM Roles: You create an
IAM rolein your AWS account that trusts your OIDC provider as an Identity Provider (IdP). When a user needs to perform an action, MechCloud leverages the OIDC token issued by your provider to exchange it for short-lived AWS session credentials.GCP via Workload Identity Federation: You configure a
Workload Identity Poolin GCP that trusts your OIDC provider. MechCloud uses your provider tokens to securely impersonate a GCP service account without ever needing a Service Account JSON key.Azure Federated Credentials: Similarly, for Azure, you set up
federated identity credentialsfor your Service Principal that trust your OIDC provider.
By establishing trust directly with 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. You retain full control over the trust relationship within your own identity system.
The Operational Advantage
This integrated approach offers profound benefits that enhance the native capabilities of your cloud providers:
Unified Offboarding: When a developer leaves your organization, you disable their account in your OIDC provider. This immediately breaks the
oauth2-proxychain, ensuring that access to the MechCloud management layer is severed. This centralizes control and reduces the risk of maintaining active access across disparate systems.Cohesive Security Policies: Instead of managing different MFA requirements and session policies for three different clouds, you can enforce your high-level corporate security standards in your OIDC provider once. This ensures that your entire multi-cloud infrastructure is protected by the same rigorous standards you apply to your primary directory.
Enhanced Developer Workflow: Developers thrive when they can focus on solving problems rather than navigating consoles. MechCloud provides a consistent interface for services across AWS, Azure, and GCP. Whether they are provisioning a VM in AWS or a database in Azure, the experience is unified, allowing your team to move faster and with greater confidence.
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 sheer 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 what matters most: building and scaling your applications.
Reclaim your engineering bandwidth and secure your multi-cloud estate with our credential-less onboarding architecture. Reach out to support@mechcloud.io today to set up your tenant and experience a more streamlined approach to cloud management.
Are you managing identities across multiple cloud providers? We would love to hear about your workflow and how you handle the complexity!
Top comments (0)