Managing a trail

If you do not have the Yandex Cloud CLI yet, install and initialize it.

The folder used by default is the one specified when creating the CLI profile. To change the default folder, use the yc config set folder-id <folder_ID> command. You can also specify a different folder for any command using --folder-name or --folder-id.

If you access a resource by its name, the search will be limited to the default folder. If you access a resource by its ID, the search will be global, i.e., through all folders based on access permissions.

See the description of the CLI command for updating a trail:

yc audit-trails trail update --help

You can update a trail by specifying its parameters in one of these two ways:

yc audit-trails trail update \
  --name <trail_name> \
  --new-name <new_trail_name>

With Terraform, you can quickly create a cloud infrastructure in Yandex Cloud and manage it using configuration files. These files store the infrastructure description written in HashiCorp Configuration Language (HCL). If you change the configuration files, Terraform automatically detects which part of your configuration is already deployed, and what should be added or removed.

Terraform is distributed under the Business Source License. The Yandex Cloud provider for Terraform is distributed under the MPL-2.0 license.

For more information about the provider resources, see the guides on the Terraform website or its mirror.

If you do not have Terraform yet, install it and configure the Yandex Cloud provider.

To manage infrastructure using Terraform under a service account or user accounts (a Yandex account, a federated account, or a local user), authenticate using the appropriate method.

1. To update a trail created with Terraform, open the Terraform configuration file and update the trail description fragment:

   resource "yandex_audit_trails_trail" "basic_trail" {
     name        = "<trail_name>"
     folder_id   = "<folder_ID>"
     description = "<trail_description>"
     labels = {
       key = "value"
     }
     service_account_id = "<service_account_ID>"
   
     storage_destination {
       bucket_name   = "<bucket_name>"
       object_prefix = "<prefix>"
     }
   
     filtering_policy {
       management_events_filter {
         resource_scope {
           resource_id   = "<cloud_or_folder_organization_ID>"
           resource_type = "<type>"
         }
       }
   
       data_events_filter {
         service         = "<service_name>"
         included_events = ["<full_event_name>"]
   
         resource_scope {
           resource_id   = "<cloud_or_folder_organization_ID>"
           resource_type = "<type>"
         }
       }
     }
   }
   

   Where:

   • name: Name of the new trail. The naming requirements are as follows:

     • Length: between 3 and 63 characters.
     • It can only contain lowercase Latin letters, numbers, and hyphens.
     • It must start with a letter and cannot end with a hyphen.

   • folder_id: ID of the folder to create the trail in.

   • description: Trail description. This is an optional parameter.

   • labels: List of labels in key=value format. This is an optional parameter.

   • service_account_id: ID of the service account the trail uses to collect and upload audit logs.

     Based on the audit log collection scope, the service account must have the audit-trails.viewer role for the organization, cloud, or folder whose audit logs the trail will be collecting.

   Specify only one destination: storage_destination, logging_destination, or data_stream_destination.

   • logging_destination: Uploading logs to a Yandex Cloud Logging group.

     Replace the storage_destination section in the template:

     logging_destination {
       log_group_id = "<log_group_ID>"
     }
     
     • log_group_id: ID of the log group for the trail to save audit logs to.

   • storage_destination: Uploading logs to a Yandex Object Storage bucket:

     • log_group_id: Name of the bucket for the trail to save audit logs to.

     • object_prefix: Prefix that will be assigned to the objects with audit logs in the bucket. It is an optional parameter used in the full name of the audit log file.

       Note

       Use a prefix to store audit logs and third-party data in the same bucket. Do not use the same prefix for logs and other bucket objects because that may cause logs and third-party objects to overwrite each other.

   • data_stream_destination: Uploading logs to a data stream in Yandex Data Streams:

     Replace the storage_destination section in the template:

     data_stream_destination {
       database_id = "<database_ID>"
       stream_name = "<data_stream_name>"
       codec       = "RAW"
     }
     
     • stream_name: Name of the data stream for the trail to save audit logs to.
     • database_id: ID of the Yandex Managed Service for YDB database used by Data Streams.
     • codec: Event compression method when writing to Data Streams. The possible values are RAW (no compression, default), GZIP, and ZSTD. Enable compression if you expect an event flow greater than 1 MB/s.

   • filtering_policy: Settings of the filtering policy that determines which events to collect and include in the audit logs. The policy consists of filters pertaining to different levels of events. It contains the management_events_filter and data_events_filter sections.

     • management_events_filter: Management event filter.

       • resource_scope: Log collection scope. You can specify multiple resource_scope sections for scopes belonging to the same organization. For example, you can collect logs from one entire cloud and only from particular folders in another cloud. Service account permissions must allow collecting logs from the specified scopes.

         • resource_id: ID of the collection scope (organization, cloud, or folder).

         • resource_type: Scope type according to the specified ID:

           • organization-manager.organization: Organization.
           • resource-manager.cloud: Cloud.
           • resource-manager.folder: Folder.

     • data_events_filter: Data event filter. You can configure several filters of this type, one filter per service. A filter for one service has the following structure:

       • service: Name of the service in which the trail will process events. You can get it from the data event reference.

       • resource_scope: Places to collect data events from. You can configure this section the same way as the management event filter.

       • included_events: Full names of events to collect. You can replace it with excluded_events (full names of events to exclude). These parameters are mutually exclusive. If both are not set, selection is not limited to event names.

         Use the full name from the event_type field of the audit log. For example, yandex.cloud.audit.iam.CreateIamToken corresponds to the CreateIamToken event from the reference.

       • include_rule and exclude_rule: Optional rules with conditions based on field values. These apply together with event selection by names.

   For more on the properties of the yandex_audit_trails_trail resource, see this provider guide.

