Update TrendAI Cloud One File Storage Security to TrendAI Vision One File Security Storage for Google Cloud Platform

Choose an update path

• Zero downtime: Choose this path if scanning must not be interrupted. Be aware that during the interval before C1FSS scanning stops, every new object is scanned by both C1FSS and V1FSS. If the promote-or-quarantine plugin is in use and you carry its settings over to V1FSS, both products also move the same objects, which can cause race conditions. These lead to inconsistent object metadata, an inconsistent file state (one product moves an object while the other is still reading it), or duplicate processing (both products attempt the same move, and whichever one wins deletes the source while the other logs a failure).
• Brief downtime: Choose this path if you can tolerate a short interruption of scanning. Scanning pauses only between removing the C1FSS bucket notification and turning on scanning in the TrendAI Vision One console, which is typically a few minutes. This path has the least chance of problems during the update, and is the better choice if you use the promote-or-quarantine plugin.

Before you begin

1. Confirm that V1FSS can replace your C1FSS layout.
   Two C1FSS layouts have no V1FSS equivalent. Check both before you plan anything else.

   Supported C1FSS layouts

   C1FSS layout	Update supported?
   All-in-One (scanner stack and storage stack together)	Yes
   Scanner stack only, or storage stack only, in the same project	Yes
   Several storage stacks in one project	Yes. They collapse into one V1FSS stack.
   Cross-project, with buckets in one project and the scanner in another	No
   Multi-region or dual-region buckets	No. V1FSS for GCP protects single-region buckets only.

   Important A cross-project layout changes your whole plan. Every V1FSS resource is scoped to a single project, and a bucket can only be served by a scanner in its own project. If C1FSS runs hub-and-spoke, you need one V1FSS deployment for each project that holds buckets, and the hub scanner project goes away. Check the Cloud One console to confirm whether your current setup is cross-project, and if it is, plan the per-project split before you change anything.

2. Check whether you use the promote-or-quarantine plugin.
   C1FSS can move clean or malicious objects to other buckets, but only through a separate plugin deployed once per scanning bucket. V1FSS has this capability built in, but the settings do not carry across automatically, and one default differs in a way that changes where your files land. The plugin is also not part of any C1FSS stack, so nothing else in this update finds or removes it.
   Run the following in Cloud Shell.

   gcloud functions list --filter="name~promote-and-quarantine" --format="value(name,region)"

   If the command returns anything, read Update promote and quarantine settings before you start, and record the plugin settings now. You need them before you install V1FSS, not after.
3. Record what C1FSS protects, and how. Do this first, before you make any changes.
   The C1FSS Bucket Listener is a Cloud Functions (1st gen) function with a google.storage.object.finalize trigger. Cloud Functions creates a notification configuration on your bucket to deliver those events, and that notification configuration is what you remove at cutover. Record its details now: they are your baseline for confirming that C1FSS has stopped scanning, and for confirming that it comes back correctly if you roll back. Some of this information becomes unreadable once the C1FSS stacks are gone.
   1. In the Cloud One console, go to File Storage Security → Stacks and note each stack's name, type (scanner, storage, or All-in-One), and region.
   2. In Cloud Shell, run the following to find the bucket that each Bucket Listener protects, along with everything else you need for cutover.

      OUTFILE="c1fss-inventory-$(date +%Y%m%d).csv"
      echo "function,region,bucket,c1_notification_id,c1_notification_topic,object_finalize_count" > "$OUTFILE"
      
      gcloud functions list --filter="name~bucket-listener" --format=json </dev/null \
      | jq -r '.[] | (.name | split("/")) | "\(.[5]),\(.[3])"' \
      | while IFS=, read -r fn region; do
          bucket=$(gcloud functions describe "$fn" --region="$region" \
            --format="value(eventTrigger.resource)" </dev/null | sed 's#.*/buckets/##')
      
          if [ -z "$bucket" ]; then
            echo "$fn,$region,,MISSING,MISSING,0" >> "$OUTFILE"
            continue
          fi
      
          notifs=$(gcloud storage buckets notifications list "gs://$bucket" --format=json </dev/null 2>/dev/null)
          id=$(echo "$notifs" | jq -r '[.[]."Notification Configuration" | select(.topic | test("cloud-functions-"))][0].id // "MISSING"')
          topic=$(echo "$notifs" | jq -r '[.[]."Notification Configuration" | select(.topic | test("cloud-functions-"))][0].topic // "MISSING"')
          count=$(echo "$notifs" | jq '[.[]."Notification Configuration" | select(.event_types == null or any(.event_types[]; . == "OBJECT_FINALIZE"))] | length')
          echo "$fn,$region,$bucket,$id,$topic,$count" >> "$OUTFILE"
        done
      
      column -s, -t "$OUTFILE"
      echo "Saved to: $(pwd)/$OUTFILE"

   3. Download the CSV file from Cloud Shell and save it somewhere accessible, alongside the Cloud One stack names and regions from the first step. A text file or a ticket comment is enough.
   Between the CSV file and the stack list you have everything the update needs: which function protects which bucket, the region to select when you generate the deployment package, the C1FSS notification id and topic to delete at cutover and confirm on rollback, the function name to redeploy for rollback and delete at teardown, and the OBJECT_FINALIZE count that is your baseline for the sixth check below.

   Note If a bucket has no notification configuration pointing at a Cloud Functions topic, C1FSS is not scanning it. Leave that bucket out of the update.

