I have a function app which is hosted in my GCP project with authentication turned on.
This app will be triggered from Jfrog container registry webhook based on events.
The issue I face here is to authenticate/authorize the HTTP request. I tried using "Authorization: bearer " header, which works good. But that token seems to expire after 60 minutes.
Q: Is there a permanent way(with no expiration) to authorize/authenticate cloud function HTTP requests ? Jfrog webhooks cannot programmatically create tokens since it's a simple HTTP POST trigger which can accept additional headers.
I am finding it hard to get a solution from GCP documentation. I do have the service account created with "roles/cloudfunctions.invoker" role.
Reference about Jfrog artifactory webhooks: https://www.jfrog.com/confluence/display/JFROG/Webhooks
It's for that reason I wrote that article. It's based on ESPv2 and Cloud Run, but API Gateway is the managed version of that technical stack. The principle and the OpenAPI spec is the same.
The solution downgrade the security level from a short lived token (1h) to long lived token (no limit). But you can use API Gateway to ensure the API Key check and query forward.
A much more simpler pattern is to remove the authentication check on Cloud Functions (and make it public) and to perform that API key (in fact a random string comparison) in your functions itself.
In both case, the API is publicly accessible (API Gateway, or Cloud Functions) and, in case of DDoS attack, nothing will protect your service (and your money). Set the correct Cloud Functions Max instance to prevent any bad surprise.
Related
I am trying to make a desktop application with Twitch API and Google API.
Since this application requires Twitch user permission, a user needs to authorize my application through twitch's OAuth and I think there's no way to omit this process.
Now, I want to add some functionalities from Goole APIs, for instance TTS.
My application will be installed and run on user's local machine,
it cannot store API key or credential information safely.
I think I have three options:
Add Google OAuth: This is most safe way, I think, but I don't think I can convince users to authorize another Google account even though they already authorized their Twitch account.
Make a kind of proxy server which verifies request for Google API using twitch authentication information and relays request to/response from Google API. This seems feasible but it requires additional payment to running server for sending data from Google API. I already have to pay for TTS service, another payment for proxy server which sends binary data frequently would be a financial burden for me.
Make a server to acquire API key for Google API. This also requires additional server, but it does not involve lots of traffic because application will access Google API directly once API key acquired. However, I concern that the API key may be easily stolen using monitoring tool such as wireshark.
Which method should I use here, and how can I improve it?
Or, is there better way for this case?
Largely, what I am trying to accomplish is explained in this video by Azure, which is the unsecured version of adding API keys to a REST API (specifically http://conferenceapi.azurewebsites.net/?format=json).
If you watch through the video, it seems great until you realize that anyone can call the "conferenceapi" as long as they know the url, essentially bypassing the entire purpose of Azure API Management which is controlling/metering peoples' access to an API.
My question is, if I'm trying to create the backend (so Spring Boot controllers) of my API Management service, what am I supposed to do in order to make sure that my REST api is only responding to requests made by API Management?
There is surprisingly little documentation on this that I could find:
Securing Backend Services behind Azure API Management
X.509 Authentication
How to secure back-end services using client certificate authentication in Azure API Management (literally only talks about how to upload a certificate and nothing about backend)
Like, a certificate sounds like a great idea. Only, how do I create the certificate, and how do I verify the certificate from a Spring Boot Application? Azure documentation feels so sparse, unless I didn't find the documentation that would address those questions.
Our current API use seesionID for the authentication. We plan to use Azure API management to manage our web api. However Azure web api management has their own authentication. How can we link those two together. Our customer can use the same logon information.
Conversations about authentication and identity in Azure API Management can get tricky because there can be three different identities and then there are the different contexts of runtime requests vs management requests. So, to be sure I'm answering the right question, let me try and get some terms defined.
The three identities:
API Provider: This is the Azure user who has created an API Management instance.
API Consumer: This is a developer who is writing some client software to consume the API.
End User: The user of the application written by the API Consumer and will be the one who actually initiates runtime requests to the API.
I am assuming that you are the API Provider. What I'm not sure about is whether your customers are the API Consumers or the End Users.
Azure API Management provides identity services for API Consumers. Consumers can either manually create a username/password account or use some social identity provider to create an account. They then can get a subscription key that will allow Azure API Management to associate requests to the API Consumer.
I think you are asking if you can connect the sessionID, which I am guessing you use to identify End Users, to a subscription key used to identify API Consumers. If that is correct, then the answer is no (except for the scenario described below), because we need to identify the API Consumer key before any policies are run to ensure we run the correct policies.
You can change our Api Consumer subscription key. So, if you only have a low quantity of customers/End Users you could create an Api Consumer account for each End User. However, you would only be able to map sessionID to API Consumer Subscription Key if sessionID was a constant value. I'm presuming based on the name, that value changes at each login.
Although Azure API Management provides identity services of API Consumers, it does not provide full identity management for End Users. We leave that to external partners like Azure AD, Thinktecture Identity Server and Auth0. I'm assuming that your existing system is already using some kind of identity provider to generate the sessionId. What you can do with Azure API Management is validate that sessionId using policies in the API Management Gateway. To do that we would need to know more about the format of the sessionId.
Sorry for the long post but it is a confusing topic and I wanted to be as clear as possible.
I am running a Kubernetes cluster hosted on GKE and would like to write an application (written in Go) that speaks to the Kubernetes API. My understanding is that I can either provide a client certificate, bearer token, or HTTP Basic Authentication in order to authenticate with the apiserver. I have already found the right spot to inject any of these into the Golang client library.
Unfortunately, the examples I ran across tend to reference to existing credentials stored in my personal kubeconfig file. This seems non-advisable from a security perspective and makes me believe that I should create a new client certificate / token / username-password pair in order to support easy revocation/removal of compromised accounts. However, I could not find a spot in the documentation actually describing how to go about this when running on managed Kubernetes in GKE. (There's this guide on creating new certificates explaining that the apiserver needs to get restarted with updated parameters eventually, something that to my understanding cannot be done in GKE.)
Are my security concerns for reusing my personal Kubernetes credentials in one (or potentially multiple) applications unjustified? If not, what's the right approach to generate a new set of credentials?
Thanks.
If your application is running inside the cluster, you can use Kubernetes Service Accounts to authenticate to the API server.
If this is outside of the cluster, things aren't as easy, and I suppose your concerns are justified. Right now, GKE does not allow additional custom identities beyond the one generated for your personal kubeconfig file.
Instead of using your credentials, you could grab a service account's token (inside a pod, read from /var/run/secrets/kubernetes.io/serviceaccount/token), and use that instead. It's a gross hack, and not a great general solution, but it might be slightly preferable to using your own personal credentials.
I am setting up an API for a mobile app (and down the line a website). I want to use oAuth 2.0 for authentication of the mobile client. To optimize my server setup, I wanted to setup an oAuth server (Lumen) separate from the API server (Laravel). Also, my db also lives on its own separate server.
My question is, if using separate servers and a package like lucadegasperi/oauth2-server-laravel do I need to have the package running on both server?
I am assuming this would be the case because the oAuth server will handle all of the authentication to get the access token and refresh access token functions. But then the API server will need to check the access token on protected endpoints.
Am I correct with the above assumptions? I have read so many different people recommending the oAuth server be separate from the API server, but I can't find any tutorials about how the multi-server dynamic works.
BONUS: I am migrating my DB from my API server, so I would assume I would need the oAuth packages migrations to be run from the API server also. Correct?