Skip to content
Sencai.docs

Inherited cloud account

Somebody left, or a company was acquired, and now you hold a cloud console login and a spreadsheet nobody trusts. The first job is not to fix anything - it is to establish what exists, where it runs, and what it costs. Sencai is useful here specifically because the discovery path is read-only: you can answer “what have we got” without a single change landing in the provider account.

The exercise is three moves. Create a credential at the provider that can only read. Connect it and run one scan. Then triage what comes back, and export the list for whoever asked the question. None of those three steps creates, modifies, or deletes anything in the account.

Two expectations to set before you start. Sencai tells you what exists; it does not tell you what depends on what, and it has no record of the account from before you connected it. And it does not enforce read-only on your behalf - that guarantee comes entirely from the scope of the credential you create at the provider, which is why creating it is step one rather than an afterthought.

What this looks like in Sencai

Section titled “What this looks like in Sencai”

1. Create the narrowest credential the provider allows. Permissions your credentials need has the recipe per provider. For AWS there is a paste-ready read-only policy of 39 actions, every one of them a Describe, List, or Get - it cannot read object contents, secret values, table rows, or IAM policy documents, which is the argument you will need with whoever still owns the account. For Hetzner it is one choice while creating the API token: Read rather than Read & Write. Azure needs Reader on the subscription, Google Cloud needs roles/viewer on the project, and OVHcloud lets you grant GET only. Two providers cannot be scoped this way at all - see the surprises below.

2. Connect and validate it. Cloud credentials live on Settings → Cloud Credentials (/gravity/settings/cloud-credentials), and adding one requires the Admin or Owner role. Give it a name that says which inherited account it is, because there will probably be more than one. Saving does not check the credential - click Validate on its row afterwards. Full form details are in Connect a cloud provider.

3. Run one scan. Click Run scan on the validated credential’s row. The scan is read-only and runs in the background, so you get a confirmation rather than an instant result, and the findings appear in the inventory shortly after. Import existing infrastructure covers the whole flow.

4. Triage in the inventory. Everything the scan found lands in Compliance & Audit → Inventory (/gravity/inventory) in the Unmanaged state - visible, but nothing Sencai acts on. Each row carries the provider, region, resource type, the provider’s own external ID, the tags as they exist at the provider, and the raw metadata behind them. Filter by provider, region, type, tag, or ownership state, then export the current view as CSV or JSON. For an inherited account that export is usually the actual deliverable. Inventory explains the four ownership states in full.

5. Decide ownership - and note which choice writes to the account. Selecting resources and choosing Adopt sets how Sencai treats them: Manage with Sencai, Read-only tracking, or Ignore. The first two write a small set of Sencai tags onto the real resource at the provider; Ignore writes nothing and is the right answer for anything decommissioned or out of scope. All three need the Member role or higher, so an Auditor or Viewer - the roles you would naturally give a reviewer - can read the inventory but not change ownership.

6. Leave promotion until after the triage. Promoting a discovered resource (Import as managed instance / network / disk, Admin or higher) creates a first-class managed record where start, stop, and destroy become real operations against the real resource. Promoting changes nothing at the moment you do it, but it converts a survey into an operational commitment, and a server brought in this way does not automatically get the Sencai-managed access account or the browser terminal that a freshly provisioned instance gets - that setup only runs on an instance’s first boot, which happened long before you arrived.

What will surprise you

Section titled “What will surprise you”

An under-privileged credential validates green and simply returns less. On AWS, validation calls an identity check that no IAM policy can restrict, so a key with a completely empty policy still validates successfully. Each service is then scanned independently, and a denial on one of them is recorded and skipped while the scan still reports success. Judge a credential by the resource counts the first scan returns, not by the validation badge. The symptom - a scan that completes with an empty or suspiciously short inventory - and what to check for it belong to Troubleshooting.

A one-region inventory looks exactly like a complete one. An AWS scan lists the account’s enabled regions first and sweeps all of them; if that one call is denied it falls back to the single region stored on the credential, silently. Scaleway is worse in the same way: discovery there is zone-scoped, the credential form has no zone field, and it defaults to a zone in Amsterdam - servers in Paris or Warsaw produce an empty inventory with no error at all.

One credential covers one scope. A Hetzner token sees a single project. An Oracle Cloud credential covers one compartment and one region. An inherited estate spread across several projects, subscriptions, or compartments needs one credential per combination, and it is easy to declare the sweep finished having scanned one corner of it.

Coverage is not uniform across providers. Several are instances-only today, including Oracle Cloud, Vultr, and Linode - a short inventory there is accurate for what Sencai currently reads, not a complete picture of the account. The per-provider table on Permissions your credentials need is the reference.

Two providers cannot be connected read-only. UpCloud’s credential is a full login and Vultr’s API keys are account-wide with no read-only scope, so “inventory only” there is a promise nothing enforces. Sencai does not inspect a credential’s scope or refuse to use it for writes either.

Adoption is the one step in this whole exercise that writes to the account. A read-only credential cannot apply Sencai’s tags, so adopting with Manage with Sencai or Read-only tracking fails at the tagging step. It fails loudly rather than silently, and scanning and viewing are unaffected - but if you promised nothing would be touched, stop at the exported unmanaged list, or use Ignore.

There is no history from before you connected. Drift detection records changes made outside Sencai to resources you have already adopted or promoted, so it starts working from the day you adopt them. It cannot reconstruct who changed what while nobody was watching.

What’s next

Section titled “What’s next”