GCP IAM - ghdrako/doc_snipets GitHub Wiki

https://cloud.google.com/iam/docs/understanding-roles#cloud-sql-roles

gcloud iam roles list | grep "name:"  # list roles
gcloud iam roles describe roles/compute.instanceAdmin #  see the permissions assigned to the role

gcloud projects add-iam-policy-binding $PROJECTID2 --member user:$USERID2 --role=roles/viewer

Create a custom role called devops that has the permissions to create an instance.

gcloud iam roles create devops --project $PROJECTID2 --permissions "compute.instances.create,compute.instances.delete,compute.instances.start,compute.instances.stop,compute.instances.update,compute.disks.create,compute.subnetworks.use,compute.subnetworks.useExternalIp,compute.instances.setMetadata,compute.instances.setServiceAccount"

The full name of the role is listed, note the role is in the project so the path is in the pattern of projects/PROJECT/roles/ROLENAME.

Bind the role to the account

gcloud projects add-iam-policy-binding $PROJECTID2 --member user:$USERID2 --role=roles/iam.serviceAccountUser

Test the newly assigned permissions.

gcloud config configurations activate user2
gcloud compute instances create lab-2

Create the service account

gcloud iam service-accounts create devops --display-name devops

Get the service account email address

gcloud iam service-accounts list  --filter "displayName=devops"

Give the service account the role of iam.serviceAccountUser and compute.instanceAdmin

SA=$(gcloud iam service-accounts list --format="value(email)" --filter "displayName=devops")
gcloud projects add-iam-policy-binding $PROJECTID2 --member serviceAccount:$SA --role=roles/iam.serviceAccountUser
gcloud projects add-iam-policy-binding $PROJECTID2 --member serviceAccount:$SA --role=roles/compute.instanceAdmin

Create an instance with the devops service account attached. You also have to specify an access scope that defines the API calls that the instance can make

gcloud compute instances create lab-3 --service-account $SA --scopes "https://www.googleapis.com/auth/compute"

Access scopes are the legacy method of specifying permissions for your instance. Access scopes are not a security mechanism. Instead, they define the default OAuth scopes used in requests from the gcloud tool or the client libraries. They have no effect when making requests not authenticated through OAuth, such as gRPC or the SignBlob APIs.

You must set up access scopes when you configure an instance to run as a service account.

A best practice is to set the full cloud-platform access scope on the instance, then securely limit the service account's API access with IAM roles.

Access scopes apply on a per-instance basis. You set access scopes when creating an instance and the access scopes persist only for the life of the instance.

Access scopes have no effect if you have not enabled the related API on the project that the service account belongs to. For example, granting an access scope for Cloud Storage on a virtual machine instance allows the instance to call the Cloud Storage API only if you have enabled the Cloud Storage API on the project.

In GCP, an IAM policy can be summarized as "[who] [can do what] [on what resources]." It has, therefore, three components:

who: This can be a Google account, a Google group, a service account, or an entire G-suite or Cloud Identity domain.
can do what: The permissions defined by an IAM role. There are three kinds of roles: primitive, predefined, and custom, as follows:

Primitive(Basic): These are the broad roles of owner, editor, and viewer. A viewer can examine but not change the state or configuration of a resource (that is, a viewer has read-only access); an editor can do everything a viewer can do, plus change the state and configuration of a resource; and an owner can do everything the editor can do, plus manage roles and permissions on the resource. If they're the owner at the project level, they can also set up billing for that project. The additional primitive role of the Billing administrator exists at the project level for access to setting up and managing billing, but not to editing project resources. Primitive roles are applied at the project level. [can do what] [on all resources in project]

