Identity Isolation and Account Silos
Date posted: 2026-01-10
Objective: Establish a multi-cloud environment for ephemeral PoCs with high identity isolation.
1. Account Segmentation
- Administrative Layer: Primary Google Workspace account (moreserverless.com) used for domain management and high-level DNS.
- Control Plane (Azure/ADO): Dedicated Outlook service account created specifically for Azure DevOps project management.
- Infrastructure Target (GCP): Dedicated Gmail service account created to anchor the Google Cloud sandbox.
2. Implementation Steps
- Identity Linking: Established recovery links for the new service accounts using a primary phone number and existing email addresses to ensure account recovery and MFA stability.
- Organization Setup: Provisioned a fresh GCP Project ID under the dedicated service account to isolate resource quotas.
- ADO Project Initialization: Provisioned a new Azure DevOps Organization to isolate repositories and pipelines from other workstreams.
3. Technical Rationale ("The Why")
- Blast Radius Mitigation: Isolates billing and security anomalies within the experimental GCP sandbox; issues cannot propagate to the primary identity.
- Clean Room Testing: Ensures no legacy IAM permissions or global settings interfere with PoCs.
- Credential Hygiene: Forces explicit configuration of service connections, mirroring enterprise-grade security requirements.
- Portability: Decouples the infrastructure stack from personal data, making the environment modular and auditable.
This documentation was generated through an iterative AI process, refined by the author for technical accuracy and clarity.