Hive Hive
Sign in

docs(infra): require ElasticMetalFullAccess on the provider IAM key

GitHub issue · Closed

Metadata
Source
tuist/tuist #11363
Updated
Jun 24, 2026
Domains
Compute
Details

Why

The canary macOS runner-cache cutover wedged because the EM node never provisioned. The operator logs showed the reconciler 403ing on every cycle:

ScalewayElasticMetalMachine: tuist-tuist-kura-fleet-...
error: list elastic metal servers by name "...": scaleway-sdk-go: http error 403 Forbidden: Permission denied

The canary provider IAM policy had AppleSiliconFullAccess, IPAMReadOnly, PrivateNetworksFullAccess, SSHKeysFullAccess but not an Elastic Metal set. Elastic Metal is a separate Scaleway product from Apple Silicon (the name is the trap), so the operator could manage PNs/IPAM/Mac minis but got 403 on its first list elastic metal servers call and never ordered a node. The fix was adding ElasticMetalFullAccess to the policy.

What

  • infra/cluster-api-provider-scaleway-applesilicon/AGENTS.md: the IAM section claimed “exactly two permission sets” (AppleSiliconFullAccess + SSHKeysFullAccess), which predated the Elastic Metal kind and didn’t match the real policy. Replaced with the full set (AppleSiliconFullAccess, ElasticMetalFullAccess, PrivateNetworksFullAccess, IPAMReadOnly, SSHKeysFullAccess) and the role each plays.
  • docs/scaleway-elastic-metal-support.md: the IAM bullet listed only PrivateNetworksFullAccess + IPAMReadOnly; added ElasticMetalFullAccess with the 403 failure mode called out.

Note

Production’s tuist-production-capi policy needs the same ElasticMetalFullAccess grant before the cutover reaches it, or it will 403 identically.

🤖 Generated with Claude Code

Comments
TA
tuist-atlas[bot] Jun 19, 2026

This change is now available in capi-scaleway@0.9.1. Update to this version to pull the new Docker image with the updated IAM requirements.