2. Optionally, supplement the filter with conditions based on field values for the relevant service. To do this, under filtering_policy.data_events_filter, set the include_rule and exclude_rule. Use the Yandex Cloud provider version 0.225.0 or higher. For filter configuration examples, see Creating a trail.

3. Apply the changes:

   1. In the terminal, navigate to the configuration file directory.

   2. Make sure the configuration is correct using this command:

      terraform validate
      

      If the configuration is valid, you will get this message:

      Success! The configuration is valid.
      

   3. Run this command:

      terraform plan
      

      You will see a list of resources and their properties. No changes will be made at this step. Terraform will show any errors in the configuration.

   4. Apply the configuration changes:

      terraform apply
      

   5. Type yes and press Enter to confirm the changes.

   Check the trail settings using the management console or this CLI command:

   yc audit-trails trail get <trail_name>
   

1. Get authenticated in the API and use the get REST API method or the TrailService/Get gRPC API call to get the trail settings.

2. Update the trail parameters as needed.

3. Optionally, supplement the filter with conditions based on field values for the relevant service. Do it by setting the includeRules and excludeRules rules in the filteringPolicy.dataEventsFilters list item in the REST API request. In the gRPC API, use include_rules and exclude_rules in filtering_policy.data_events_filters. For a filter configuration example, see Creating a trail.

4. Use the update REST API method for the Trail resource or the TrailService/Update gRPC API call to update the trail. Provide the trail ID, updated parameters, and update mask.

   If updating the filtering policy, enable filteringPolicy in updateMask for the REST API or filtering_policy in update_mask.paths for the gRPC API.

To delete a trail, run this command:

yc audit-trails trail delete <trail_name_or_ID>

To find out the names and IDs of available trails, use this tutorial.

To delete a trail created using Terraform:

1. Open the Terraform configuration file and delete the trail description section.

   Example of a trail description in a Terraform configuration:

   resource "yandex_audit_trails_trail" "basic_trail" {
     name        = "<trail_name>"
     folder_id   = "<folder_ID>"
     description = "<trail_description>"
     labels = {
       key = "value"
     }
     service_account_id = "<service_account_ID>"
   
     storage_destination {
       bucket_name   = "<bucket_name>"
       object_prefix = "<prefix>"
     }
   
     filtering_policy {
       management_events_filter {
         resource_scope {
           resource_id   = "<cloud_or_folder_organization_ID>"
           resource_type = "<type>"
         }
       }
   
       data_events_filter {
         service         = "<service_name>"
         included_events = ["<full_event_name>"]
   
         resource_scope {
           resource_id   = "<cloud_or_folder_organization_ID>"
           resource_type = "<type>"
         }
       }
     }
   }
   

2. In the command line, navigate to the directory with the Terraform configuration file.

3. Check the configuration using this command:

   terraform validate
   

   If the configuration is valid, you will get this message:

   Success! The configuration is valid.
   

4. Run this command:

   terraform plan
   

   You will see a list of resources and their properties. No changes will be made at this step. Terraform will show any errors detected in the configuration.

5. Apply the configuration changes:

   terraform apply
   

6. Type yes and press Enter to confirm the changes.

7. To make sure the trail has been deleted, use this tutorial.

To delete a trail, use the delete REST API method for the Trail resource or the TrailService/Delete gRPC API call.