When employing the Remote API for Java for accessing another application's GAE datastore (as suggested here), do I have to use an admin password (as shown in sample code) or can I use service account credentials instead. Calls to the Remote API should originate in an App Engine Client, so non-password authentication seems to be the (only) sensible choice.
Of course you can! It's as simple as that: RemoteApiOptions.useServiceAccountCredential
PS: You'll have to create a service account and download the key first. You have to grant the "AppEngine Admin"-role to the service account.
Related
I followed the following documentation by Google to create ML engine and I deployed my online predicator there:
https://cloud.google.com/ml-engine/docs/scikit/quickstart
I know that it's possible to access to the engine by RESTful api as described in below:
https://cloud.google.com/ml-engine/docs/v1/predict-request#request-body
But I want all clients can access the API related to my model without OAuth or any type of authentication. How can I do this?
You can do this by granting modelUser role for that model to allUsers as follows:
gcloud ml-engine models add-iam-policy-binding mymodelname --member allUsers --role roles/ml.modelUser
You have to code your server to do that. You can have your server perform the API calls. Your clients simply access a frontend you designed to provide their parameters and your server makes the actual call. All the quota/charges would be with your API key, but the requests will be done with your Client's parameters.
For a project that I'm currently developing, I need to expose a servlet (hosted on Google App Engine) to a Java executable which is hosted on Google Compute Engine (in the same project). Such servlet performs some maintenance tasks, so it should never be triggered by non-authorized users. So, the goal is to authorize the requests coming from the Google Compute Engine instance that is running the JAR executable.
In the past I've solved the same issue by having the servlet exposed on HTTPS and rely on a "shared secret", known both to AppEngine application and to the JAR running on the Compute Engine instance. In that way, the instance calls the specific servlet (which is public), then the servlet verifies if the secret is correct, and if so, the request is allowed.
I don't like this approach. For sure we can do something better using challenge-response authentication or by using some other authentication procedure (probably via asymmetric crypto signing). However, this is not what I want to do.
My preferred way of acheiving the same result would be by using the Compute Engine Default Service Account. I am pretty sure there is a way of creating a HTTP POST request on the compute engine and authenticate that via the default service account key. Then, on the servlet, I would rely on the UserService to check whether the request is coming from the ComputeEngine default service account, and if so, I would accept that.
However, I have not seen any documentation or code example that explains how to do that. I suspect there might be possible to perform an authenticated HTTPRequest using the default Compute Engine Service Sccount (maybe adding the Bearer JWT token as Authorization header?).
Has anyone tried something like that?
You have several options; OAuth is likely your best bet.
I have a rest API hosted in Google App Engine. (API lives in a Docker container in the Flexible environment).
I need to support only internal API calls (from another service in the same App Engine Project) and for developer testing be able to call it directly (I don't want user authentication, but I should be able to access it still using the application_default_credentials...I'm just unsure how)
Can you direct me to documentation or examples of how to set this up?
The Google documentation is very lacking.
You have several options, including the following:
The App Engine documentation states that the recommended approach is OAuth for microservices that require authentication.
A second option is to use Cloud Endpoints with service account authentication.
Third, you can use Identity-Aware Proxy to secure the server. Clients can get an identity token from the metadata server.
In the Developer Console UI I cannot edit data as expected with this 'can view' user. However I am able to write to datastore by connecting to our Remote API Servlet on App Engine. From what I can tell, you can only apply an admin security constraint to servlets on App Engine but this still opens it up to all members of the project wether they are an owner, can write or can view. And then I'm guessing the Remote Api uses the default app engine service account which has write permissions.
Is there any way to completely lock an account down to be read only if you also want to use the Google Remote API? Is this not considered a flaw with the Remote API?
This is intended behaviour. Any administrator of the app - no matter in what role - can access the app using the remote api. Remote API does not use the default service account, it is merely a bridge to the datastore API that is tunneled over HTTP.
If you want to lock down to read for a given user, build your own REST Api that provides readonly access.
I've got a google spreadsheet owned by a GAE service account and I want my GAE Python app to update a cell in one of the rows.
Based on some reading, these are my findings:
the spreadsheets service is old-school. It's a Google Data API and most Google services are now on the Google API platform. For Google API services, one can use a service account to do two-legged oauth2 access, but not for Google Data API services. Oh, it seems one can do two-legged oauth on Google Data API services, but only if the app is on a Google Apps domain (which mine isn't)
I could implement a similar effect (i.e. a user of the app can use data in my spreadsheet and doesn't need to login or authorize in any way) by using my personal account. There's a complicated way that involves me to authorize the app once, store the token and reuse it when a user uses the app. There's another way, which is to use client login (i.e. I embed my personal login and password in the code and use it to authorize the app to access the data in my spreadsheet)
This latter approach seems fairly safe as well, but of course I must be very careful that my source code will not be exposed. The authorization is between the GAE app and the Google Data Spreadsheets API, so the actual user's machine is not involved at all.
My spreadsheet is owned by the service account and shared with my personal account.
Note that my app is also using the Google Drive API (to access some personal Drive files, also shared between me and the GAE service account), so for that it will authorize using the service account.
Can someone confirm that my findings are correct and this approach is sound?
You can use gdata.spreadsheets.client (Google Data API) on the OAuth2 (Google API platform) flow.
https://github.com/HatsuneMiku/googleDriveAccess
It uses 'oauth2client-gdata-bridge'.