So, we have a "Compute Engine default service account", and everything is clear with it:
it's a legacy account with excessive permission
it used to be limited by "scope" assigned to each GCE instance or instances group
it's recommended to delete this account and use custom service account for each service with the least privilege principle.
The second "default service account" mentioned in the docs is the "App Engine default service account". Presumably it's assigned to the App Engine instances and it's also a legacy thing that needs to be treated similarly to the Compute Engine default service account. Right?
And what about "Google APIs Service Agent"? It has the "Editor" role. As far as I understand, this account is used internally by GCP and is not accessed by any custom resources I create as a user. Does it mean that there is no reason to reduce its permissions for the sake of complying with the best security practices?
You don't have to delete your default service account however at some point it's best to create accounts that have minimum permissions required for the job and refine the permissions to suit your needs instead of using default ones.
You have full control over this account so you can change it's permissions at any moment or even delete it:
Google creates the Compute Engine default service account and adds it to your project automatically but you have full control over the account.
The Compute Engine default service account is created with the IAM basic Editor role, but you can modify your service account's roles to control the service account's access to Google APIs.
You can disable or delete this service account from your project, but doing so might cause any applications that depend on the service account's credentials to fail
If something stops working you can recover the account up to 90 days.
It's also advisable not to use service accounts during development at all since this may pose security risk in the future.
Google APIs Service Agent which
This service account is designed specifically to run internal Google processes on your behalf. The account is owned by Google and is not listed in the Service Accounts section of Cloud Console
Addtiionally:
Certain resources rely on this service account and the default editor permissions granted to the service account. For example, managed instance groups and autoscaling uses the credentials of this account to create, delete, and manage instances. If you revoke permissions to the service account, or modify the permissions in such a way that it does not grant permissions to create instances, this will cause managed instance groups and autoscaling to stop working.
For these reasons, you should not modify this service account's roles unless a role recommendation explicitly suggests that you modify them.
Having said that we can conclude that remooving either default service account or Google APIs Service Agent is risky and requires a lot of preparation (especially that latter one).
Have a look at the best practices documentation describing what's recommended and what not when managing service accounts.
Also you can have a look at securing them against any expoitation and changing the service account and access scope for an instances.
When you talk about security, you especially talk about risk. So, what are the risks with the default service account.
If you use them on GCE or Cloud Run (the Compute Engine default service account) you have over permissions. If your environment is secured, the risk is low (especially on Cloud Run). On GCE the risk is higher because you have to keep up to date the VM and to control the firewall rules to access to your VM.
Note: by default, Google Cloud create a VPC with firewall rules open to 0.0.0.0/0 on port 22, RDP and ICMP. It's also a security issue to fix by default.
The App Engine default service account is used by App Engine and Cloud Functions by default. Same as Cloud Run, the risk can be considered as low.
Another important aspect is the capacity to generate service account key files on those default services accounts. Service account key file are simple JSON file with a private key in it. This time the risk is very high because a few developers take REALLY care of the security of that file.
Note: In a previous company, the only security issues that we had came from those files, especially with service account with the editor role
Most of the time, the user doesn't need a service account key file to develop (I wrote a bunch of articles on that on Medium)
There is 2 ways to mitigate those risks.
Perform IaC (Infra as code, with product like teraform) to create and deploy your projects and to enforce all the best security practices that you have defined in your company (VPC without default firewall rules, no editor role on service accounts,...)
Use organisation policies, especially this one "Disable service account key creation" to prevent the service account key creation, and this one "Disable Automatic IAM Grants for Default Service Accounts" to prevent the editor role on the default service accounts.
The deletion isn't a solution, but a good knowledge of the risk, a good security culture in the team and some organisation policies are the key.
Related
My organization is using GCP, and we have service accounts created for me and my co-workers. We need to use BigQuery storage transfer service, Cloud Dataflow and other Google Cloud resources.
1)So, what will be the recommended way of creating the scheduling job or creating the resources. Shall we create it via our service accounts or create another service account for the project and use that to schedule and use resources?
2)If it is done via my organization provided service account, what happens when I leave the organization and my service account is deleted. Does the jobs and pipelines continue to run under that project, or the resources are stopped?
NOTE Stackoverflow is focused on programming questions and this is not a programming question but more a question for help with architecture (guidance).
Service Accounts are non-user identities supported by Google.
Service Accounts are intended to be used by software|processes.
Service Accounts are Google resources that are "owned" by Google Projects (not Organizations nor users).
Service Accounts are deleted by Project members (users or indeed other Service Accounts that may inherit Project-specific roles from an Organization).
If a user (i.e. you) were to leave the organization, your org admins would likely delete your user account. This would not delete any Service Accounts. However, if your user identity had unique roles in the organization (represented by IAM permissions in the Google Organization and/or Project(s)), access to resources including Service Accounts could become inaccessible. For this reason, good org hygiene recommends that admin-like roles be assigned to groups rather than individual users.
I think it's good practice to create Service Accounts for software|processes on a per function basis. Some job should have its own Service Account.
This approach results in more Service Accounts but, it enables each Service Account to be exquisitely suited (IAM roles|permissions) to its job.
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 am creating a service account in a project en GCP, but a friend told me not to do that, instead to use a service account that already exists in another project.
So, the question is.
A service account created in a project in GCP can be used to access resources of diferent projects? or, it is only valid to access resources of the project where it was created?
Creating a service account is similar to adding a member to your project, but the service account belongs to your applications rather than an individual end user.
#dishant makwana is right, you can use a Service Account in any project, but you need to take in consideration some security factors.
Per my experience you should only grant the service account the minimum set of permissions required, even though you are only using your Service Account in a single project.
You can get more information in the following link: Granting minimum permissions to service accounts
Another good practice is to create service accounts for each service with only the permissions required for that service.
You could check this documentation with some best practices for Service Accounts.
Additionally, depending on your requirements you could consider to create short-lived credentials that allow you to assume the identity of a Google Cloud service account.
The most common use case for these credentials is to temporarily delegate access to Google Cloud resources across different projects, organizations, or accounts.
You could find more information in this link
In GCP, service account impersonation is a way to create temporary IAM credentials to perform an action as developer (see here). This has been described as equivalent to assuming a role in AWS - see this other question.
My question is:
is this the recommended/canonical way of doing this in google cloud, namely grouping permissions around service accounts & allowing developers to inpersonate that service account ?
Or alternatively is it better to create custom roles and assign them directly to developers identities (and not indirectly via a service account)? But then of course you lose the advantage of short living credentials.
If the first option is valid, it would also mean that you would end up having as many service accounts as roles in AWS.
In general, you should grant IAM roles to groups, and then add developers to the appropriate groups.
For example, you may want to grant all developers "Editor" access to a project. To do this, grant group:ll-developers#yourcompany.com the Editor role to the project. Then, use LDAP or G Suite to ensure that all developers are a member of that group.
You can give developers the ability to actAs a service account, but then the audit logs and principal would be the service account, not the developer.
Enabling the Cloud Run API (dev console→Cloud Run→Enable) creates five service accounts. I want to understand their purpose. I need to know if it's my responsibility to configure them for least privileged access.
The Default compute service account has the Editor role. This is the Cloud Run runtime service account. Its purpose is clear, and I know it's my responsibility to configure it for least privileged access.
The App Engine default service account has the Editor role. This matches the description of the Cloud Functions runtime service account. Its purpose is unclear, given the existence of the Cloud Run runtime service account. I don't know if it's my responsibility to configure it for least privileged access.
The Google Container Registry Service Agent (Editor role) and Google Cloud Run Service Agent (Cloud Run Service Agent role) are both Google-managed service accounts "used to access the APIs of Google Cloud Platform services":
I'd like to see Google-managed service accounts configured for least privileged access. I'd also like to be able to filter the Google-managed service accounts in the IAM section of the GCP console. That said, I know I should ignore them.
The unnamed {project-number}{at}cloudbuild.gserviceaccount.com service account has the Cloud Build Service Account role. This service account "can perform builds" but does not appear in the Cloud Run Building Containers docs. It's used for Continuous Deployment—but can't do that without additional user configuration. It's not a Google-managed service account, but it does not appear in the Service Accounts section of the GCP console like the runtime service accounts. Its purpose is unclear. I don't know if it's my responsibility to configure it for least privileged access.
Cloud Run PM:
Yep, exactly right.
We should probably not create this if you're only using Run (and likely not enable the App Engine APIs, which is what created this). During Alpha, this was the runtime service account, and it's likely that it wasn't cleaned up.
I have a feeling it's stuck as Editor because it accesses Cloud Storage, which is oddly broken for "non Editor access" (I'm still trying to track down the exact issue, but it looks like there's a connection to the legacy Editor role that requires it).
Is already "least privileged" from it's perspective, as it only has the permissions to do the things that Run needs to do in order to set up resources on your behalf.
This is the runtime service account equivalent for Cloud Build, and falls into the same category as 1,2. If you need a build to deploy to Cloud Run, you have to grant this account something like Cloud Run Deployer (plus to the additional step of allowing the build service account to act as your runtime service account, to prevent [or at least acknowledge] privilege escalation).
I too want better filtering of "Google created" and "Google managed" and have been talking with the Cloud IAM team about this.