Cloud Storage buckets with no bucket retention policy
What does ZopNight detect here?
Cloud Storage buckets are flagged when no bucket retention policy is configured. A retention policy, set with `gcloud storage buckets update --retention-period`, makes every object undeletable and unreplaceable until it reaches a minimum age, which is what regulated records need and what stops a bad sync job or stolen credential from wiping the bucket.
Signal and threshold
| Field | Value |
|---|---|
| Rule IDs | RC-1231 |
| Category | compliance |
| Severity | medium |
| Metric | none — pure configuration read |
| Threshold | no retention policy on the bucket |
| Source | ZopNight |
| Permissions used | storage.buckets.list · storage.buckets.get |
Where it applies
What a retention policy guarantees
Bucket Lock lets you set a retention period
on a bucket. Once set, objects can only be deleted or replaced after their age exceeds that
period, and attempts to do it sooner fail with 403 retentionPolicyNotMet. The policy applies
retroactively to objects already in the bucket, not only to new uploads. Periods go up to
3,155,760,000 seconds, which is 100 years.
A policy can also be locked. A locked policy can never be removed or shortened, only extended, and the bucket cannot be deleted until every object has met the period. Google positions this together with detailed audit logging for rules such as those from FINRA, SEC and CFTC.
Checking a bucket’s current policy
gcloud storage buckets describe gs://BUCKET_NAME \ --format="default(retention_policy)"No retention_policy block in the output means the bucket has none. Across a project, run the
same describe in a loop over gcloud storage buckets list --format="value(name)".
The test ZopNight applies
For each bucket it has fully inventoried, ZopNight records whether a retention policy is set, and the rule fires when none is. There is no minimum period it expects: any configured policy, however short, clears the finding.
Buckets it does not report
Buckets missing their basic inventory details are skipped so an incomplete scan cannot flag them. The rule does not look at per-object retention settings or object holds, only the bucket-level policy, and it does not say whether a policy should be locked.
The cost side of retention
There is no saving here, and adding a policy can raise spend: objects cannot be cleaned up early, and Object Lifecycle Management deletions wait until each object has met the period. That is why the retention period should come from a real requirement, not a guess.
Setting a retention period
- Agree the period with whoever owns the compliance requirement or recovery objective.
- Apply it, for example 30 days:
gcloud storage buckets update gs://BUCKET_NAME --retention-period=P30D. - Check lifecycle rules still make sense now that deletes wait for the period.
- Lock the policy only when the period is final:
gcloud storage buckets update gs://BUCKET_NAME --lock-retention-period.