The case
Who deleted the invoices folder? The log only showed a service account.
On a Monday morning, Isaac's store found out that invoice files were missing from storage. The team needed to know who had done it, and from where. Without a record of the actions, the answer was a guess.
This post builds on Security and Shared Responsibility in the Cloud, which explains who answers for what and the concepts of identity and role. It also depends on the resource hierarchy, because permissions follow the tree of folders and projects.
The problem
Too much permission and too little record
When everyone has administrator access to the project, any mistake can delete everything, and nobody knows who did what. The problem is not only excessive permission: it is also not having a reliable record of the actions.
IAM policies
Who can do what, and where
On Google Cloud, IAM works with a policy (IAM policy) attached to a resource. The policy is a list of bindings: a member (a user, a group or a service account) gets a role on that resource.
Policies are inherited from top to bottom. A role granted on a folder applies to all projects inside it, and a role granted on a project applies to all of its resources. That is why granting access at the highest level can open more than you intended.
Roles
Three types of role
Basic (basic roles)
Owner, Editor and Viewer. They are too broad for production: an Editor can change almost everything in the project.
Predefined (predefined roles)
Created for each service, with the permissions for one task. For example, a role that only reads Cloud Storage objects.
Custom (custom roles)
You build the role with the exact permissions. It gives more control, but needs maintenance when the service changes.
At the store, the support team gets a predefined role that reads the invoice bucket, and nothing else.
Service accounts
Identity for applications
An application is not a person, so it does not use a user login. On Google Cloud, it gets a service account (service account), its own identity that receives roles like any other member.
The most common mistake is downloading a service account key and putting it in the code. The key can leak, and it does not expire on its own. The recommended path is to attach the service account to the resource that runs the application, with no key in the code.
Encryption and keys
Data already comes encrypted
Google Cloud encrypts data at rest by default, with no configuration from you. Whoever needs to control the keys can use Cloud KMS to create and rotate their own keys (CMEK, customer-managed encryption keys), and define who can use them.
Audit logs
Who did what, and when
Cloud Audit Logs record actions on resources. Admin activity logs (who created, changed or deleted something) are already on and have no extra cost. Data access logs are optional for most services (BigQuery is the exception), may generate costs and must be turned on on purpose.
The store already had data access logs turned on for the invoice bucket. That is why the team could see that the deletion came from the billing system's service account, in the early hours, and fixed that account's permission.
Key terms
Five terms to remember
Tap a card to see the definition.
Quick test
Three questions, exam style
01
An order system only needs to read invoices from a bucket. What is the most appropriate way to grant access?
02
The team needs to know which account deleted a file from a bucket last week. Which resource answers that?
03
The store wants to control the keys that encrypt its data, and not only use the default encryption. Which resource should it use?
In any cloud exam, the security question is usually the same: who has access, with which role, at which level, and how you know what was done. On Google Cloud, the answer goes through the IAM policy, the service account and the audit logs.