0
votes

I created a service account [email protected].

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:

  1. Do you advise any additional role I should use? (i.e. instance admin)

  2. 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?

1
What do you want to do with this service account and this VM? Which service do you need to access?guillaume blaquiere
1/2) Do you mean that you want to assign the new service account to be the default service account for the VM? If yes, then the service account only needs the roles for tasks that the VM must do while running (example to log to Stackdriver) or when someone has logged into that instance (via SSH). The answer requires a well defined list on what the VM needs to do and what it is used for.John Hanley
2/2) You cannot restrict a service account to be assigned to only one resource (a VM in your example). You can use Conditional Role Bindings to restrict what resources (by name, example Bucket A) the service account can access.John Hanley
From the best of my understanding, a service account can get permissions on a particular resource (instance), if that is allowed by IAM of the given API. For example, a permision can be granted to one chosen BigQuery table, or chosen dataset, rather than all datasets or tables in a given project.al-dann
Here I have a doubt: I know I can assign a SA directly to an instance, but the instance but exist a priori. However, I would assume that a "better practice" is to assign the SA when creating such an instance. Is that correct? Do you have any other advice?SubZeno

1 Answers

1
votes

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.