Predefined: These are predefined roles specific to a GCP service that are aligned with the typical job roles of individuals using those services. For example, Compute Engine offers a set of predefined roles that define permissions to Compute Engine resources exclusively, such as instanceAdmin, along with a set of permissions necessary to create, modify, and delete virtual machines (VMs); or imageUser, which has a more specific set of permissions for listing and reading images. Each service will have its own set of predefined roles. Predefined roles are designed to map job functions. [can do what][on resource in project or folder or org] Colection of permission on particular services. Example Instance Admin Role (compute.instance.delete,compute.instances.get,compute.instances.list, compute.instances.setMachineType,compute.instances.start,compute.instances.stop

Custom: Roles where you can manually specify the list of permissions associated with the role. You must create and manage these types of roles yourself, but they're a fundamental component of the least privilege principle, which we will discuss in more detail later.

on what resources: The specific resources access is assigned for; that is, the scope of the permissions, which can also be a project, folder, or organization node. Since permissions are inherited from parent nodes, an access policy that's applied at any of the parent levels will affect all the resources down the hierarchy. Custom roles can only be applied at project and organization levels (not folders).

Service accounts are used when the "who" is a machine. They control server-to-server interactions, such as when a VM needs to access the Cloud Storage service. It is a crucial component of IAM as it prevents the usage (and storage) of a real user's credentials for this type of authentication. In GCP, service accounts use managed cryptographic keys as opposed to passwords to access resources. You can assign IAM roles to service accounts, just like you would with any user account. They are identified with email addresses, as follows:

Principle of least privilege and the IAM Recommender

The principle of least privilege states that an identity (be it a user, a system, or a group) should only be able to access the resources and perform actions that are strictly necessary for the user or system to perform its function.

The least privilege principle is one of the components of the zero trust security model

Segregation of duties - best practice in IAM

No one should have all rights, and highly privileged rights are spread among multiple people. Its intention can be divided into two key objectives:

Conflict of interest: This relates to abusing administrative power, and the possibility of wrongful acts being performed by individuals who would be responsible for reporting them themselves and whose acts are unrestricted.
Detection of security control failures: This includes security breaches or theft of information and intellectual property. An individual with influence over the design and implementation of security controls can potentially circumvent them and prevent, for example, reports of fraudulent activities from surfacing.

To reduce business risks and improve the organization's security posture, organizations must strive to apply segregation of duties to highly privileged operations and highly sensitive areas. Responsibilities and rights must be assigned to individuals so that no one single individual could compromise the system, and especially not be able to do so without any trace.

IAM allow policys

You can grant access to Google Cloud resources by using allow policies which are attached to resources. You can attach only one allow policy to each resource.

An allow policy is a collection of role bindings and metadata. A role binding specifies what access should be granted to a resource. It associates, or binds, one or more principals with a single IAM role and any context-specific conditions that change how and when the role is granted. The metadata includes additional information about the allow policy, such as an etag and version to facilitate policy management.

Policy metadata - etag (concurrency and consistency control) version (schema version for a given allow policy)

{
  "bindings": [
    {
      "members": [
        "user:[email protected]"
      ],
      "role": "roles/resourcemanager.organizationAdmin"
    },
    {
      "members": [
        "user:[email protected]",
        "user:[email protected]"
      ],
      "role": "roles/resourcemanager.projectCreator"
    }
  ],
  "etag": "BwUjMhCsNvY=",
  "version": 1
}

gcloud RESOURCE_TYPE add-iam-policy-binding RESOURCE_ID \
    --member=PRINCIPAL --role=ROLE_ID \
    --condition=CONDITION
# RESOURCE_TYPE projects, resource-manager folders, or organizations

#gcloud <resourceType> add-iam-policy-binding <resourceName> --member=<accountToGrantOnTheResource> --role=<roleToGrantOnTheResource>
# gcloud compute instances add-iam-policy-binding 
gcloud compute instances add-iam-policy-binding my-instance --zone=ZONE --member='user:[email protected]' --role='roles/compute.securityAdmin'
# gcloud spanner instances add-iam-policy-binding
gcloud spanner instances add-iam-policy-binding my-instance --member='user:[email protected]' --role='roles/editor'
# gcloud iam service-accounts add-iam-policy-binding
# Uwaga !!! Service account can be an identity and a resource.
gcloud pubsub subscriptions get-iam-policy \
   projects/${PROJECT}/subscriptions/${SUBSCRIPTION} \
   --format json
gcloud pubsub topics get-iam-policy \
    projects/${PROJECT}/topics/${TOPIC} \
    --format json
gcloud pubsub subscriptions set-iam-policy \
  projects/${PROJECT}/subscriptions/${SUBSCRIPTION} \
  subscription_policy.json
gcloud pubsub topics set-iam-policy  \
   projects/${PROJECT}/topics/${TOPIC}     \
   topic_policy.json
gcloud iam list-testable-permissions \
   https://pubsub.googleapis.com/v1/projects/${PROJECT}/subscriptions/${SUBSCRIPTION} \
   --format json
gcloud iam list-testable-permissions \
   https://pubsub.googleapis.com/v1/projects/${PROJECT}/topics/${TOPIC} \
   --format json

Policy contains roles and rolmembers and is asociate with resource. Resource inherit policy from each pareents. On top of hierarchy is organisation. Roles grant on this level are inherit by all resources.

If you change project hierarchy the policy hierarch also changed.

Child policies cannot restrict access granted at the parrent level.

org level - grant editor role and on project level grant view role - but effectivly you have editor on projrct level !!!

Members

google accout
service account - represent different logical application components
Google group - named collection fo google accounts
Cloud Identity or G Suit DOmain

Google Cloud Directory Sync

IAM Best Practice

Principle of least privilege - minimal access level required to get the job done
Use groups when when configuring GCP access
Assign roles to the groups instead of invidual users
Utilizing predefined roles offers less administrative overhead. Predefined role are managed by Google but Custom role are not
Audit logs record project-levelpermitionchanges
Audit policy changes
Export audit logs to Cloud Storage to store your logs for long periods of time