Managing CloudAccounts

Or: What are the ways a user can create, update, and delete CloudAccounts?

In the context of cloudigrade, a CloudAccount is the parent object that relates to a user's account a public cloud (such as AWS). The CloudAccount has Instances, InstanceEvents, and other relevant data coming from the user's public cloud account.

A user can have many CloudAccount objects if they have many separate accounts in the various public clouds, but there can exist at most only one CloudAccount object for one public cloud account. One user cannot have multiple CloudAccounts for one actual public cloud account, and multiple user cannot have their own CloudAccounts for a "shared" public cloud account. In the case of multiple users sharing a public cloud account, only the first user with verified access to the public cloud account may have its CloudAccount.

CRUD for CloudAccounts

There are two mechanisms for creating and manging CloudAccounts within cloudigrade: the synchronous HTTP API and the asynchronous Kafka message topics that receive messages from sources-api.

HTTP API

The public HTTP API does not support creating, updating, or deleting cloud accounts. You can only read accounts from the public HTTP API. As described in detail with examples in REST API Example Usage, a user can get their accounts with access automatically scoped to objects belonging to the authenticated user:

• HTTP GET /api/v2/accounts/ gets a list of all CloudAccounts
• HTTP GET /api/v2/accounts/{id}/ gets the CloudAccount with id {id}

Internal HTTP APIs exist to create, update, or delete cloud accounts, but they are wholly unsupported and intended only for local development use.

• HTTP POST /internal/api/cloudigrade/v1/accounts/ creates and returns a new CloudAccount
• HTTP PATCH /internal/api/cloudigrade/v1/accounts/{id}/ updates the CloudAccount with id {id}
• HTTP PUT /internal/api/cloudigrade/v1/accounts/{id}/ replaces the CloudAccount with id {id}
• HTTP DELETE /internal/api/cloudigrade/v1/accounts/{id}/ deletes the CloudAccount with id {id}

Creating a CloudAccount via the internal HTTP API synchronously communicates with the relevant public cloud to verify access and with sources-api to update its Application availability status. Both of those calls must succeed for CloudAccount creation to complete, and cloudigrade will abort creation and respond with an appropriate error if either one fails.

Sources

See Sources Integration

CloudAccount.is_enabled

All CloudAccounts have an is_enabled state that can be read (but not set) by the HTTP API. Because all verification steps must complete successfully upon creation of a CloudAccount, all new CloudAccounts are created with is_enabled as true.

When a CloudAccount is not enabled, cloudigrade stops processing new data from the user's public cloud account. Historic data is not deleted, but any instances that were running at the time the CloudAccount was disabled are also immediately updated to act as though those instances were stopped. This prevents cloudigrade from erroneously tracking usage during the time when the CloudAccount is not enabled.

When a CloudAccount is reenabled after having been disabled, it performs a comprehensive describe of the user's public cloud account so that it can resume tracking its data.

Authentication.update from sources-api

If cloudigrade receives an Authentication.update message but cannot verify the new authentication with the user's public cloud account, cloudigrade saves the new authentication but sets is_enabled to false and notifies sources-api to update the Application status to "unavailable".

If cloudigrade receives an Authentication.update message for a disabled CloudAccount and succeeds verifying the new authentication with the user's public cloud account, cloudigrade enables the CloudAccount and notifies sources-api to update the Application status to "available".

If cloudigrade receives an Authentication.update message for a CloudAccount we do not currently manage, and succeeds verifying that we are meant to manage it, it'll create a new CloudAccount, and notify sources it is available.

Periodic Permissions Checking

Once a CloudAccount is enabled, cloudigrade starts a periodic task to run once every day to verify that the CloudAccount's authentication into its user's public cloud is still valid. If this task ever fails to verify access, the CloudAccount is disabled and notifies sources-api to update the Application status to "unavailable". When the CloudAccount is disabled, the periodic task is destroyed and will not run again until the CloudAccount is enabled.