I have seen many places in GCP documentation that service account based authentication is recommended over user account based. I couldn't find what is the actual reason behind it
Imagine that you have a service A running on compute A. You want service A to communicate with another service B running on compute B AND you want to use some form of protection (authorization) to only allow A and B to communicate and return errors for everything else.
If you use User Authentication, a person must be involved to authorize communication. Not practical for programs running on computers in the cloud.
Google implemented service accounts to provide authorization of machine to machine communication. The secrets are stored in a file. These secrets create a Token that is passed between services.
Related
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 have a java application that is deployed on GKE cluster. Let's call it the "orchestrator"
The application should be able to deploy other applications on same GCP project where the "orchestrator" app is running (can be same GKE or different GKE cluster), using helm cli commands.
We were able to do that using Google Service Account authentication, where the JSON key is provided to the "orchestrator" and we could use it to generate tokens.
My question is.. since both the "orchestrator" and the others apps are running on same GCP project (sometimes on same GKE cluster), is there a way to use some default credentials auto discovered by GCP, instead of generating and providing a Service Account JSON key to the "orchestrator" app?
That way, the customer won't need to expose this Key to our system and the authentication will be happened behind the scenes, without our app intervention.
Is there something a GCP admin can do which make this use case work seamlessly?
I will elaborate on my comment.
When you are using a Service Account, you have to use keys to authenticate - Each service account is associated with a public/private RSA key pair. As you are working on GKE cluster, did you consider using Workload identity, like mentioned in Best practices for using and managing SA?
According to Best practices for using and managing service accounts all non-human accounts should be represented by Service Account:
Service accounts represent non-human users. They're intended for scenarios where a workload, such as a custom application, needs to access resources or perform actions without end-user involvement.
So in general, whenever you want to provide some permissions to applications, you should use Service Account.
In Types of keys for service accounts you can find information, that all Service Accounts needs RSA pair key:
Each service account is associated with a public/private RSA key pair. The Service Account Credentials API uses this internal key pair to create short-lived service account credentials, and to sign blobs and JSON Web Tokens (JWTs). This key pair is known as the Google-managed key pair.
In addition, you can create multiple public/private RSA key pairs, known as user-managed key pairs, and use the private key to authenticate with Google APIs. This private key is known as a service account key.
You could also think about Workload Identity, but I am not sure if this would fulfill your needs as there are still many unknowns about your environment.
Just as additional information, there was something called Basic Authentication which could be an option for you, but due to security reasons it's not supported since GKE 1.19. This was mentioned in another stack case: We have discouraged Basic authentication in Google Kubernetes Engine (GKE).
To sum up:
Best Practice to provide permissions for non-human accounts is to use Service Account. Each service account requires a pair of RSA Keys and you can create multiple keys.
Good Practice is also to use Workload Identity if you have this option, but due to lack of details it is hard to determine if this would work in your scenario.
Additional links:
Authenticating to the Kubernetes API server
Use the Default Service Account to access the API server
One way to achieve that is to use use default credentials approach mentioned here :
Finding credentials automatically. Instead of exposing the SA key to our App, the GCP admin can attach the same SA to the GKE cluster resource (see attached screenshot), and the default credentials mechanism will use that SA credentials to get access the APIs and resources (depends on the SA roles and permissions).
I have recently made a program that listens to a PUB/SUB topic that is connected to a Gmail account. I have it all working fine. When a push notification arrives it will do different tasks based on the message content.
The problem is that I use a Service Account to connect to all the API's on Google Cloud Platform that I need. The Service Account allows access to ALL of our Gmail accounts in our organization. I need to somehow limit the access to a specific Gmail account.
The closest I could find to this issue was this question Impersonating list of users with Google Service Account. However, the only solution presented there was to turn my project into a marketplace app which I do not want to do.
I have tried setting up an Organizational Unit and trying to limit the scope to that somehow, but there seems to be know way (that I can find) to do it. I did try speak with Google Cloud Platform help but they didn't know the answer as it didn't quite fall under their area of expertise and referred me on to another help group, but I'm not eligible for them because I don't pay for support.
Edit: It doesn't actually appear that what I want to do is possible. I'll be going back to an OAuth2 method of authentication.
Understanding service accounts explains the possibilities:
Service accounts can be thought of as both a resource and as an identity.
When thinking of the service account as an identity, you can grant a role to a service account, allowing it to access a resource (such as a project).
When thinking of a service account as a resource, you can grant roles to other users to access or manage that service account.
Now try to fit that impracticable intent into there ...
If you need to limit the access of the service account to user-specific resources, this can only be done on the application level, not the system level - since a service account can impersonate just any user identity; eg. in order not to mess up the ownership, when uploading files on behalf of a user. If you want 1 user identity to access 1 user-specific resource, why even use a service account? And when using a service account, why not just impersonate as the correct identity? This could even be hard-coded, if it's only 1 user identity. But nevertheless, it can only be done on the application level - but cannot be configured for the service account itself.
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
For local development (including other team members) should we be using application default credentials for our apps, or service accounts when authenticating and using Google Cloud Platform services?
I was thinking that being able to control the individual user permissions instead of a random service account would be better, as it also prevents us from having to revoke the whole service account key if someone leaves the team. Whereas if we used ADC, it would just work as we'd disable their account and remove its permissions. However, the documentation in the Authentication overview contains this note:
Important: For almost all cases, whether you are developing locally or
in a production application, you should use service accounts, rather
than user accounts or API keys.
What is the correct authentication method to use for local development?
From the same page:
All GCP APIs support service accounts. For most server applications that need to communicate with GCP APIs, we recommend using service accounts, as they are the most widely-supported and flexible way to authenticate.
In this sense, the randomness of the service account is determined only on your way of managing it.
For your scenario, when someone leaves the team, it would indeed be easier to revoke the user account('s permissions), instead of revoking the key, affecting all using it. In my opinion, both ways are correct and the best way would be the one that best suits your context. The documentation pushes for service accounts as it is a Google account, as opposed to a specific user, and it can be used for authentication regardless of where your code runs.