I am using a Google Cloud Project to automate the creation of some users inside of our organization. I have been using some API's that are hosted using the Google Cloud and have had no problem authenticating and using the API's, however I am not sure if I should be using a service account for this. I am currently using the Google Drive API, the Google Admin SDK(Directory API), the Sheets API, and the Docs API to create some accounts and manage an error log.
What I am asking is, should I be creating a service account to use the API's or is my own personal Google Workspace account okay for creating these? Is there a site/video/something that can guide me in the right direction if I do need to create a service account. I personally would rather have all of the automation using a service account for authentication, but the only videos and tutorials I found on using the service accounts are trying to use resources pertaining to Cloud Computing and service accounts that are impersonating other service accounts.
Using a Service Account is the best course of action for security reasons when you are the one giving authorization and authentication to your organization.
It is identical to granting access to any other identity to allow a service account access to a resource. For instance, suppose you only want an application that runs on Compute Engine to be able to generate items in Cloud Storage.
As a result, instead of managing each and every one of your users, you may limit and manage service accounts, assign certain roles to specific users or groups, and keep track of them because several service accounts can be created in a project.
Since you use Google Workspaces, I also advise you to read the shared documentation posted in the comments by #John Hanley.
I'm using text-to-speech API on Google Cloud. I'm used with service accounts, roles or API Keys on GCP, but I feel lost with this AP and don't understand how I can set the permission to access this API.
The API forbid anonymous call, but I tried to create a service account with no specific permission, and it can access the API. Have this API only project level permission (API enabled or not)? How can I set what account can access the API?
In Google Cloud Platform the restriction works the other way around than what you described, you create Service Account and you limit to what resource they can access. Please see documents: Understanding service accounts and Service accounts to learn more, and specifically Permissions for service accounts to learn how to restrict permissions on your Service Accounts.
Added to the above, this API Console Help document contains best practices and further information on API security
I'm currently investigating the most appropriate authentication/authorization approach for a greenfield project, to be entirely hosted on Google Cloud Platform. I'm writing this summary to do a sanity check of my preferred approach & seek feedback on whether there are any considerations or inaccuracies I'm unaware of. I would appreciate input from anyone with relevant experience in implementing the associated strategies.
The main queries/concerns I have are:
How to manage or negate scopes in the OIDC process? It should not be up to the user to authorize appropriate access; this should be set by the org IT admins that created the user
Can G Suite IT admins apply params to users (custom &/or not) which automatically allocate predefined "Google Identity/IAM" policy groups/roles?
Will the G Suite users signed JWT's/Google ID be directly compatible with Endpoints + IAP (not requiring any processing/re-encoding)?
Will this approach accomodate external users via a federated identity approach, in future, without major refactors to the existing process (e.g. Firebase auth)?
Requirements:
Angular SPA will be the single GUI for the application, hosted on the same domain registered for the organisation on GCP/G Suite
SPA will use GCP's api gateway (Endpoints) to make requests to GKE micro-services (likely all within the one VPC) & other G Suite services (Drive, etc)
Org IT G Suite admin's can create users & assign various (predefined) IAM policy groups/scopes via the G Suite UI, to give users least privilege access to org resources (G Suite services & GCP hosted custom api's/apps)
Users are ONLY able to "sign in with Google" to the SPA, using their orgs G Suite account
If the User is already signed into their org google account, they should not need to sign in again to the SPA
While logged into the SPA, the users credentials should be sent with each request, which micro-services will use for authorization of custom business logic, as well as passing those credentials to G Suite services like Google Drive (leverage api scopes authorization as additional layer of security if custom business logic fails)
In the distant future, there is potential to allow customers/users, external to the org, to utilize various federated identity providers (Facebook, Twitter, etc) to access a SPA & resources hosted by the org (this is not a current requirement, but it is a long term strategic goal)
The two approaches I've determined best fit for purpose are:
1) Endpoints
Google Sign-In with IT Apps to obtain the users org Google ID &, as we are using OpenAPI, the GCP Endpoints with an Identity-Aware Proxy (IAP), to manage authentication of the JWT token.
Pros:
Establishes a clear demarcation between internal users of the UI portal, & potential future external users
No custom code for IT admins to manage users
No custom code to sync Firebase & G Suite users, roles, permissions, etc, or access the mirrored G Suite user for credentials
OR, 2) Firebase
Firebase authentication, & write code to generate users in G Suite with the Firebase Admin SDK, restricting access to resources based on the org domain.
Pros/Cons are the opposite to Endpoints above, plus no need for 2 separate auth approaches if external users are ever required.
I'm leaning towards the Endpoints approach...
How to manage or negate scopes in the OIDC process? It should not be
up to the user to authorize appropriate access; this should be set by
the org IT admins that created the user
Permissions for IAM members (users, groups, service accounts, etc) are managed in Google Cloud IAM. Scopes are used with OAuth to limit permissions already assigned by IAM. Best practices mean assigning the required permissions (and no more) and not combing IAM with scopes.
Can G Suite IT admins apply params to users (custom &/or not) which
automatically allocate predefined "Google Identity/IAM" policy
groups/roles?
G Suite and Google Cloud are separate services. Google Cloud supports G Suite as an Identity provider (IDP). Permissions are controlled in Google Cloud IAM and not in G Suite. You can combine G Suite with Google Groups to put IAM members into groups for easier IAM management.
Will the G Suite users signed JWT's/Google ID be directly compatible
with Endpoints + IAP (not requiring any processing/re-encoding)?
Google Accounts (G Suite) do not provide private keys to its member accounts. Therefore you cannot use Signed JWTs. Signed JWT is an older authorization mechanism and is used with service accounts. The correct method for user credentials is OAuth 2.0 Access and Identity tokens. For administrators, service accounts with Domain Wide Delegation can be used.
Will this approach accomodate external users via a federated identity
approach, in future, without major refactors to the existing process
(e.g. Firebase auth)?
This is a difficult question to answer. Google Cloud does support external identity providers but I have found this to be problematic at best. You can also use identity synchronization but this is also not well implemented. If you are going the Google Cloud route use G Suite as your identity provider and Google Cloud IAM for authorization.
An important point that I think your question lacks is understanding how authorization works in Google Cloud and Google APIs. These services primarily use OAuth 2 Access Tokens and Identity Tokens. This varies by service and with the type of access required. This means that your application will need to understand the services that it is accessing and how to provide authorization. I have a feeling that you are expecting Firebase/Endpoints to do this for you.
Another item is that Firebase is part of Google Cloud and is only a subset of Google Cloud. Firebase is a great product/service but if you are planning to use Google Cloud features outside of Firebase, then stay with G Suite and Cloud IAM for identity and authorization.
Angular SPA will be the single GUI for the application, hosted on the
same domain registered for the organisation on GCP/G Suite
I am assuming by domain you mean DNS Zone (website DNS names). This will make CORS and cookie management easier but is not a requirement.
SPA will use GCP's api gateway (Endpoints) to make requests to GKE
micro-services (likely all within the one VPC) & other G Suite
services (Drive, etc)
OK - I don't see any problems using Endpoints. However, a good answer requires details on how everything is actually implemented. Another item is that you are mentioning Endpoints and G Suite services. These are very different items. Endpoints protect your HTTP endpoints not other Google services where it would just get in the way.
Org IT G Suite admin's can create users & assign various (predefined)
IAM policy groups/scopes via the G Suite UI, to give users least
privilege access to org resources (G Suite services & GCP hosted
custom api's/apps)
Google Cloud IAM and G Suite authorization are separate authorization systems. In order for G Suite members to manage Google Cloud IAM, they will need roles assigned in Google Cloud IAM via either their member ID or group membership. There is no shared authorization permissions.
Users are ONLY able to "sign in with Google" to the SPA, using their
orgs G Suite account
Unless you configure SSO, Google Account members are the only ones that can authenticate. Authorization is managed by Google Cloud IAM.
If the User is already signed into their org google account, they
should not need to sign in again to the SPA
That is up to your application code to provide the correct Authorization header in requests.
While logged into the SPA, the users credentials should be sent with
each request, which micro-services will use for authorization of
custom business logic, as well as passing those credentials to G Suite
services like Google Drive (leverage api scopes authorization as
additional layer of security if custom business logic fails)
I am not sure what you mean by "User Credentials". You should never have access to a user's credentials (username/password). Instead, your application should be managing OAuth Access and Identity Tokens and sending them to the backend for authorization.
In the distant future, there is potential to allow customers/users,
external to the org, to utilize various federated identity providers
(Facebook, Twitter, etc) to access a SPA & resources hosted by the org
(this is not a current requirement, but it is a long term strategic
goal)
I covered this previously in my answer. However, let me suggest clearly thinking about what needs to be authorized. Authorization to your app is different that authorization to your app that also authorizes Google Cloud services. For example, you could use Twitter for authentication and a single service account for Google Cloud authorization. It just depends on what you need to accomplish and how you want to manage authorization.
[UPDATE]
One term that you use in your question is SPA. In the traditional use case, all processing is being done by your application in the browser. This is a security nightmare. The browser will have access to the OAuth tokens used for authorization and identity which is not secure. This also limits your application's ability to generate Refresh Tokens which means the user will need to reauthenticate once the existing tokens expire (every 3,600 seconds). For the scope of this question, I recommend rethinking your app into a more traditional client/server design. Authentication is handled by your servers and not directly by (inside) the client application. In the sections where I mention service accounts, I am assuming that backend systems are in place so that the client only have an encrypted session cookie.
As per my experience,
G-Suite as Identity provide + Cloud IAP will work to authn and authz to do user level access checks on the frontend. refer this
However for backend application to application communication, I will recommend service accounts in GCP, refer this. You can also use Cloud IAP to do the same, refer this. However the choice depends on your use case and your companies security guidelines and policies.
I am just starting to use GCP and I have some questions about the service accounts.
Say there is a team of like 4 remotely located developers and we all want to use the python API to access GCP to launch instances and run stuff on them. My question is should every user get their own service account and keys or should one service account be shared by all? What is the intended use case here?
Google Cloud Service Accounts provide both identity and authorization to Google Cloud.
They are similar to user accounts. If you would like to do auditing or logging of actions with service accounts, you will want to use separate service accounts per user.
Service accounts are typically used for software applications to authorize their actions with the Google Cloud APIs. Service Accounts are using to issue OAuth 2.0 Access Tokens and optionally OIDC Identity Tokens. These tokens are what provides your application with authorization in Google Cloud.
My question is should every user get their own service account and
keys or should one service account be shared by all?
Yes, you should issue separate service account JSON key files to each developer. In the same way that you would not share usernames and passwords for computer systems, you would not share service accounts.
I have written a bunch of articles on Google Cloud Service Accounts that might help you understand how to configure and use them:
Google Cloud Service Accounts
At my company we want to start hosting our applications on Google Cloud Platform, so, I signed up, which asked me to create a Google Account, so, I used my business email address pablo.fernandez#example.com to do so. But now it looks like this is an organization-less account. When I try to sign up for Cloud Identity, so that we can have an organization and other users in the GCP account I get this error:
Does GCP require me to sign up with a temporary throway email so I can set it up correctly? At any point, how do I move forward from here?
Although Cloud identity is a separate service from G Suite, most probably the same rules apply when managing users: https://support.google.com/a/answer/7044710?hl=en
Before you add users to your organization's Google domain, you should check if they have a personal Google Account with the same email address that you plan to use for their managed Google Account. Two accounts can’t share the same email address. If they do, you have 2 options:
Option 1: Invite your users to transfer or rename their existing account (using a tool in the Google Admin console).
Option 2: Require users to rename their existing account.
Learn more about conflicting accounts.
I believe it is because ultimately they are all "google accounts" just that, G Suite and Cloud Identity accounts belong to an Organization.