I have created the IAM user in instance.
While create Cloud IAM user its showing below error message
Required
After you create a user account with Cloud IAM authentication, it will have no database privileges, so make sure permissions are granted as needed.
How to access the database from IAM user. And what permissions are required?
I'm going to go out on a limb and assume you're talking about a Cloud SQL instance since the problem you're discussing mentions user accounts and Cloud IAM Authentication which is mentioned by Cloud SQL when creating user accounts.
To access a Cloud SQL you need two things:
Cloud SQL Client or another Cloud SQL Role that allows instance connection
Cloud SQL Instance User Credentials (May need to create a Cloud SQL user before you have these, and potentially grant specific permissions on your databases)
The final step is to allow your connection in to the Cloud SQL Instance, there's 2 major ways to do so: Use the Cloud SQL Auth Proxy, or adding your IP to the Cloud SQL Instance's Authorized Networks. * If your Cloud SQL Instance requires SSL/TLS connections you'll also require SSL Certs from your instance on top of authorized networks. The Cloud SQL Auth Proxy is inherently an SSL/TLS connection.
NOTE: Actual access to your Database is not granted via IAM roles. The IAM roles are merely to manage who can attempt to connect to your Cloud SQL instance and management of your Cloud SQL Instance. The Cloud SQL Instance User Credentials provide you with actual access to your Cloud SQL instance databases.
After having both of the requirements needed for a connection you'll need to decide on how to connect to your Cloud SQL instance. There's a variety of connection options, you'll have to decide on whichever method best fits your current use case.
EDIT: Added step 3, utilizing Cloud SQL Auth Proxy or using authorized networks
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 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.
On the instance details page of my Google Cloud SQL instance, I see that there's a "Service account" card on the dashboard with a value. The domain of which includes speckle-umbrella. This account doesn't show up in the IAM settings or any service account lists. Regarding its purpose, the most I've been able to find is this question but it seems to only deal with granting the account privileges. A couple of questions:
What is this account for?
Why is this account not enumerated with the rest of the service accounts?
Google Cloud SQL is a managed service and the instances you create and use actually run in a Google-owned project. The service account you mentioned belongs to that project and is used to perform operations in that project.
The relationship between both projects is clearer with some specific use-cases. For example, in the other SO question you linked about exporting data from CloudSQL to Google Cloud Storage, you need to grant access to your bucket to the service account in question since this SA will be used to authenticate the request to GCS.
Another example is when you create a CloudSQL instance with private IP. The connection through internal IP is made available by actually peering your network in your project with the network in the speckle-umbrella project where your CloudSQL instance resides. You're then able to see that peering in your Developer Console showing the "speckle-umbrella" project as peered project ID.
I have Cloud SQL and Instance in same project of Google Cloud.
I want to connect to Mysql (from Google Cloud SQL) from Instance using command line.
I am connecting using command:
gcloud sql connect cloud-sql-name --user=username
its giving:
ERROR: (gcloud.sql.connect) There was no instance found or you are not authorized to connect to it.
How do I make connection.
You probably missed the authorization of your instance's IP to be able to connect to the Cloud SQL database. This is done for e.g. through the Cloud Console in the Cloud SQL Instances page.
To see the step-by-step guide for connecting from Compute Engine instance to Cloud SQL (with the mysql client) check this docs page.
Are you trying to connect to your Cloud SQL instance from your Compute Engine VM instance?
If this is the case, I can suggest to first grant your service account (the Compute Engine default service account or a new one) the corresponding IAM role/permission for Cloud SQL [1].
Then, authenticate/activate [2] your service account within your VM instance command line (it is recommended to generate a JSON key File instead of a P12 key File for your service account):
~$ gcloud auth activate-service-account [ACCOUNT] --key-file=KEY_FILE
To generate a key File for your service account, you can go to your Products and Services menu > IAM & admin > Service accounts. Click on the three-dotted button at the right of the corresponding service account and select "Create key".
Your key File should be stored/uploaded to your VM instance, so that it can use it to activate the service account.
It is possible that you would also need to grant your VM instance access for Cloud SQL within its Cloud API access scopes panel. Go to your Products and Services menu > Compute Engine > VM instances. Select your VM instance and edit it.
Be aware that you will need to stop your VM instance before editing Cloud API access scopes. Go to "Access scopes" > "Set access for each API". Enable and Save.
You will also have to enable the Cloud SQL Admin API. Go to your Products and Services menu > API and services. Search for SQL Admin and Enable it (wait a few minutes)
Start the VM instance and try your Cloud SQL tests (re-activate your service account if necessary).
Your Cloud SQL instance for MySQL creates the "root" user. Just make sure to use this as the username, or any other you have created (if any).
Take into account that since you would be connecting from a Compute Engine VM instance, it is possible that yo will be asked for a MySQL Client.
[1] https://cloud.google.com/sql/docs/mysql/project-access-control
[2] https://cloud.google.com/sdk/gcloud/reference/auth/activate-service-account
default service account does not have access to cloud sql and has only read only access to storage.
I tried adding cloud sql admin and storage admin permission to defautl service account but that does not seems to work.
I know it can be solved by using another service account that have these permission and using that when creating compute instance.
I am just curious to know why updating permission of default compute does not work?
It seems that updating the permissions on the Compute Engine default service account is not enough to set the correct level of access you are trying to give to your Compute Engine instance, since, as described here:
When you set up an instance to run as a service account, the level of access the service account has is determined by the combination of access scopes granted to the instance and IAM roles granted to the service account.
From my understanding you are only granting IAM roles to the service account, so, in order to give the desired access level, you should also update the Access scopes for your Compute Engine instance.
When you create a new Compute Engine instance, under Access scopes, it is selected "Allow default access" by default as you can see here New instance. This default access has Cloud SQL access disabled and Cloud Storage access as read-only.
You can refer to this documentation which explains how to change the access scopes for a Compute Engine instance:
To change an instance's service account and access scopes, the instance must be temporarily stopped. To stop your instance, read the documentation for Stopping an instance. After changing the service account or access scopes, remember to restart the instance.
Once you stop your instance, you can change the Access scopes to either "Set access for each API" or to "Allow full access to all Cloud APIs".
If you choose to set access for each API, you will have to search for "Cloud SQL" and then select "Enabled" and also for "Storage" and select the desired option (Read Only, Write Only, Read Write, Full)
For more information on Access Scopes please refer to this doc and for more information on running Compute Engine instances as service account (including the default service account) please see this doc.
In the Cloud IAM Admin you have to select your Default Service Account by hitting on that pen to the right; then a side.bar will pop up, where you can assign the following roles: Cloud SQL Admin, Cloud SQL Client, Cloud SQL Editor, Cloud SQL Viewer. it's the default role is Editor.