API Accounting Config

API Accounting Configs represent cloud API audit trail configurations. An example of such a service would be AWS CloudTrail. This class inherits from TopLevelResource and has direct access to the resource’s database object. The following attributes are directly accessible:

attr resource_id:
 The primary resource identifier that takes the form of a prefix followed by numbers and letters
attr accounting_config_id:
 The provider ID of the accounting configuration
attr organization_service_id:
 The ID of the parent organization service (cloud)
attr region_name:
 The region where the API configuration resides
attr name:The name of the config
attr multi_region:
 Denotes whether or not the configuration spans all regions
attr parent_resource_id:
 The resource ID of the parent that this trail is associated with
attr config:JSON output of configurations (If logging enabled, log file validation enabled, S3 bucket name)
class DivvyResource.Resources.apiaccountingconfig.ApiAccountingConfig(resource_id)

Bases: DivvyResource.Resources.resource.Resource

ApiAccountingConfig operations

accounting_config_id
api_accounting_config
delete(user_resource_id=None)

Delete this resource. If wrapped in a with JobQueue() block, this will queue the deletion job to the wrapped queue, otherwise it calls immediately.

get_arn()
static get_db_class()
static get_provider_id_field()
static get_resource_type()
get_supported_actions()

Retrieve all the actions which are supported by this resource.

handle_resource_created(user_resource_id=None, project_resource_id=None)

This should be called when a resource is created/discovered after the basic data is added to the database. This gives an opportunity for post-addition hooks (assignment to projects/groups, alerts, etc)

handle_resource_destroyed(user_resource_id=None, project_resource_id=None)

This should be called when a resource is destroyed before the basic data is removed from the database. This gives an opportunity for pre-destruction hooks (removal from projects/groups, alerts, etc)

handle_resource_modified(resource, *args, **kwargs)

This should be called when a resource is modified after the new data has been updated in the DB session This gives an opportunity for post-modification hooks