A Scaleway API key lets whoever holds it call the Scaleway API as the user or application it was issued to. The holder can create and delete instances, read and write object storage, change DNS records and manage other resources in the projects that key can reach. Keys belong to an account and carry the permissions granted to their owner, so a leaked key of an administrator is a serious event. Delete the exposed key first, then check what it did.
Check your GitHub account for leaked secrets — free
- Provider
- Scaleway
- Severity
- High
- Impact
- Cloud infrastructure access
- Checked live by LeakWatch
- No
What a Scaleway API Key looks like
A Scaleway API key is made of two values. The access key begins with a fixed prefix and has a short random body, and the secret key is a UUID-shaped value with dashes between its groups:
SCW…XXXX access key (masked)
The access key on its own does not authenticate a request. The secret key is what signs requests, so a leak that contains only the access key is less urgent than one that contains both. The SCW prefix identifies Scaleway, so an access key with that prefix is rarely a false alarm. The secret key is harder to tell apart from other identifiers, because a UUID is common. What makes it recognizable is context: the word scaleway near the value, or an environment variable that names the service.
How Scaleway API keys get leaked
- Committed environment files. Scaleway variables in a
.envfile or a shell profile that was committed with the rest of the project. - Hard-coded clients. A script or a Terraform provider block that sets the key directly, then pushed to a public repository.
- Continuous integration. A pipeline that writes the keys into a configuration file or prints them in a debug step.
- Shared dotfiles. A command-line configuration file that stores the key in plain text and was copied into a shared repository.
- Screenshots and tickets. A console or terminal capture posted to a forum or a support request with the value visible.
What to do in the first hour
- Identify the key and its owner. In the Scaleway console, go to the identity and access management section and open the API keys list. Match the access key to an entry there. Note whether it belongs to a person or an application, and which projects it can reach.
- Create a replacement. Create a new key for the same owner and deploy it to your secret store or environment. Confirm that your services still work before the old key goes.
- Delete the exposed key. Deleting it stops every request signed with it. Deletion cannot be undone, so confirm that the replacement is in place first.
- Check the audit trail. Scaleway’s Audit Trail records actions taken through the API and the console. Filter by the exposed access key and the period since the exposure. Look for new instances, new keys, object storage activity and changes to security groups or DNS.
- Look for persistence. An attacker often creates another API key or invites a user. Review the keys and members of the project, and remove anything you cannot explain.
- Review the projects. If the key had access to several projects, check each one for resources you did not create.
- Clean the repository. Remove the values and rewrite history if you want to. See I accidentally pushed an API key to GitHub and Deep scan your whole git history.
Not sure what else leaked? Run a free scan.
Revoke it at Scaleway
API keys are managed in the identity and access management section of the Scaleway console. Open the API keys page, find the key by its access key, and delete it. Make sure the correct organization and project are selected, because a key listed under one account will not appear under another. Keys that belong to a person are removed from that person’s profile, while keys for applications are managed from the application’s entry. If the labels differ from this description, look for the API keys list in the identity section, and follow Scaleway’s documentation for the current steps.
How LeakWatch detects it
The rule is called Scaleway API Key. It looks for the word scaleway in any letter case, followed within about 40 characters by a UUID-shaped value, which is the secret key. The value must have the standard grouping of 8, 4, 4, 4 and 12 characters with dashes, and a shorter or differently grouped value is not reported. The access key is not the part the rule keys on, so an access key without a nearby secret will not produce a finding. The severity is high. This type is not checked live: LeakWatch does not send any request to Scaleway with the value it found.
LeakWatch detects this format but does not check it live: it can tell you the key is exposed, not whether it still works. Assume it does until you have revoked it.
FAQ
Why is the secret key harder to detect than the access key?
A UUID is a common shape for identifiers, so the rule needs the word scaleway close by. A secret key pasted without that word nearby can be missed, which is one reason to search your own repositories for the access key prefix as well.
If only the access key leaked, do I need to act?
Yes. Delete it, because the access key is part of the same credential and its partner may be stored elsewhere in the same project. The secret key is the more sensitive half.
Can I give an application a narrower key?
Yes. Create a key for each application and grant it only the projects and permissions it needs, so that a leak affects one service.