If I need to store API keys, passwords, or other sensitive information for a Google App Engine app running in the standard environment to access (let's say in order to access third-party services), what are my best options for doing so?
I've heard good things about KMS
https://cloud.google.com/kms/
Easily Encrypt Secrets
Wrap secrets up to 64KiB in size, to allow you
to protect secrets like user credentials and API tokens. Take
plaintext secrets out of source code, deployment managers, containers,
and metadata, and make these accessible to users as well as service
accounts via decryption using the Cloud KMS API.
Related
I'm building an app that uses a sensitive scope (https://developers.google.com/identity/protocols/googlescopes). Google requires the oauth server to be owned by me. This requirement restricts a huge swath of plug-in's, hosted apps (like amazon lambda or heroku) from using sensitive scopes. IMO, This reduces developer efficiency, reduces app options for users and is an unnecessary overhead since the user is already providing their credentials irrespective of the domain to access the application.
Why does Google Oauth restrict apps to use self-owned domains?
Even if the users are authenticated, the App still needs Authorization. As you can see in the documentation:
Verification is the process of proving that you own the property that
you claim to own. We need to confirm ownership because once you are
verified for a property, you have access to its Google Search data,
and can affect its presence on Google Search. Every Search Console
property requires at least one verified owner.
You can suggest changes to Google in Issue Tracker.
I have successfully configured qn Azure AD App Registration, allowing a client_credentials based OAuth 2.0 flow to work. This allows a third party application to access Microsoft Graph API. The app has "Calendar.Read" permission. Meaning the app can pretty much read any of the calendars (including CEO's).
I now have a conversation with security. What is out there in the Microsoft world, that I can use to lock down usage of API access via this Application Permission? Is there ability to do things like:
Restrict IP ranges the App can be accessed from?
Restrict users that can access the App? (However in Client_credentials, there is no user context)
Log traffic / activity happening via the App?
The only thing i can think of now is to say the Redirect URL configuration on the app means, no other application can get an access token using the Client_credentials, even if the application id & passkey get compromised
Any advice on further security controls that can be put in place?
Restricting access: You would need to do this in your application. The Client Credential flow doesn't allow for restricting what users as you point out. However there is nothing stopping you from adding user authentication to your application, possibly using a delegated graph auth flow to determine who they are.
IP Ranges: This is not possible currently.
Logging Traffic: This is not possible on the graph side currently, however you could/should log traffic on your applications side.
Redirect urls will not help you because they are not used int eh client credential flow.
In general application only auth (client credential flow) + a broad authorization scope is very powerful, but must be managed correctly. You don't inadvertently want to build a totally new users/permissions model over the top of the graph :)
There are very few options available currently available to offer these controls at token issuance (in Azure AD) or at API access (in Microsoft Graph). However, you can achieve similar results by carefully managing access to the app's credentials. Here are a couple steps you can take (not exhaustive):
App credentials: keep them secret, keep them safe
Use Key Vault. You can configure many of the restrictions you mention for access to data in Key Vault, including IP ranges and which users access. Key Vault also offers auditing of access to secrets. Don't forget to also be careful about which users have management access to the Key Vault (e.g. other users with access to the same Azure subscription).
Use certificates (public/private key pair), rather than client secrets (passwords), to authenticate the app. People tend to manage certificates much more carefully than they manage shared passwords, and developers are much less likely to hard-code the secret into scripts/code.
Be careful and deliberate about which users can manage the app's credentials
This is often overlooked. A user (or another app) who can access existing credentials, or add a new authorized credential to an app can act as the app and (mis)use all the permissions the app has been granted. This includes:
Users (and apps) in the "Company Administrator", "Application Administrator" and "Cloud Application Administrator" directory roles.
Users who are set as owners of the app registration (Application object) and enterprise app (ServicePrincipal object) for the app.
Users (or systems) who have access to the server or service the application resides on (which will have, or have access to, the credentials).
For all of these cases, ensure this is the smallest possible number of users, and they actually have a legitimate need. For users who do need access, wherever possible enforce just-in-time, time-limited access (not persistent access), such as with Azure AD Privileged Identity Management, for time-bound, just-in-time access for Azure AD directory roles and Azure resources.
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.
(intro)
I am new to Google Cloud Endpoints and I have started to build some HTTP REST services.
The purpose of those services is to be consumed directly by the users of my application (Business to Consumer - not business to business).
(The question)
I need to secure my services in a way to have only registered users being able to retrieve sensible data (and after login). My main purpose is to have the list of registered users saved in my database on CloudSQL (Dont want to use FB of Google Accounts). I was not able to find particular information about this point in the official Google documentation regarding authentication.
Can anyone advise me of the way to proceed and suggest some tutorials?
Thank you in advance.
The Endpoints proxy can validate JWTs, and we provide a couple of alternatives for creating those. Both Auth0 and Firebase have good user management capabilities and client-side libraries for generating JWTs. Both allow you to choose an identity provider (like FB or Google) or simply use username/password.
Check out the documentation here.
If you don't want to use Auth0 or Firebase Authentication, you can sign JWTs yourself with a private key and just give the proxy the URL of the Public Key (see the "Custom" tab on that same documentation page).
As far as looking up individual users in the database, you would have to do that part on your own.
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'.