My goal is to run a google app engine application with the minimal amount of access to resources it needs. In my case the application will access the datastorage in the project (this is the golang example tutorial using the source code git checkout origin/part4-usingdatastore from https://github.com/GoogleCloudPlatform/appengine-guestbook-go.git)
I did the following
Create a new project, foobarproject3
Created a new app in the project (using golang)
In the project IAM/IAM noticed the
foobarproject3#appspot.gserviceaccount.com, assumed this is the service account, so changed it's role to just BigQuery User. Notice that no Datastorage roles are configured (The UI forces me to provide access to something so I chose BQ)
Followed the tutorial instructions for the using datastore golang app (guestbook application)and deployed the app.
Opened the link to my app: https://foobarproject3.appspot.com/ It failed (this is great, this is what I expected, since the service account does not give the app permissions to read/write datastorage)
Refreshed https://foobarproject3.appspot.com/ and it started to work
There is something basic that I'm not understanding about service account from app engine. Isn't the app engine using these service account to access project resources? Why is the app getting access to datastorage when the service account does not have a policy that would allow access to datastorage?
"My goal is to run a google app engine application with the minimal amount of access to resources it needs."
This is dicey to unpack without more context. What is it that you're trying to achieve that goes beyond App Engine's default behavior?
My experience is that if one starts changing roles without understanding the basics, things go sideways (or South, or West, or Pear-shaped, depending on where you are). So I suspect you shot yourself in the foot in your third bullet.
When you access your app from the browser you are using your own user credentials, not the app's service account. And your user credentials might be exactly the app owner/admin ones, if you created the app using those credentials. See, for example, app.yaml handler login: admin option not effective on standard env python GAE app?
Make sure you log out from the app, or try accessing the app from an incognito browser window or by using a dumb(er) utility to prevent accidental/undesired credential leaking.
The app's service account is for your app to identify itself when it's interacting with other services/apps. From Understanding Service Accounts:
A service account is a special type of Google account that belongs to
your application or a virtual machine (VM), instead of to an
individual end user. Your application assumes the identity of the
service account to call Google APIs, so that the users aren't
directly involved. A service account can have zero or more pairs of
service account keys, which are used to authenticate to Google.
Related
How to restrict access to GAE Flexible site only for all account from my domain in GSuite and eventually other Google accounts that I provide explicitely. AFAIR there where something simillar in Standard GAE version in app.yaml handlers section.
So my scenario:
prodution versions restricted until go-live
dev and stage version restricted permanently
I would like to do this on the IAM level, to reject traffic to the site. But I didn't found anything in docs.
Ok, after rethink the problem and dig deeper in a documentation I found a page about dev environment - https://cloud.google.com/appengine/docs/standard/python/creating-separate-dev-environments.
So my current solution is not to have separate versions like dev, stage and prod and work with them within one project, but to create separate projects for each of environment.
It will also simplify management of DBs - previous I thought about different database in one DB server for particular environment. Now I will have a separate DB instance for it.
Anyway I still have a problem with securing access.
I did it in the same way like in Restrict App Engine access to G Suite accounts on custom domain:
changed Google Authentication to my Google Suite domain
added Custom Domain in my app
added my page domain to my GSuite as a second domain
And I still can connect to my page without auth - even in "Incognito mode" and on others computers and mobiles.
EDIT:
As a workaround I used Django-lockdown module. For the timebeing is more than enough - I have a password, I have a session, I can set it in Middleware or as a decorator for urls.
EDIT 2:
I noticed today a new feature in GAE Flexible - Identity-Aware Proxy.
This is the feature, that I was searching. You can restrict accces by:
Google Account email: user#gmail.com
Google Group: admins#googlegroups.com
Service account: server#example.gserviceaccount.com
Google Apps domain: example.com
I believe there is an undocumented Google API available to create and manage Google Cloud Console (and App Engine) projects on behalf of third party users.
Does anyone know how to use it?
I think older versions of the Google Eclipse Plugin obtained an OAuth2 token in the (undocumented) scope https://www.googleapis.com/auth/appengine.admin, and this allowed it to generate a Cloud Console project on your behalf. The latest version doesn't seem to do this. App Engine's own appcfg.py also uses this scope, but doesn't seem to do much more than deploy the code - I'm looking to change core settings for the project, such as Name, Redirect URLs, and Web Origins.
Any information would be appreciated.
I maintain a WordPress plugin providing secure Google Apps Login for end users, and currently have to give detailed instructions to admins for creating a new Cloud Console project manually, and entering settings such as Redirect URL. Ideally, I would create a simple on-line service to do all of this for them.
Thank you!
It is possible to programmatically create a new Developer Console project on behalf of a Google Account (yes, you read that right). You do so in a very roundabout way:
Request the https://www.googleapis.com/auth/drive.scripts scope from the user (standard OAuth 2.0 flow).
Use the Drive API's drive.insert method to create a new file with a mimetype of application/vnd.google-apps.script.
Somehow try to get the project ID, maybe by uploading some Apps Script code? This is the part that I was never able to figure out.
A little known fact is that every Google Apps Script project has a hidden Developer Console project associated with it. This project is not shown in the list of projects, but it does exist. It is created automatically when the user starts a new Apps Script project, and the drive.insert method is enough to cause this to happen.
How do you get to the hidden project? Well, the only way I know of is to open the Apps Script project from the Drive website, open the "Resources > Advanced Google Services" dialog, and click the link to the Developer Console. You'll find the project ID in the URL.
Aside from not being shown in your list of projects and not being able to use App Engine, this is a normal Developer Console project. You can add additional OAuth client credentials, service accounts, Compute Engine instances, etc. And of course once you have a project ID, all of the various management APIs will work: creating new virtual machines, making use of a service account's impersonation ability, etc.
I have a Google App Engine web app that runs the majority of my site. However, for certain functions, I need a linux machine. I would like my Google App Engine app to automatically spin-up a Google Compute Instance on certain events.
I understand that you can add Google Compute instances using the Compute Engine REST API. However, in order to access the Google Compute REST API, you need to get an access token using the OAuth2 authentication process.
How can I programmatically get an access token from within Google App Engine?
It seems that all of the authentication methods require a window to appear so you can type in your username and password, which is impractical from within Google App Engine.
Here is a complete example of using service accounts and App Engine cron tasks to stop instances after they've been running for a while:
(opposite of starting instances, but the authorization code will be the same)
https://github.com/GoogleCloudPlatform/compute-appengine-timeout-python
AppAssertionCredentials handles the access token using this code:
# Obtain App Engine AppAssertion credentials and authorize HTTP connection.
# https://developers.google.com/appengine/docs/python/appidentity/overview
credentials = AppAssertionCredentials(
scope='https://www.googleapis.com/auth/compute')
HTTP = credentials.authorize(httplib2.Http(memcache))
# Build object for the 'v1beta15' version of the GCE API.
# https://developers.google.com/compute/docs/reference/v1beta13/
compute = build('compute', 'v1beta15', http=HTTP)
You should be able to use the service account associated with your project to authenticate to the Compute Engine API and launch VMs.
Documentation on service accounts suggests that the following python code should fetch a service account token.
import httplib2
import discovery
from oauth2client.appengine import AppAssertionCredentials
...
credentials = AppAssertionCredentials(
scope='https://www.googleapis.com/auth/compute')
auth_http = credentials.authorize(httplib2.Http())
compute_service = discovery.build('compute', 'v1beta15', http=auth_http)
I'd thought that the Google I/O demo from this year where they built a video-sharing site was going to be available, but I don't see it on GitHub yet. There are a number of demos that use AppEngine to control GCE, but most of them seem to use the user's project and credentials, rather the app's own credentials.
Obviously, you probably don't want to spin up a VM on direct user input unless you've got a very large budget or some form of rate limiting in place, but it's quite helpful to spin up a VM now and then when you've got a lot of computation to do. (Transcoding, etc.)
I have a GAE application with a database of users.
When one of the user tries to download, say, file myapplication.appspot.com/somefile.jpg, I would:
check on the GAE database whether he is allowed to
if he is allowed, redirect him to a cloud storage bucket of mine from where he can download somefile.jpg
if he is not allowed, return him a 404 error code, and do some magic so that directly trying to download somefile.jpg from the cloud storage bucket does not complete.
Now what’s unclear to me is how to control access to somefile.jpg. How can I restrict the download to this scope of users?
PS: using something else than Google Storage is not an option (for those of you guys who thought about blobstore).
You don't need to restrict access on a per user basic you can restrict access on a per application (Google App Engine App) basis.
Every application has a service account, what you can do is set an ACL on the bucket to allow access to the application service account.
Now all you need to write an handler that would access Google Storage and return the data to the user.
As Shay noted, every App Engine application automatically has associated with it an internal account, called the “service account”. Normally, the service account name follows the pattern “your-app-id#appspot.gserviceaccount.com”, however, you can confirm the exact name by visiting the App Engine Administration Console, then clicking on your app name, followed by the “Application Settings” link, at which point you should see your service account name.
Once you find your service account name, add it to the “Team” subpage on the APIs console with “Can edit” permissions. This is even easier than updating the bucket ACL because you don't have to change any ACLs, however, bear in mind this applies to all buckets in your project. If you'd like to restrict your app to only have access to a subset of the buckets owned by your project then you'll want to update the per-bucket ACL(s), as Shay proposed.
I am still trying to wrap my mind around the workings of OAuth/OpenID, as such...
I am developing an "installed app" that will run on computers and iPhone. A given user may install the client app on multiple machines, and all of the user's installed clients will synchronize via a centralized Google App Engine service. The GAE service will also allow multiple users to collaborate on the data produced by the installed app, via a web app.
I don't want to roll my own authentication system, for my own ease and also to spare users from yet another set of credentials. As such I was initially thinking of using Google's clientlogin service, but then I thought OAuth/OpenID would be better because it would allow users to use not just Google credentials but also credentials from the other OpenID providers. Also, avoiding asking the user for a login/password seems more secure.
My question is... I'm not sure if this is the right use case for OAuth/OpenID. I am not accessing data from any other service, I am just looking for an authentication solution. Also, how difficult is this scenario to accomplish using Google App Engine (java)?
Any advice and/or starting points would be much appreciated!
My question is... I'm not sure if this is the right use case for OAuth/OpenID.
The "use case" for oAuth is: App X requires access to App Y. App X "asks" permission for access to App Y through your credentials. App X received an "authorized access token".
In your case, assuming I understood correctly, you could have the App on GAE implement an OpenID consumer and have your mobile app access the GAE app through oAuth.
In other words, your approach seems like a sensible one.