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.