英文:
How to authenticate google cloud function for HTTP trigger?
问题
我有一个函数应用程序，它托管在我的GCP项目中，并启用了身份验证。
这个应用程序将根据事件从Jfrog容器注册表webhook触发。
我在这里遇到的问题是如何对HTTP请求进行身份验证/授权。我尝试使用"Authorization: bearer <身份令牌>"头部，这个方法效果不错。但是那个令牌似乎在60分钟后过期。
问题：有没有一种永久的方式（没有过期时间）来授权/验证云函数的HTTP请求？Jfrog webhooks无法以编程方式创建令牌，因为它是一个简单的HTTP POST触发器，可以接受附加的头部。
我在GCP文档中很难找到解决方案。我已经创建了具有"roles/cloudfunctions.invoker"角色的服务帐号。
关于Jfrog artifactory webhooks的参考链接：https://www.jfrog.com/confluence/display/JFROG/Webhooks
英文:
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 <identity token>" 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
答案1
得分: 1
这是我写那篇文章的原因。它基于ESPv2和Cloud Run，但API Gateway是该技术栈的托管版本。原则和OpenAPI规范是相同的。
该解决方案将安全级别从短期令牌（1小时）降级为长期令牌（无限制）。但是，您可以使用API Gateway来确保API密钥检查和查询转发。
一个更简单的模式是在Cloud Functions上删除身份验证检查（使其公开），并在函数本身中执行API密钥（实际上是随机字符串比较）。
在这两种情况下，API都是公开可访问的（API Gateway或Cloud Functions），在遭受DDoS攻击时，没有任何东西可以保护您的服务（和您的资金）。设置正确的Cloud Functions最大实例数以防止任何不好的意外。
英文:
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.
通过集体智慧和协作来改善编程学习和解决问题的方式。致力于成为全球开发者共同参与的知识库，让每个人都能够通过互相帮助和分享经验来进步。
评论