A service account is a special kind of account used by an application or a virtual machine (VM) instance, not a person. Applications use service accounts to make authorized API calls.
For instance, maybe you have an application running in a virtual machine that needs to store data in Google Cloud Storage, but you don’t want to let just anyone on the Internet have access to that data, only that virtual machine.
So, you’d create a service account to authenticate your VM to cloud storage. Service accounts are named with an email address.
But instead of passwords, they use cryptographic keys to access resources. This way the service account is the identity of the service, and the service account’s permissions control which resources the service can access.
A service account is identified by its email address, which is unique to the account.
Differences between a service account and a user account
- Service accounts do not have passwords, and cannot log in via browsers or cookies.
- Service accounts are associated with private/public RSA key-pairs that are used for authentication to Google.
- Cloud IAM permissions can be granted to allow other users (or other service accounts) to impersonate a service account.
- Service accounts are not members of your G Suite domain, unlike user accounts. For example, if you share assets with all members in your G Suite domain, they will not be shared with service accounts. Similarly, any assets created by a service account cannot be owned or managed by G Suite admins.
Cloud Identity & Access Management lets you grant granular access to specific Google Cloud resources and helps prevent access to other resources. Cloud IAM lets you adopt the security principle of least privilege, where you grant only necessary permissions to access specific resources.
Primitive Roles are broad and impact all resources in the project. They are roles which existed prior to existence of Cloud IAM.
These roles are concentric, owner includes the permissions of editor and editor includes the permission of viewer.
- Viewer – Permissions for read-only actions that do not affect state, such as viewing (but not modifying) existing resources or data.
- Editor – All viewer permissions, plus permissions for actions that modify state, such as changing existing resources.
- Owner – All editor permissions, plus Manage roles and permissions for a project and all resources within the project. Set up billing for a project.
4. Billing Administrator Role
someone to be able to control the billing for a project without the right to change the resources in the project.
In addition to the primitive roles, Cloud IAM provides additional predefined roles that give granular access to specific Google Cloud Platform resources and prevent unwanted access to other resources.
There is a long list of these roles listed here.
Custom roles can only be used at the project or organization levels. They can’t be used at the folder level.
To create a custom role, a caller must possess iam.roles.create permission. By default, the owner of a project or an organization has this permission and can create and manage custom roles.
Users who are not owners, including organization admins, must be assigned either the Organization Role Administrator role, or the IAM Role Administrator role.
Organization policies are needed to enforce what resources are available in a Google Cloud trust boundary (folder, project, or other organizational level).
Cloud Identity and Access Management (IAM) enables you to manage access control by defining who (identity) has what access (role) to which resource.
Top to bottom : Resources inherit the policies of their parent resource.
Google Cloud Platform Policies are set at the highest level, like the organisation node are cascaded down to the project.
Inheritance is transitive, all the resources in a project inherit the policy.
However policies implemented at a higher level in this hierarchy can’t affect the access that’s granted exceptionally at a lower level.
Policy A – Enforced at the Organisation Level – Users can view cloud storage buckets.
Policy B – Enabled at the Project Level – User can modify cloud storage buckets.
Since Project Level Policy B is granting a more generous access at a lower level, it shall take effect and override Policy A.
An IAM policy has the following :
- “who” part,
- a “can do what” part, and
- an “on which resource” part.
The “who” part of an IAM policy can be defined either by a
a. Google account
b. Google group
c. Service account
d. G Suite
e. Cloud Identity domain.
Can Do What – Role
The “can do what” part is defined by an IAM role which is a collection of permissions.
To do any meaningful operations, you need more than one permission.For example, to manage instances in a project, you need to create, delete, start, stop, and change an instance.
So the permissions are grouped together into a role that makes them easier to manage.
There are three kinds of roles in Cloud IAM:
- Primitive roles: Roles historically available in the Google Cloud Console. These roles are Owner, Editor, and Viewer. Avoid using these roles if possible, because they include a wide range of permissions across all Google Cloud services.
- Predefined roles: Roles that give finer-grained access control than the primitive roles. For example, the predefined role Pub/Sub Publisher (
roles/pubsub.publisher) provides access to only publish messages to a Pub/Sub topic.
- Custom roles: Roles that you create to tailor permissions to the needs of your organization when predefined roles don’t meet your needs.
Reference : Concepts Related to Access Management
Projects, Folders, Organisation Node are the binding blocks of the Google Cloud Hierarchy.
Policies are inherited downwards in the hierarchy. All Google Cloud platform resources belong to a project.
Projects are the basis for enabling and using GCP services like managing APIs, enabling billing and adding and removing collaborators and enabling other Google services.
Each project is a separate compartment and each resource belongs to exactly one.
Projects can have different owners and users – they’re built separately and they’re managed separately.
Project ID / Name / Number
Project has three identifying attributes
Each GCP project has a name and a project ID that you assign.
Project ID : Globally unique : Chosen by you : Immutable
The project ID is a permanent, unchangeable identifier and it has to be unique across GCP. You use project IDs in several contexts to tell GCP which project you want to work with. In general, project IDs are made to be human readable strings and you’ll use them frequently to refer to projects.
It is a a unique identifier for your project, composed of the project name and a randomly assigned number.
Project Name : Need not be unique : Chosen by you : Mutable
On the other hand, project names are for your convenience and you can assign them.
Project Number : Globally Unique : Assigned by GCP : Immutable
GCP also assigns each of your projects a unique project number and you’ll see a display to you in various contexts. It is a number that’s automatically generated by the server and assigned to your project.
You can organize projects into folders, although you don’t have to.
For example, you can use folders to represent different departments,
teams, applications or environments in your organization.
Folders let teams have the ability to delegate administrative rights,
so they can work independently.
The resources in a folder inherit IAM policies from the folder.
So, if project three and four are administered by the same team by design,
you can put IAM policies into folder B instead.
Doing it the other way, putting duplicate copies of those policies on
project three and project four would be tedious and error prone.
To use folders, you need an organization node at the top of the hierarchy.
You probably want to organize all the projects in your company into a single structure.
Most companies want the ability to have centralized visibility on how resources are being used and to apply policy centrally. That’s what the organization node is for. It’s the top of the hierarchy.
In part the answer depends on whether your company is also a G Suite customer.
If you have a G Suite domain, GCP projects will automatically belong to your organization node. Otherwise, you can use Google Cloud Identity to create one.
When you get a new organization node, it lets anyone in the domain create
projects and billing accounts just as they could before. That’s to avoid surprises and disruption.
But it’d be a great first step with a new organization node to decide who on your team should really be able to do those things.
Once you have an organization node, you can create folders underneath it and put it in projects.
The Google Cloud Platform Hierarchy is a internal platform resource hierarchy is something you should go out bottom up.
Whatever the resources utilized they are VM’s, cloud storage buckets, tables and big query, they are all organised into projects.
- Projects rollup into folders.
- Folders can also multiple other folders.
Together everything can rollup into an organisation node.
GCP Resources -> Projects -> Folders -> Organisation Node
Policies can be enforced at any level of this tree.