Security: IAM, API keys, hardening and the shared responsibility line
The Security domain tests identity, least privilege, key hygiene and the shared responsibility boundary: what Exoscale protects and what remains yours.
Identity and API access
IAM gives you users, roles and API keys. A key is a credential pair whose secret is shown once; treat it like a password hash. Bind keys to narrow roles rather than to an all-powerful account key, scope them to what the automation actually does, and rotate on a schedule. Human access should use named users with MFA rather than shared credentials, and portal/API activity should be exported to your logging stack so that "who deleted that volume" has an answer.
Network and host hardening
Security groups are the first control: role-based groups, no 0.0.0.0/0 on administrative ports, bastion or VPN for SSH. SSH keys are injected at boot; rotate them, and do not reuse a personal key for fleet automation. Cloud-init user-data is readable from inside the instance and via the metadata service, so never put secrets there - fetch them at runtime from a secrets manager.
Encryption and data handling
Data is encrypted in transit with TLS where the service offers it (DBaaS connection URIs, HTTPS object endpoints). For data at rest, combine platform-encrypted volumes and buckets with application-level encryption for crown jewels, so a mis-scoped snapshot is not a breach on its own. Secret material belongs in a dedicated secrets store, not in environment variables baked into templates.
Worked example
A CI pipeline must create volume snapshots before each release. Reasoning: the pipeline needs snapshot-create and snapshot-list on specific resources, not instance-delete. Create a role with exactly those permissions, issue a key bound to it, store the secret in the CI secret store (masked, never echoed), restrict the key to the CI egress range where supported, and rotate quarterly. If the pipeline is compromised, the blast radius is "can take snapshots", not "can destroy the estate".
Traps
Using one omnipotent API key everywhere; putting secrets in user-data; assuming a private IP is authentication; leaving a database port open "just for the migration"; and forgetting that deleted keys and departed employees' accounts both need explicit revocation.