0

We have a storage bucket which has sensitive data stored in it, in the form of JSON files. For a PCI compliance, we have to make these files read only.
Versioning will be enabled on the bucket so Retention policy can not be used.
I tried keeping only one account in the bucket permissions with Read Only access, that (not really) partially serves the purpose. But any user with Editor or Owner role can edit the file permissions and change it back to Editable and modify the file.
How to restrict anyone and everyone to not be able to edit or modify the file GCP?

Is this technically possible with Google Cloud Platform?
If not, how to reduce access to a file as minimum as possible?

EDIT
I am not sure if we would compulsorily enable versioning, I will discuss this with the team (once they are available) and mention the same in the question.
So answers which consider "versioning will not be enabled" or ignore versioning completely, are also welcomed.

Amit Yadav
  • 4,422
  • 5
  • 34
  • 79

2 Answers2

2

Google IAM permissions are additive and not subtractive. This means that anyone with the Owner role has the required permissions to read/write/modify/delete. You cannot restrict permissions once granted.

Since you have mention PCI DSS compliance I recommend creating a new project. In this project assign the project owner. Then create a group and add everyone else to this group. Grant the group storage read permission only. Create a new bucket in this project and store the objects that you want to protect there. Since there is only one (or several) well defined owners, read only permissions can be enforced for everyone else.

I do not know of a way to protect an exising bucket with IAM members with roles that have write permissions without using retention policies. Versioning protects object data from being destroyed with the issue of requiring versions to access the data.

Note: You cannot edit or modify objects in Google Cloud Storage. Any changes require creating a new object.

John Hanley
  • 74,467
  • 6
  • 95
  • 159
  • But the owner would still have a write access right? How can we restrain even the owner to modify (by modify I mean delete and create a new one) the object? Is this even possible? – Amit Yadav Apr 15 '19 at 03:35
  • You have a chicken and egg situation. You need an Owner to create the bucket. If you then remove the Owner, you will never again be able to manage the bucket. The owner should be a trusted authority (person). – John Hanley Apr 15 '19 at 03:38
  • I understand that. So we'll be using the default service account `cloud-logs@system.gserviceaccount.com` for exporting a few logs into the bucket. Only this service account has the write access is what we are looking for. Also, is it possible to change read/write access on Object basis, rather than bucket basis? – Amit Yadav Apr 15 '19 at 04:17
  • First Q: You can use a service account. If you accidentally delete that service account you are in trouble. Normally you do not want to give the service account for log file uploads delete ability, just create and write. So you are back to the chicken and egg situation. Next Q: You can use IAM permissions (roles) or you can use Bucket / Object ACLs or both. However, remember that permissions are additive and not subtractive. If someone has delete or overwrite permission you cannot take it away. – John Hanley Apr 15 '19 at 04:29
  • For PCI Compliance I would drop Versioning and use Bucket Lock. This is the only way that I can think of for compliance. Set the time to something like 7 years. – John Hanley Apr 15 '19 at 04:31
2

The following answer assumes that you will choose to disable versioning, as it is not compatible with retention policies.

You may want GCS's Bucket Lock feature. Placing a retention policy on a bucket ensures that all current and future objects in the bucket cannot be deleted or overwritten until they reach the age you define in the retention policy, which sounds like what you want. Once you have enabled it and verified that it works correctly with your workflow, you can lock the policy in place to irrevocably revoke your ability to remove objects before the specified retention date.

This is a serious decision for an existing bucket, so I'd read up on it before turning it on: https://cloud.google.com/storage/docs/bucket-lock

Once you've decided to enable it, you can do so from the console or by using gsutil:

gsutil retention set 1y gs://my-bucket-name  # 1y = 1 year

Once you're happy and want to make it permanent:

gsutil retention lock gs://my-bucket-name

As mentioned at the top, this feature is incompatible with another object preservation option: versioning. However, this is usually not a problem, as the most common use case of versioning is to prevent accidental deletion, and if your goal is to prevent any possibility of deletion, versioning is unnecessary.

Brandon Yarbrough
  • 37,021
  • 23
  • 116
  • 145