4. Identify which C1FSS generation you have.
   C1FSS shipped two GCP deployment mechanisms, and teardown differs between them. Run the following in Cloud Shell.

   gcloud deployment-manager deployments list

   C1FSS deployment generations

   Result	Generation	Teardown command
   Deployments named <prefix>-scanner or <prefix>-storage	Deployment Manager	gcloud deployment-manager deployments delete
   No deployments listed	Terraform	terraform destroy, run in the directory you were told to keep

5. Confirm that you have the required permissions and tools.
   • Permissions on the Google Cloud project: For the full list, see Google Cloud required permissions.
   • Terraform in Cloud Shell: Cloud Shell provides gcloud, gsutil, and jq, but it no longer preinstalls Terraform. Install Terraform yourself, because deploy.sh does not run without it.

   Note Step 1 of either update path runs ./deploy.sh precheck. That command is a Terraform plan, which shows you what would be created. It is not a permissions check, so confirm your permissions separately.

6. Check the notification slots on each bucket. This check applies to GCP only.
   A bucket can hold at most 10 notification configurations for a single event type. C1FSS uses one, and V1FSS needs one more. If a bucket already has 9 or more OBJECT_FINALIZE configurations, turning it on in V1FSS fails silently: TrendAI Vision One logs the failure internally and continues, and the bucket stays unprotected with no error in the console.

   for b in <bucket-1> <bucket-2>; do
     n=$(gcloud storage buckets notifications list "gs://$b" 2>/dev/null | grep -c 'OBJECT_FINALIZE' || true)
     echo "$b: $n OBJECT_FINALIZE notification(s)"
   done

   Any bucket at 9 or above needs a slot freed before you turn it on.

Update promote and quarantine settings

gcloud functions list --filter="name~promote-and-quarantine" --format=json </dev/null \
| jq -r '.[] | (.name | split("/")) | "\(.[5])\t\(.[3])"' | column -t

gcloud functions describe <plugin-function-name> --format="value(environmentVariables)"

1. Where objects go. Each destination is a JSON string, resolved in the order custom, then regional, then global.

   # If every protected bucket used the same destination:
   clean_bucket      = jsonencode({ global = "my-clean-bucket" })
   quarantine_bucket = jsonencode({ global = "my-quarantine-bucket" })
   
   # If destinations differed per source bucket:
   quarantine_bucket = jsonencode({
     custom = {
       "source-bucket-1" = { destBucket = "quarantine-bucket-1", destRegion = "us-east1" }
       "source-bucket-2" = { destBucket = "quarantine-bucket-2", destRegion = "us-west1" }
     }
   })
   
   # Or per region, keyed by region name, with an optional global fallback:
   quarantine_bucket = jsonencode({ "us-east1" = "quarantine-use1", global = "quarantine-fallback" })

   Leave a variable as jsonencode({}) if that action was turned off. Those objects are tagged in place, exactly as before.

   Important Use global only if every bucket you are protecting had a plugin for that action. A global value applies to all of them, including buckets that never had a plugin, and those buckets were only tagged under C1FSS. If you give them a destination, V1FSS starts moving their objects. If only some buckets had a plugin, use the custom form, which affects only the source buckets you list.

