I created a new VM in a google compute engine project. I changed the "Compute Engine" access scope to "Read Write" after creating the VM.
On the existing (long-running) VM, if I do:
gcloud iam service-accounts list
I see the default service account for the project.
However, if I do the same thing on the newly created VM, I get an error:
gcloud iam service-accounts list
ERROR: (gcloud.iam.service-accounts.list) User [<service-account>] does not have permission to access projects instance [<project>] (or it may not exist): Request had insufficient authentication scopes.
The original VM is a ubuntu-16, the new VM is ubuntu-18 freshly created from a google image.
If I look at the project IAM roles, my user has the following roles:
- Access Approval Config Editor
- Compute Admin
- Role Viewer
- Service Account Admin
- Owner
- Organization Administrator
What am I missing?
The access scopes for the two VMs are the same:
- Compute Engine Read Write
- Service Control Enabled
- Service Management Read Only
- Stackdriver Logging API Write Only
- Stackdriver Monitoring API Write Only
- Stackdriver Trace Write Only
- Storage Read Only
What controls access for the individual VMs other than the access scopes?
The problem was the SSH window was running under the service account, not my normal user account. I needed to run
gcloud init
to reconfigure to use my regular account.
I discovered this by doing
gcloud config list
on both machines.
PART 1
What controls access for the individual VMs other than the access
scopes?
The union of Compute Engine Scopes and service account permissions.
Google Compute Engine scopes limit permissions, scopes do not grant permissions.
The service account assigned to Compute Engine determines the permissions/roles that are available. Scopes can limit those permissions granted to the service account. Scopes cannot grant permissions that the service account does not already have.
Scopes are a legacy authorization mechanism.
PART 2
gcloud iam service-accounts list ERROR:
(gcloud.iam.service-accounts.list) User [] does not
have permission to access projects instance [] (or it may not
exist): Request had insufficient authentication scopes.
Part of this message is confusing to most people. Scopes are a legacy authentication mechanism that Google used before IAM. Scopes are similar to permissions and in this message mean OAuth 2 Permissions.
The command gcloud iam service-accounts list requires the permission iam.serviceAccounts.list which is present in roles such as roles/iam.serviceAccountUser named Service Account User. The service account mentioned in the error does not have one of the roles granting the permission to list service accounts or the Scopes are limiting a permission granted to the service account. Read my recommendation at the end.
Service Account Roles
Part 3
If I look at the project IAM roles, my user has the following roles:
The roles assigned to the user are not related to the roles assigned to the Compute Engine service account.
If you logged into Compute Engine using SSH and did not do anything else to authenticate then you are using Compute Engine Default Service Account credentials. Service Account and Scopes affect your permissions.
If you logged into Compute Engine using SSH and you use your own account for authentication (gcloud auth login or similar) then your user identity is using the the permissions granted to your user account and not the Compute Engine Default service account credentials.
Part 4
The original VM is a ubuntu-16, the new VM is ubuntu-18 freshly
created from a google image.
If the scopes are the same for both VMs, then your issue is the service account. Normally Compute Engine VMs use the Compute Engine Default Service Account. You can change which service account is assigned to each VM. Double check what is assigned to each VM.
Summary
I recommend that you set the scopes to Allow full access to all Cloud APIs and control the permissions via roles granted to the service account. Do not use roles such as Project Owner or Project Editor. Those roles are very powerful. Use fine grained permissions for each Google Cloud service that Compute Engine needs to access.
Related
I want to automate the creation of development servers within my org's GCP account that are tied to an individual developer.
I intend to script the copying of relevant credentials (think crypto key for GitHub). How do I lockdown the VM so that only a single user can access it. GCP has options like block-project-ssh-keys but we've found that all users are still able to login using gcloud compute ssh.
I fear this may require a really complex IAM configuration.
Is there an easy way to accomplish this? (IAM or otherwise)
Has anyone seen a project that has automated this or something similar to this? (IAM provisioning of a new tag/group/etc. using a script when a new user joins the org)
Enable OS Login on the project, ideally by using an organizational policy constraint. OS Login automatically disables metadata-based SSH keys.
Grant OS Login roles individually per VM and user so that each user can only login to their own VM.
Either don't attach service accounts to the VMs at all, or create dedicated service accounts per VM. Then grant users the Service Account user role on "their" service account only.
Don't grant any Compute* roles beyond Compute Viewer on the project. In particular, don't grant Compute Admin or Compute Instance Admin, or any other role that lets users modify instance metadata (because that would let them alter startup and shutdown scripts).
Optionally:
Grant the users Compute Viewer on the project. That ensures that they can list VMs in the Cloud Console.
Only allow SSH access via IAP TCP forwarding, and grant the IAP-secured tunnel user role on a per-VM, per-user basis.
I am looking to Restrict creation of VMs on GCP projects. Any workaround for this request.
You might want to try IAM Roles if you do a proper role segmentation within the users of your organization you can restrict all users/groups from creating VMw on your GCP project. Here is another link regarding IAM
The compute IAM role are too broad. If you want finer control, you need to create a custom role without this permission compute.instances.create
You can assign in IAM just permission to create instance. Here are some documentation what roles you can use.
With IAM, every API method in Compute Engine API requires that the identity making the API request has the appropriate permissions to use the resource. Permissions are granted by setting policies that grant roles to a member (user, group, or service account) of your project.
The following tables describe the predefined Compute Engine IAM roles, as well as the permissions contained within each role. Each role contains a set of permissions that is suitable for a specific task. For example, the Instance Admin roles grant permissions to manage instances, the network-related roles include permissions to manage network-related resources, and the security role includes permissions to manage security-related resources, like firewalls and SSL certificates.
Compute Admin role
Name Description Permissions
roles/compute.admin
Full control of all Compute Engine resources.
If the user will be managing virtual machine instances that are configured to run as a service account, you must also grant the roles/iam.serviceAccountUser role.
compute.*
resourcemanager.projects.get
resourcemanager.projects.list
serviceusage.quotas.get
serviceusage.services.get
serviceusage.services.list
click here for more documentation.
Set Quotas in GCP , Quota for VMs are based on the region.
https://cloud.google.com/compute/quotas#understanding_quotas
"The VM instances quota is a regional quota and limits the number of VM instances that can exist in a given region, regardless of whether the VM is running. This quota is visible in the Google Cloud console on the Quotas page. "
I created a service account mycustomsa#myproject.iam.gserviceaccount.com.
Following the GCP best practices, I would like to use it in order to run a GCE VM named instance-1 (not yet created).
This VM has to be able to write logs and metrics for Stackdriver.
I identified:
roles/monitoring.metricWriter
roles/logging.logWriter
However:
Do you advise any additional role I should use? (i.e. instance admin)
How should I setup the IAM policy binding at project level to restrict the usage of this service account just for GCE and instance-1?
For writing logs and metrics on Stackdriver those roles are appropriate, you need to define what kind of activities the instance will be doing. However as John pointed in his comment, using a conditional role binding 1 might be useful as they can be added to new or existing IAM policies to further control access to Google Cloud resources.
As for the best practices on SA, I would recommend to make the SA as secure as possible with the following:
-Specify who can act as service accounts. Users who are Service Account Users for a service account can indirectly access all the resources the service account has access to. Therefore, be cautious when granting the serviceAccountUser role to a user.
-Grant the service account only the minimum set of permissions required to achieve their goal. Learn about granting roles to all types of members, including service accounts.
-Create service accounts for each service with only the permissions required for that service.
-Use the display name of a service account to keep track of the service accounts. When you create a service account, populate its display name with the purpose of the service account.
-Define a naming convention for your service accounts.
-Implement processes to automate the rotation of user-managed service account keys.
-Take advantage of the IAM service account API to implement key rotation.
-Audit service accounts and keys using either the serviceAccount.keys.list() method or the Logs Viewer page in the console.
-Do not delete service accounts that are in use by running instances on App Engine or Compute Engine unless you want those applications to lose access to the service account.
I have a Google cloud project created.
I created a service account with project editor role.
Now, if I give a user, serviceAccountUser role to the service account, it doesn't automatically gives the user permission on the project.
If I login using that user to Google cloud console, I'm unable to see the project itself.
It says in the documentation - "Users granted the Service Account User role on a service account can use it to indirectly access all the resources to which the service account has access." So, I thought I would be able to access all the projects as well. Does the above statement mean something else?
On GCP you have user accounts and service accounts. The main purpose of the service accounts is to consume GCP services via API calls, the documentation says: "A service account is a special type of Google account intended to represent a non-human user that needs to authenticate and be authorized to access data in Google APIs.". For login and interact with the GUI and resources you need a user account, if you want to see the resources the account need the viewer role, if you need perform operations on the resources you need admin role, review the documentation for more information (How IAM works).
what's the equivalent of AWS account number in Google cloud ?
If the user adds 2 service accounts to a portal, how to validate if the service accounts belong to different accounts or a single account.
AFAIK in GCP there's no account ID.
By reading the AWS documentation looks like the concepts are slighty different in GCP and in AWS.
As I understand, you want to identify if a service account in GCP belongs to an account, the thing here is that service accounts in GCP do not belong to any account.
Quoting from the documentation:
One of the features of IAM service accounts is that you can treat it both as a resource and as an identity.
When treating the service account as an identity, you can grant a
role to a service account, enabling it to access a resource (such as
a project).
When treating a service account as a resource, you can grant permission to a user to access that service account. You can grant
the Owner, Editor, Viewer, or Service Account User role to a user to
access the service account.
Example of how service accounts work in GCP as an identity:
Let's say that I have 2 GCP projects where I am owner in both
projects:
projectA where I am owner with my email owner-of-project#gmail.com
projectB where I am owner with my email owner-of-project#gmail.com
I log into projectA with owner-of-project#gmail.com and from there I create a service account:
Service account name: service-account-project-A
Role of the service account (permissions): "Compute Engine Admin" (meaning that this service account will have only access to Compute Engine resources within projectA).
Service account ID: service-account-project-a#projectA.iam.gservice
I can choose to generate a private key for this service account
I can also choose to enable G Suite Domain-wide Delegation
Then I can log into projectB with owner-of-project#gmail.com.
Once there I can add the service account as a member of projectB so the Compute Engine resources within project A will be reachable from projectB.
What you can do is list all the service accounts that are added in a particular project in the Service Accounts section of GCP Console.