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.
Hive
docs(infra): require ElasticMetalFullAccess on the provider IAM key
GitHub issue · Closed
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 onlyPrivateNetworksFullAccess+IPAMReadOnly; addedElasticMetalFullAccesswith 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