Our developers enabled certain APIs in their GCP project that are no longer needed.
I tried disabling Google Cloud Memorystore for Redis API (redis.googleapis.com) but got an error:
Error Disabling Api
[Not ready to deactivate the service on this project; ensure there are no more resources managed by this service.] with failed services [redis.googleapis.com]
Is there any way to list the resources currently managed by the API service so I can remove them and disable this API?
I am not aware of any API that will tell you which resources are under Service Usage. Some resources require more than one service to be enabled. I do not recommend disabling services once enabled. There is not a one-to-one relationship between an API and a resource (eg VM instance). Some resources need to access more than one API (VM instance/KMS/Cloud Storage). There are side effects such as disabling/deleting service accounts that may affect resources that you need. Instead, remove permissions (roles) to those services from users/service accounts.
The Google Cloud Console will show you which APIs are being used historically. Go to APIs & Services -> Dashboard. You will find a table of APIs being used, but not the resource using them.
The process of mapping API usage to Resources is a manual process. I would use Cloud Asset Inventory to manage my resources and not worry about APIs that are enabled.
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'm Trying to access maps using Maps JavaScript API at Google Cloud Platform.
I got error
You must enable Billing on the Google Cloud Project at
https://console.cloud.google.com/project/_/billing/enable Learn more at
Can we access Google API & Services without link Billing Account?
Yes it is necessary to enable billing to access Google API & Services.
Some Google APIs charge for usage, and you need to enable billing before you can start using these APIs. Enabling billing for the APIs that your projects use also has other advantages:
Some APIs allow free usage up to a courtesy usage limit, and in some cases this free limit is increased when you enable billing. For some APIs, more services are available after you enable billing.
Billing is enabled at the project level, not the API level. If you enable billing for a project, then every billable API in that project is billed, based on the project's usage. All usage in a project is billed using the payment method that you specify, and you can change to a different method at any time. You cannot selectively enable billing for some APIs but not others; when you enable billing for a project, it applies to all the APIs that you used within that project, even if the API is currently disabled. Refer APIs and billing for information.
NOTE : In order for you to use Maps API or Places API, you will have to create a new account under USD because Google Maps Platform services cannot be billed through the same billing account as Google Cloud Platform services. In order to continue using Google Maps Platform, all customers with a billing account in INR will need to create a new billing account for Maps and then migrate their existing Maps projects under this new account. You cannot get Google Map API without billing. Refer Google Maps Platform for information.
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
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.
One thing I dislike about Google Cloud Platform (GCP) is its less baked-in security model around roles/service accounts.
Running locally on my laptop, I need to use the service account's key specified in a JSON file. In AWS, I can just assume a role I have been granted access to assume (without needing to carry around a private key). Is there an analogue to this with GCP?
I am going to try and answer this. I have the AWS Security Specialty (8 AWS certifications) and I know AWS very well. I have been investing a lot of time this year mastering Google Cloud with a focus on authorization and security. I am also an MVP Security for Alibaba Cloud.
AWS has a focus on security and security features that I both admire and appreciate. However, unless you really spend the time to understand all the little details, it is easy to implement poor/broken security in AWS. I can also say the same about Google security. Google has excellent security built into Google Cloud Platform. Google just does it differently and also requires a lot of time to understand all the little features / details.
In AWS, you cannot just assume a role. You need an AWS Access Key first or be authenticated via a service role. Then you can call STS to assume a role. Both AWS and Google make this easy with AWS Access Keys / Google Service Accounts. Whereas AWS uses roles, Google uses roles/scopes. The end result is good in either platform.
Google authentication is based upon OAuth 2.0. AWS authentication is based upon Access Key / Secret Key. Both have their strengths and weaknesses. Both can be either easy to implement (if you understand them well) or a pain to get correct.
The major cloud providers (AWS, Azure, Alibaba, Google, IBM) are moving very fast with a constant stream of new features and services. Each one has strengths and weaknesses. Today, there is no platform that offers all the features of the others. AWS today is ahead both in features and market share. Google has a vast number of services that outnumber AWS and I don't know why this is overlooked. The other platforms are catching up quickly and today, you can implement enterprise class solutions and security with any of the cloud platforms.
Today, we would not choose only Microsoft or only Open Source for our application and server infrastructure. In 2019, we will not be chosing only AWS or only Google, etc. for our cloud infrastructure. We will mix and match the best services from each platform for our needs.
As described in the Getting Started with Authentication [1] page, for service accounts it is needed the key file in order to authenticate.
From [2]: You can authenticate to a Google Cloud Platform (GCP) API using service accounts or user accounts, and for APIs that don't require authentication, you can use API keys.
Service and user accounts needs the key file to authenticate. Taking this information into account, there is no manner to locally authenticate without using a key file.
Links:
[1] https://cloud.google.com/docs/authentication/getting-started
[2] https://cloud.google.com/docs/authentication/