How a Google Cloud Administrator can enforce security with Organization Hierarchy, Organizational Policies, and IAM Policies
The topic of Organizational Hierarchy, Organizational Policies, and IAM Policies is simple but because it’s simple, users often dismiss it to focus on the sexier security stuff.
Organizational Hierarchy, Organizational Policies, and IAM Policies are fundamental security building blocks in Google Cloud. The start of every Google Cloud journey begins with setting up your organization properly. As an administrator, you can centralize control of all your organization’s cloud resources through these policies.
These building blocks provide a solid secure foundation on which to layer on more advanced security services.
Organization Hierarchy
The Organization Hierarchy consists of 3 things:
- Organization
- Folders
- Projects
The way I think about the organization hierarchy is to think about it like a file system. With a file system, you have a root folder. Within the root folder, you have sub-folders. Within each sub-folder you have your files. In Google Cloud, the root folder is the Organization (ie. your-company.com). Under the Organization are multiple folders to organize similar items. Within each folder are Projects, which contain different Google Cloud resources such as VMs.
The Resource Manager is the interface in Google Cloud that manages the folders and projects and you can think of the resource manager as the equivalent to the Windows File Manager that manages the file system.
From a security perspective, the organization structure enforces the principle of least privilege.
The child nodes will inherit the security policies of their parent node. For example, in the diagram above, Team A and Team B will inherit the security policies of the folder Department Y. The best practice is to restrict permissions as much as possible at the higher layers to maintain the principle of least privilege.
You might be wondering, if a good hierarchy is good security, what makes a good hierarchy?
Finding the optimal hierarchy is more of an art than a science. From my experience, most users build their hierarchy to match their business units and then separate their business units into different environments such as Development, Test, and Production. If you follow the Google Cloud setup checklist, it recommends 4 different types of structures:
- Simple Environment — ie. Non-production and Production
- Simple Team-Oriented — ie. Development and QA
- Environment Oriented — ie. environment + business unit
- Business Unit Oriented — ie. HR and Engineering
As long you have a easy way to enforce the principle of least privilege through inheritance, then I’d say you have a good organization hierarchy.
Organizational Policies
After you create the organization hierarchy, the next step is to configure organization policies.
Organization Policies are constraints that restrict how resources are used. They are great for setting guardrails to help teams stay within compliance boundaries. Organizational Policies are inherited so an administrator can configure restrictions across the the organization by configuring the policy at the organization root.
If you need to override a restrictive policy, the best practice is to override the policy at the project level so the security of other projects is not affected.
Some Recommended Organization Policies
- Limit the usage of IAM service accounts. constraints/iam.disableServiceAccountCreation
- Restrict the physical location of newly created resources. constraints/gcp.resourceLocations
- Disable external IPs on VMs. constraints/compute.vmExternalIpAccess
- Disable VM serial port access. constraints/compute.disableGlobalSerialPortAccess
- Skip default VPC network creation. constraints/compute.skipDefaultNetworkCreation
- Define trusted image projects. constraints/compute.trustedImageProjects
IAM Policies
The final step is to configure IAM Policies, which defines who is allowed to do what on which resource.
When I first started learning about IAM policies, I found them confusing because IAM is more than just permissions. A policy consists of 2 parts:
- Permissions
- Roles
What I found confusing is that we do not assign permissions directly to users. We group a bunch of permissions into a role and then assign a role to user. To makes things even more confusing, there are 3 types of roles in Google Cloud:
- Basic Roles
- Custom Roles
- Pre-defined Roles
Basic Roles
Basic Roles are the OG roles. There are 3 versions:
- Viewer: read-only permissions
- Editor: read/write permissions
- Owner: admin level permissions
These basic roles still exist in Google Cloud but are no longer recommended.
Custom Roles
A custom role allows you to select the exact permissions you want in your role.
This sounds like the most secure option because these roles are user defined and you have granular control. However, custom roles are not recommended because they are not maintained by Google. When Google Cloud adds new permissions, features, or services, your custom roles are not automatically updated which could lead to a management nightmare if you have to manually update many custom roles.
Even though custom roles are not recommended, there are scenarios where you might want to use custom roles to fine tune your security.
Pre-defined Roles
Pre-defined roles are recommended by Google Cloud.
Pre-defined roles are created and maintained by Google meaning that Google will automatically update the permissions within these roles. To select a role with the least number of permissions, review the documentation. Reviewing the documentation also ensures that users don’t get a black box role of permissions.
With IAM roles, the key takeaway is to use predefined roles wherever possible and use custom roles where necessary.
Summary
- The organization hierarchy enforces the principle of least privilege since child nodes inherit the security policies of their parent nodes.
- Organization constraints restrict how resources are used and are inherited from the parent node.
- IAM policies control who can do what on which resource and pre-defined roles are recommended by Google Cloud.
Resources
- https://cloud.google.com/resource-manager/docs/cloud-platform-resource-hierarchy
- https://cloud.google.com/iam/docs/resource-hierarchy-access-control
- https://cloud.google.com/docs/enterprise/setup-checklist
- https://cloud.google.com/resource-manager/docs/organization-policy/overview
- https://cloud.google.com/resource-manager/docs/organization-restrictions/overview
- https://cloud.google.com/resource-manager/docs/organization-policy/org-policy-constraints
- https://cloud.google.com/blog/topics/developers-practitioners/cloud-iam-google-cloud
- https://cloud.google.com/iam/docs/understanding-roles
- https://cloud.google.com/iam/docs/roles-overview#custom
- https://cloud.google.com/iam/docs/roles-overview#custom-role-use-cases
- https://www.googlecloudcommunity.com/gc/Architecture-Framework-Guidance/System-Design-Resource-Management-Best-Practices/ta-p/178060
- https://cloud.google.com/architecture/framework/system-design/resource-management
- https://medium.com/google-cloud/organization-policies-that-needs-to-be-enforced-to-tighten-your-gcp-security-f3bfb724e9dd
