After we created a new project in Google developer console, we see one App Engine service account and one Google APIs service account already there in "Permission" page. But we have no client Ids in credential. Those two accounts seems to be dummy, what are they for?
They are not exactly dummy.
Those are "service" accounts meant to be used if you want an application or utility/tool that is sitting inside/on your app engine VM or compute engine VM, to perform actions that will require authentication ... having service accounts should ideally let you can skip the oauth step which would otherwise require browser access and user intervention ... things that an automated process in a VM should not have to deal with.
I'm guessing they were provisioned automatically with ease of use (? shrug) in mind so folks wouldn't have to go about creating them.
https://cloud.google.com/compute/docs/faq#serviceaccounts
https://cloud.google.com/compute/docs/authentication
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 am trying to publish my Android app to our company's Play Store.
On Google API access page
I am trying to create new service account. It does not work.
You are missing at least one of the following required permissions:
Project
orgpolicy.policy.get resourcemanager.projects.get Check that the
folder, organization, and project IDs are valid and you have
permissions to access them
My GCP shows myname#github.com google account.
On the other side,Google API(Google Play Console) shows MYCOMPNAY Team account.
How to solve this IAM problem?
I'll do my best to answer but the question lacks some detail.
As the error describes, service accounts are a distinct type of credential used by Google that are intended to be used by software (rather than humans) for interacting with Google services. It makes some sense (though I'm unfamiliar with the Play process) that you'd need to use service accounts rather than human accounts with this service.
Unlike, regular (human) accounts (e.g. yourname#github.com), service accounts are owned by Google projects. When you create a service account, you'll need to scope the account to an existing Google project.
Google provides various Consoles for different services. I'm most familiar with Google Cloud Platform (GCP) and so I would create projects and service accounts using GCP's CLI (Cloud SDK aka gcloud) or https://console.cloud.google.com. Are you using something similar?
Unfortunately, I think, Google's tools scope projects (even though these are universal Google resources) to specific platforms (Cloud, Firebase, Apps etc.) and so you may not be able to see all your projects via the e.g. Cloud Console.
So....
If you have a Play (!?) Console, there should be a mechanism to list|create projects. If you haven't already, created a project to own your service account. Then the tool should provide a mechanism to create a service account. Do so under that projects. Lastly, you'll need to grant the service account permissions so that it can do what you need it to do (e.g. publish your app).
If you add more details to your question, I may be able to help.
NOTE One distinction between human (e.g. yourname#github.com as a Google account) and a service account is that human accounts using 3-legged OAuth while service accounts use 2-legged OAuth. This is because the service account is not able to interact with OAuth prompts as a human user would and it is often a good "tell" when you need to use a human vs. a service account.
See:
Google Play: (API) Projects and Service Accounts
Understanding Service Accounts
Using OAuth for Server-to-Server apps
I've been reading the Google Cloud documentation and can't exactly figure out what the difference between these two are. I know that both of them are automatically created in GCP, but I really don't know much more.
You aren't alone, and that's why google has started a new video series on this topic. To summarize,
The Google managed service account are account created on Google side (managed by Google, you can't delete them) but that you can grant on your project to allow them to perform actions. They are also named service agent. They are used when you used serverless product, such as Cloud Build for example, or Cloud Run (to pull the image, not to run the instance)
The default service account (mainly Compute Engine default service account and App Engine default service account) are service account created automatically in YOUR project (so managed by you, you can delete them if you want) when you activate some APIs. They are used by default when you create some service's instance.
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.
we have a cloud foundry demo installation for customers. Customers are able to create an account. Now, I would like t assign automatically a specific org and space incl. roles to every new user.
Is that possible?
You could create a web application that users go to create their account then use uaa apis and cloud controller apis to create and assign the user to whatever you want. This application can use uaa client accounts with appropriate authorities.
If you only want users to create their accounts using your application I believe you can tell uaa to disable self service links in the uaa ui using "login.self_service_links_enabled=false" and can probably stop people from creating their own accounts on the CLI by removing the "scim.write" scope from the cf client.
There's nothing out of the box that does this. I can't see anything in the events API that you could plug into either.