Cloud
What this screen is for
The Cloud tab holds the credentials Fenwave uses to talk to your cloud accounts. Clusters can authenticate through these credentials rather than carrying their own, so this is usually the first thing registered on a new install.
Three provider types are supported: AWS, GCP, and Kubernetes.
Before you start
| To do this | You need |
|---|---|
| See the tab | platform-settings.cloud.read |
| Add a credential | platform-settings.cloud.create |
| Edit one | platform-settings.cloud.update |
| Delete one | platform-settings.cloud.delete |
| Validate one | platform-settings.cloud.validate |
Have the credential itself ready before you start — the dialog does not save partially.
Opening it
- Settings › Infrastructure
- Select the Cloud tab (it opens here by default).
The interface
📸 Screenshot Placeholder: The Cloud tab with one AWS credential. Mark: (1) Add button, (2) the provider column, (3) the region, (4) the status, (5) the validate action.
| # | Control | What it does | When you’d use it |
|---|---|---|---|
| 1 | Add | Opens the credential dialog | Registering an account |
| 2 | Provider | AWS, GCP, or Kubernetes | Identifying the credential |
| 3 | Region | The default region, for AWS | Confirming where resources are expected |
| 4 | Status | Whether the credential is currently valid | Triage |
| 5 | Validate | Tests the credential now | After any rotation |
The dialog changes shape entirely with the provider — the AWS, GCP and Kubernetes forms ask for different things, and switching the provider resets the fields that no longer apply. Choose the provider first.
Walkthroughs
Register an AWS account
Requires platform-settings.cloud.create.
- Settings › Infrastructure › Cloud, click Add.
- Choose AWS as the provider.
- Choose the authentication method and fill in the credential.
- Set the default region. It defaults to
us-east-1, which is rarely what you want — set it deliberately. - Save, then validate.
Register a GCP account
Same flow, choosing GCP. The form asks for GCP’s own credential shape rather than AWS keys.
Rotate a credential
Requires platform-settings.cloud.update and .validate.
- Edit the credential and replace the secret.
- Save, then validate immediately.
- Re-validate any cluster that authenticates through this credential — a cloud credential rotation propagates to them, and a cluster left unvalidated will fail at the next deployment rather than now.
Scenario
Deployments to EKS started failing overnight; nothing was changed.
- Settings › Infrastructure › Cloud — check the status of the AWS credential.
- If it is invalid, the access key expired or was revoked. This is the common case for static keys, and it is why IRSA and Pod Identity exist.
- Issue a replacement, edit the credential, save, and validate.
- Go to Clusters and validate every cluster that authenticates through this credential. Fixing the cloud credential does not by itself mark those clusters valid again.
- Retry the deployment.
If step 1 shows the credential is fine, the problem is on the cluster rather than the account — continue on the Clusters page.
When it doesn’t work
| Symptom | Cause | How to check | Fix |
|---|---|---|---|
| Credential invalid, nothing was changed | A static key expired or was revoked | Validate the credential | Issue a new one; consider IRSA or Pod Identity to avoid the recurrence |
| Validation passes but clusters still fail | Clusters carry their own status and were not revalidated | The Clusters tab | Validate each affected cluster |
| Resources appear in an unexpected region | The AWS default region was left at us-east-1 |
The region column | Edit the credential and set the correct region |
| Fields vanished after switching provider | The form is provider-specific and resets | — | Expected; choose the provider first, then fill in |
| Cannot validate although you can edit | Validation is its own permission | Access Explorer | Ask for platform-settings.cloud.validate |
Next
- Clusters — register clusters against this account