2. Where objects land inside the destination. You must change this value.

   use_source_bucket_as_folder = false

   The package ships with true, which is the correct default for a new deployment but not for an update.

   Destination paths

   Configuration	Path your objects land at
   C1FSS plugin	<destination>/<object>
   V1FSS with false	<destination>/<object>, the same as C1FSS
   V1FSS with true	<destination>/<source-bucket>/<object>, which is different

   If anything reads your quarantined or promoted objects by path, true breaks it at cutover. Note the trade-off that the setting exists for: with false, two source buckets that hold an object of the same name overwrite each other in the destination. C1FSS behaved the same way, so false matches your current behavior. If that was only safe because each plugin instance had its own destination bucket, keep that arrangement with the custom form rather than collapsing to one global destination.
3. Leave the failure destination empty, to match C1FSS.

   failure_bucket = jsonencode({})

   The C1FSS plugin had no failure destination, so objects whose scan failed stayed where they were. V1FSS can move them somewhere instead, which is a new capability but not your current behavior.

• Copy mode. If PROMOTE_MODE or QUARANTINE_MODE was copy, the plugin left the original object in place. V1FSS always moves the object: it copies the object to the destination and then deletes the original. Make sure nothing depends on the original staying in the source bucket.
• Destinations in another project. V1FSS grants its post-scan action service account roles/storage.objectAdmin on each destination bucket as part of the Terraform apply, so the identity you run deploy.sh with needs permission to set IAM on that bucket. If a destination is in another project and you cannot grant that permission, the apply fails on the binding. Move the bucket into this project, or ask the other project's administrator to grant the …-action-tag service account access after you deploy.

Important The plugin replaces an object's metadata in full, not only the fss- keys, immediately before it copies the object to the destination. For objects the plugin acts on, both the V1FSS keys and any custom metadata of your own are absent from the destination copy. This is existing C1FSS behavior and the update does not change it.

What changes after the update

• Bucket selection is a console setting, not a deployment parameter. C1FSS fixed the scanning bucket when you deployed the stack, one stack per bucket. V1FSS deploys once for each project, and you turn buckets on and off in the TrendAI Vision One console.
• Only one V1FSS stack is supported for each project. V1FSS records its deployment metadata in a secret with a fixed name, so a second stack in the same project fails to apply. Several C1FSS storage stacks collapse into one V1FSS stack, which is usually what you want, but it is not optional.
• V1FSS grants itself project-wide access to Cloud Storage. Instead of per-bucket IAM bindings, it creates two project-level custom roles that cover every bucket in the project. There is no option to scope access to individual buckets. If the per-bucket model in C1FSS was a control you relied on, review this before you update.
• V1FSS uses Cloud Run v2 instead of Cloud Functions (1st gen), so it does not depend on the Cloud Build, Cloud Functions, or Deployment Manager APIs.
• Promote and quarantine always move objects, never copy them, and they are configured once in the deployment package rather than once for each bucket in a separate plugin.
• The scan-result Pub/Sub topic changed, along with the shape of its messages. If you had your own subscriber on the C1FSS …-scan-result-topic topic, subscribe it to the V1FSS topic and update your parser.
• Scan history stays in Cloud One. TrendAI Vision One starts fresh at cutover. Export anything you need to keep before your Cloud One tenant is removed.

• A cross-project scanner: A V1FSS deployment is confined to one project. A hub-and-spoke C1FSS layout becomes one V1FSS deployment for each project that holds buckets.
• Object prefix filtering (objectFilterPrefix): The V1FSS Terraform supports it, but the path that a TrendAI Vision One managed deployment uses cannot set it. If C1FSS scanned only a prefix of a bucket, V1FSS scans the whole bucket. Check your object volumes first, because for a prefix that covered a small part of a large bucket, this is a significant change in how much is scanned.
• Per-bucket IAM scoping (disableScanningBucketIAMBinding): No equivalent in V1FSS.
• Reporting object keys to the backend (reportObjectKey): No equivalent in V1FSS. Object keys are always hashed in telemetry.
• Multi-region and dual-region buckets: Not protected by either product's V1FSS path. They always report as not deployed.

• Detections in TrendAI Vision One XDR and Workbench visibility, alongside the rest of your security data.
• Object moving without a separate plugin, built into V1FSS and configured once instead of once for each bucket, with no extra service account or custom roles of its own to manage.
• A destination for failed scans (failure_bucket). The C1FSS plugin left those objects in place.
• Better failure handling, with three dead-letter queues and exponential backoff instead of one queue, and daily automatic credential rotation.
• A configurable metadata format: separated keys, which is the default and matches C1FSS, a single merged key, or no metadata at all.

Common questions