Lekkerbezig

GCP → Scaleway Migration: Key Differences

Summary

For large organisations, Scaleway will not work. The lack of IAM isolation (org-scoped applications, no deny policies, no custom roles, no resource-level policies) and the absence of enterprise controls (no IAP, no workload identity, no organisation policies, no binary authorization) make it very hard to build a secure platform. Every guardrail that GCP enforces server-side must be reimplemented in CI/CD pipelines and Terraform modules, and remains bypassable by anyone with direct API access.

For a single company that does not need to isolate departments, Scaleway may be a good fit. The simpler hierarchy (organisation → project, no folders) and fixed permission sets are manageable when blast radius is contained to one team and trust boundaries are not required between departments.

Topic GCP Scaleway Impact
Identity-Aware Proxy (IAP) In GCP, IAP provides zero-trust access. It authenticates and authorises requests before they reach backend services. No VPN needed — users access internal apps through Google's identity layer. No equivalent service exists. Scaleway has no managed zero-trust proxy offering. Without IAP, we need an alternative for secure access to internal services. Options include a VPN, a reverse proxy with authentication (e.g., Caddy + OAuth2-Proxy), or restricting access at the network level (private subnets + bastion). Each adds operational overhead.
IAM Application Scoping (Service Accounts) In GCP, Service accounts are project-scoped. You grant custom or predefined roles per-project, enabling strict least-privilege. Resource-level IAM policies are widely supported (GCS, Pub/Sub, KMS, BigQuery, etc.). Deny policies and org policy constraints provide guardrails. IAM applications (service account equivalent) are always organisation-scoped — they cannot be created in or confined to a project. Permission grants can be scoped to org or project level, but the application identity itself is org-level. No custom roles exist — only fixed Scaleway-defined permission sets. Policies are allow-only (no deny, no guardrails). Almost no resources have resource-attached IAM policies (Object Storage buckets are the only exception, and they are intersective with IAM, not additive). Resource-level CEL conditions exist for IAM, Key Manager, and Secret Manager only. Least-privilege is significantly harder. The application identity is always org-scoped, so policy is the sole boundary. No deny policies means no guardrails — controls that would be deny policies in GCP must move to preventative tooling (Terraform checks, CI gates). No custom roles means you cannot fine-tune permissions beyond Scaleway's fixed catalogue. Resource-level access control is largely unavailable outside Object Storage.
Workload Identity Federation In GCP, External workloads (GitHub Actions, GitLab CI, AWS/Azure, other Kubernetes clusters) authenticate via short-lived tokens (OIDC/SAML/X.509) through STS — no long-lived service account keys needed. No native equivalent exists in Scaleway. Scaleway's IAM API has no token-exchange, identity-pool, or STS endpoint. SAML/SCIM federation covers human users only. CI/CD pipelines must use long-lived access-key/secret-key pairs stored as CI secrets. Every external automation (GitHub Actions, GitLab CI, etc.) requires a static API key that we must mint, store, and rotate manually.
Workload Identity In GCP, Managed workload identities bind GKE pods, Cloud Run instances, and Compute Engine VMs directly to service accounts. The workload receives short-lived tokens via the instance metadata endpoint. Scaleway has no native vm/pod/container to IAM application binding. Pods must obtain credentials via Secret Manager or External Secrets, which relocate the key rather than eliminate it. The bootstrap key for the CSI/ESO controller itself is unavoidably long-lived — the secret-zero problem. Every Kapsule workload ends up holding a static API key. Secret Manager CSI improves storage hygiene and enables central rotation, but a bootstrap key is always required. Budget for rotation tooling and secret-sprawl auditing that GKE Workload Identity provides out of the box.
Organization Policies In GCP, Organization Policy Service provides centrally-managed, hierarchy-inherited preventative constraints on how resources may be configured — independent of IAM. ~200 managed constraints (restrict resource locations, block VM external IPs, block Cloud SQL public IP, disable service-account key creation, domain-restricted sharing, GKE hardening) plus custom CEL constraints, with dry-run mode and Policy Simulator. Scaleway has no equivalent. Scaleway's IAM conditions only expose request.ip, request.time, request.user_agent — no resource-configuration or region attributes. The only org-wide guardrails are MFA enforcement, member security requirements, and API-key max duration. Data residency, "no public IP / no public bucket", and credential-hygiene rules cannot be enforced server-side. They must be shifted left into Terraform/OpenTofu modules + policy-as-code in CI, backed by Audit Trail for detection. Enforcement depends on nobody holding direct create permissions outside the pipeline — bypassable by design rather than blocked.
Binary Authorization In GCP, Binary Authorization enforces deploy-time admission control for GKE, Cloud Run, Cloud Service Mesh, and Distributed Cloud. Policies require cryptographic attestations (signed image digests) from trusted attestors — non-conforming images are blocked at deploy. Native Cloud Build / Artifact Registry / Artifact Analysis integration, plus continuous validation re-checking running pods against Sigstore, SLSA, and vulnerability checks. Breakglass and dry-run modes supported. Scaleway has no equivalent. Container Registry offers only push/pull and public/private visibility — no image signing, attestation, provenance, or vulnerability scanning. Supply-chain gating becomes self-operated: cosign in CI plus self-installed Sigstore policy-controller or Kyverno on Kapsule, with our own key custody, webhook HA, and policy rollout. Serverless Containers cannot block unsigned images by any means. Expect a compliance-narrative gap for SLSA / supply-chain-integrity controls that GCP satisfies with a managed, audited service.

Summary

For large organisations, Scaleway will not work. The lack of IAM isolation (org-scoped applications, no deny policies, no custom roles, no resource-level policies) and the absence of enterprise controls (no IAP, no workload identity, no organisation policies, no binary authorization) make it very hard to build a secure platform. Every guardrail that GCP enforces server-side must be reimplemented in CI/CD pipelines and Terraform modules, and remains bypassable by anyone with direct API access.

For a single company that does not need to isolate departments, Scaleway may be a good fit. The simpler hierarchy (organisation → project, no folders) and fixed permission sets are manageable when blast radius is contained to one team and trust boundaries are not required between departments.