GCP - For particular bucket make policy for access - google-cloud-platform

In my GCP project, people have storage admin access. I want to restrict the person and give few members writing access in the GCP bucket. When I try to revoke the access it is saying cannot change access as it is inherited.
Any way to create custom access for a particular storage bucket in GCP. I have to make this for the AIRFLOW DAG bucket.

Custom roles cannot be recognized upwards on the resource hierarchy. For example, a role created at the project level cannot be used at the folder or organization level.
Similarily, custom roles cannot be recognized laterally. For example, a custom role created at the project level cannot be used in bindings in another project even if they are in the same folder or organization.
To use a custom role in different projects or different folders, customers have to create/define the roles at the parent organization level. Note that currently, a custom role cannot be created at the folder level.
For more information on custom roles you can check the public documentation.

Related

Understanding GCP IAM policies for various resources

I want to list IAM policies or access levels for various resourses. I followed docs and I'm able to list it for projects. There are various resources and I'm somewhat confused with it.
Is all other resourses come inside the project? (Basically I'm confused with the chain)
If someone have access to project (read/write/anything else) then can they have access to resourses inside the projects?
If other resourses are independent then how to list their IAM policies? (For each individual resourse)
I'm using GCP Oauth2 API and would highly appreatiate if anyone at least answer the above questions.
Is all other resourses come inside the project?
Yes,
For a specific project, you can use search-all-resources to search all the resources across services (or APIs) and projects.
To use the number 123 to search every resource in a project:
$ gcloud asset search-all-resources --scope=projects/123
If someone has access to a project (read/write/anything else) then can they have access to resources inside the projects?
Results from the above command are the resources in that project. If you have a user who has an owner role in the project then the user can manage roles and permissions for a project and all resources within the project. If a user has a viewer role then the user has permissions for read-only actions that do not affect state, such as viewing (but not modifying) existing resources or data.
Some resources also have separate permissions,a user can have permissions other than project level that is Individual permissions to the specific resource, by using them you can restrict the user to access projects but the user can access a specific resource.
Here you can find Access control for projects with IAM.
If other resources are independent then how to list their IAM policies? (For each individual resource)
Google has Predefined roles for every resource in the project you can filter out the specific resource by searching the resource in this doc, those are predefined roles which can assign a user to the specific resource.
You can find more information in this doc.
The ORG, Folder, and Project are resources. They have an API to access IAM Policy Bindings. Cloud Storage, KMS, Compute Engine, Cloud Run, Functions, etc are also resources. They have an API to access IAM Policy bindings. Look up the API for each resource type.
In Google Cloud, many resources support IAM Policy Bindings but not all.
Is all other resourses come inside the project? (Basically I'm
confused with the chain)
Google Cloud resources belong to projects in almost all cases. Billing Accounts and Payment Accounts are examples that are separate.
If someone have access to project (read/write/anything else) then can
they have access to resourses inside the projects?
If as you say "read/write/anything else", then yes. If they have the correct IAM roles at the project level, they can access the resource. Since some resources also support their own IAM Policy Bindings, a user can be granted access to a resource at the resource level without having permission at the project level.
If other resourses are independent then how to list their IAM
policies? (For each individual resource)
You must access the resource's IAM Policy Bindings. Each resource that supports IAM Policy Bindings has a corresponding API to read/modify.
Note: resources are not independent. They are owned by a project in almost all cases as I mentioned previously.

Understanding GCP IAM between multiple projects

In my organization, we work with GCP and have multiple projects there. I'm now trying to organize the IAM roles between all the projects and I'm not sure about some of the IAM settings. Are to projects act as completely separate entities with completely different IAM roles/permissions or are there any overlap between them that can lead to that a change in one project might affect another project?
Changing roles in one project will not directly change roles set on another project. But there are some things you'll want to consider.
While projects can have their own access control rules, it is possible to manage access at more than the project level. Here are the four resource points where you can manage access:
Organization level. The organization resource represents your company.
IAM roles granted at this level are inherited by all resources under
the organization.
Folder level. Folders can contain projects,
other folders, or a combination of both. Roles granted at the highest
folder level will be inherited by projects or other folders that are
contained in that parent folder.
Project level. Projects represent a
trust boundary within your company. Services within the same project
have a default level of trust. For example, App Engine instances can
access Cloud Storage buckets within the same project. IAM roles
granted at the project level are inherited by resources within that
project.
Resource level. In addition to the existing Cloud Storage and
BigQuery ACL systems, additional resources such as Genomics Datasets,
Pub/Sub topics, and Compute Engine instances support lower-level roles
so that you can grant certain users permission to a single resource
within a project.
Access can be at the individual level, through a service account, or through organization-wide and Google Group membership. That means that when you add or remove someone from the organization or a Google group, you may inadvertently add or remove them from various roles in different projects.
Also, if a member (individual or group) is assigned a role that gives the capability to change IAM roles, then anyone in that member group can modify permissions. They may change rules in ways you don't want.
When in doubt, use testPermissions to verify that roles are working as expected.
The IAM roles you set in a project won't affect other projects.
Google Cloud resources are organized hierarchically, where the organization node is the root node in the hierarchy, the projects are the children of the organization, and the other resources are descendants of projects. You can set Identity and Access Management (IAM) policies at different levels of the resource hierarchy. Resources inherit the policies of the parent resource. The effective policy for a resource is the union of the policy set at that resource and the policy inherited from its parent.
Please check the following documentation where you will find a good explanation of the resource hierarchy for access control
I think this diagram can help you to understand better how IAM works:

Google Cloud Bucket with permission for just my user

I have Google Cloud project shared with few collages and few service accounts. I have Owner permission on the GCP project.
I want to create a Google Cloud Storage Bucket that only me will have access to it. So, the other users and service accounts in the projects will can't see it.
I created a new Google Cloud bucket (permission: Uniform) and went into the "Permission" sections. This list was already filled with inherits permissions. Since I want that only me will have access into this bucket:
I was added my self as Storage Admin
I removed the permissions for Owner, Editor and Viewer for this repository.
Now I have list with all the service accounts in the project. Unfortunately, Google not allowing me to remove the access of those service accounts:
How to revoke account to those service-accounts to this bucket?
These are inherited access which cannot be removed at bucket level.
Roles are always inherited, and there is no way to explicitly remove a permission for a lower-level resource that is granted at a higher level in the resource hierarchy.
As a principle of least priviledge grant minimum scope to the service accounts.

Google Cloud Resource created with user that is not in IAM

Situation:
I have a GCP project (owner) that is under a organization I do not have access to, so I see it in No Organization
a user (xyz#domain.com) has created a subscription for an existing pubsub topic, I see that under activity and the audit logs
this user is not visible for me in IAM (e.g. as editor, or with some pubsub specific role)
neither can I see this user in any pub/sub related topic/subscription, with a role, specifically not in the topic he created the subscription in
Summary:
xyz#domain.com created a subs.
I don't know where he got the role from (inherited?)
Question:
Is it possible that this person has e.g. editor on the organization (or some folder above the project) but I don't see that role in my IAM section of the project?
If not, where could the role be inherited from?
Creating a Subscribtion
To subscribe to a Pub/Sub topic a user should be able to create a Subscription object. To do that, a permission pubsub.subscriptions.create on a Topic is needed. It could be assigned explicitly onto a Topic or inherited from the parent levels (Project, Folder, Org) via:
a Custom Role inherited from the Project level or above;
a Predefined Role pubsub.editor or pubsub.admin assigned at the Pub/Sub Topic level or inherited from a parent level;
a Primitive Role Editor or Owner inherited from the Project or Service Resource level or above; for example, the Compute Engine default service account freshly created VM Instances are working on behalf of has an Editor Role on the Project it is part of.
Viewing role assignments
To trace where effective rights are inherited from, one would need at list the following Permssions:
resourcemanager.organizations.getIamPolicy
resourcemanager.folders.getIamPolicy
resourcemanager.projects.getIamPolicy
IAM Predefined Roles that contain that permissions are:
resourcemanager.organizationAdmin
iam.securityAdmin
iam.securityReviewer
IAM Predefined Roles that can trace up to the Folder level are:
resourcemanager.folderAdmin
resourcemanager.folderEditor
resourcemanager.folderIamAdmin
IAM Primitive Roles:
Viewer
Editor
Owner
To obtain the comprehensive view of resulting permissions you should be granted the Roles listed above assigned as high as possible in the IAM hierarchy (ideally at the Org level) to get enough administrative scope for investigation.
You can't see bindings that are located outside of the administrative scope you've got. Therefore you can't see the level where permissions are inherited from as well as security subject the permissions are granted for.
Back to the questions
Is it possible that this person has e.g. editor on the organization (or some folder above the project) but I don't see that role in my IAM section of the project?
Yes
If not, where could the role be inherited from?
An Org level and all Folder levels (those could be nested) above your Project.
Vendor documentation
IAM Roles
Cloud Pub/Sub | Access Control | Roles
Support level for permissions in custom roles

How do I restrict a Google service account?

If I create a service account in my project and give it to a third party, can that third party abuse it to create VM instances etc? Or is it only allowed to do things that I give it explicit permission to do?
In the "permissions" section of the Google developers console I can set the service account to "Can edit" or "Can view", but what do those mean?
If you give "edit" or "owner" permissions, the user can create, modify, or delete GCE VM instances (among other resources). If you only give "view" permissions, then they can't create, modify, or delete GCE VM instances.
However, you cannot give fine-grained permissions such as "user can only edit this VM instance, but not this other one".
Per Google Compute Engine docs:
Can View
Provides READ access:
Can see the state of your instances.
Can list and get any resource type.
Can Edit
Provides "Can View" access, plus:
Can modify instances.
On standard images released after March 22, 2012, can ssh into the
project's instances.
Is Owner
Provides "Can Edit" access, plus:
Can change membership of the project.
Per Google Cloud Storage docs:
Project team members are given the following permissions based on
their roles:
All Project Team Members
All project team members can list buckets
within a project.
Project Editors
All project editors can list, create, and delete buckets.
Project Owners
All project owners can list, create, and delete buckets, and can also perform administrative tasks like adding and removing team members and changing billing. The project owners group is the owner of all buckets within a project, regardless of who may be the original bucket creator.
When you create a bucket without specifying an ACL, the project-private ACL is applied to the bucket automatically. This ACL provides additional permissions to team members, as described in default bucket ACLs.
Per Google Cloud SQL docs:
Team members may be authorized to have one of three levels of access:
“can View” (called Viewer in App Engine Console) allows read-only
access.
“can Edit” (called Developer in App Engine Console) allows
modify and delete access.
This allows a developer to deploy the
application and modify or configure its resources.
“is Owner” (called
Owner in App Engine Console) allows full administrative access.
This
includes the ability to add members and set the authorization level of
team members.