CLOUD_SDK_CREDENTIALS_WARNING我们建议大多数服务器应用程序改用服务帐户 [英] CLOUD_SDK_CREDENTIALS_WARNING We recommend that most server applications use service accounts instead
问题描述
上下文:我刚刚学习了从FireStore仪表板获取(下载)数据的技巧.显然，只要在浏览器上打开Google信息中心，然后凭我的眼神去拥有Google Dasboard，就会容易得多.但是，出于个人原因，在我公司中，操作员无法查看第三个仪表板.他们只能看到内部仪表板.我正在尝试一些解决方法，可以获取/下载用于填充仪表板的相同数据，并将其导入到基于Dynatrace/ELK的内部解决方案中.
Context: I have just learn a trick to get (download) data from FireStore Dashboard. Obviouslly, it is much easier just open Google Dashboard on Browser and see with my eyes to own Google Dasboard. Nevertheless, for personal reasons, in my company the operators can't look at a third Dashboard. They only can see internal Dashboards. I am trying some workaround where I can get/download the same data used for fill in Dashboard and imported it to our internal solution based on Dynatrace/ELK.
出于学习目的，为了下载Google Dashboard数据，我遵循以下步骤:
For learning purposes, in order to download Google Dashboard data I followed:
1-使用gcloud获取ACCESS_TOKEN
1 - Get a ACCESS_TOKEN using gcloud
C:\Program Files (x86)\Google\Cloud SDK>gcloud auth application-default print-access-token
C:\Program Files (x86)\Google\Cloud SDK\google-cloud-sdk\bin\..\lib\third_party\google\auth\_default.py:69: UserWarning: Your application has authenticated using end user credentials from Google Cloud SDK. We recommend that most server applications use service accounts instead. If your application continues to use end user credentials from Cloud SDK, you might receive a "quota exceeded" or "API not enabled" error. For more information about service accounts, see https://cloud.google.com/docs/authentication/
warnings.warn(_CLOUD_SDK_CREDENTIALS_WARNING)
ya29. ... ACCESS-TOKEN ...7hu
2-使用上面的ACCESS_TOKEN获取Dashboard数据，例如:
2 - using the above ACCESS_TOKEN to get Dashboard data like:
curl --location --request GET 'https://monitoring.googleapis.com/v3/projects/firetestjimis/timeSeries?filter=metric.type%20%3D%20%22firestore.googleapis.com%2Fdocument%2Fread_count%22&interval.endTime=2020-05-07T15:01:23.045123456Z&interval.startTime=2020-05-05T15:01:23.045123456Z' --header 'Authorization: Bearer ya29...ACCESS-TOKEN 7hu'
显然，这只是一个示例，说明如何获取满足过滤条件的锥体.我可以继续根据 Google Cloud Metrics 来调整API和过滤器和 Google Cloud API v3
Obviously this is just an example how to get how many conections satisfied the filter criteria. I can keep searching adjusting the API and filters according to Google Cloud Metrics and Google Cloud API v3
这次从API版本1获取Dashboard元数据的另一个示例是
Other example of getting Dashboard metada this time from API version 1 is
curl --location --request GET 'https://monitoring.googleapis.com/v1/projects/firetestjimis/dashboards' --header 'Authorization: Bearer ya29... ACCESS-TOKEN ...7hu'
从gcloud获取访问令牌时的警告鼓励您参阅身份验证指南和我做到了.好吧，它既没有解释如何解决此警告，也没有解释为什么如果您的应用程序继续使用Cloud SDK中的最终用户凭据，您可能会收到超出配额"或未启用API"错误".我可以看到从仪表板获取数据的技巧正在起作用，但似乎我正在依靠一种奇怪的方式来获取ACCESS-TOKEN.
The warning when getting the ACCESS-TOKEN from gcloud encourage to see Authentication guidance and I did it. Well, it doens't explain how to fix this warning neither why "If your application continues to use end user credentials from Cloud SDK, you might receive a "quota exceeded" or "API not enabled" error". I can see my trick to get data from Dashboard is working but it seems I am relying on strange way to get a ACCESS-TOKEN.
所以我的直接问题是:手动获取ACCESS-TOKEN并将其用于curl/postman以避免这种警告的适当步骤是什么?
So my straight question is: what is the appropriate steps to get manually an ACCESS-TOKEN and use it in curl/postman avoiding such warnning?
在我看来，基于此 stackoverflow答案的根本原因是"...此错误消息表示您使用的是用户帐户，而不是服务帐户..."那么如何解决呢?我必须创建一个服务帐户吗?如果是这样，怎么办?在此可接受答案的结尾，我读到"...使用真实的应用程序默认值，您可以使用gcloud auth应用程序-默认登录名..."，这正是我使用gcloud记录的方式:运行gcloud auth应用程序-默认登录名，打开Google SingleSignOn时，我选择的电子邮件与我在Firebase帐户中注册的用户相同.答案还提到"...关联特定服务帐户的方法是gcloud auth activate-service-account --key-file...."我想尝试一下，但是他/她在说哪个密钥文件大约吗?
It seems to me that, based on this stackoverflow answer the root cause is "... This error message means you're using a User account, and not a service account..." So how can I fix it? Do I have to create a service account? If so, how? At the end of this accepted answer I read "... to use the true application default you can use gcloud auth application-default login..." And it is exactly how I am logging with gcloud: run gcloud auth application-default login, when open Google SingleSignOn I pick my email which is the the same user I registered in Firebase account. The answer also mentioned "... method to associate a specific service account is gcloud auth activate-service-account --key-file ...." I want give a try on it but which key-file is he/she talking about?
在适当的情况下，就我而言，我仅在Firebase项目下使用FireStore(除FireStore外，我不使用其他任何东西).
In case it is relevant, in my case I am only using FireStore under Firebase project (I am not using anything else other than FireStore).
***在约翰回答后编辑
*** EDITED after John's answer
我们即将将该项目投入生产.
We are moving soon this project to production.
1-我们的移动应用程序会通过将其发布到我们的内部Microserve中来创建汇款.这样的发布请求将返回从我们内部的NodeJs服务器生成的CustomToken.
1 - Our Mobile App will create money transfer by posting it to our internal microserve. Such post request will return a CustomToken generated from our internal NodeJs server.
2-我们的内部微服务会将此类传输复制到Firestore，并相应地更新其在Firestore上的状态.
2 - Our internal microservice will replicate such transfer to Firestore and update its state on Firestore accordingly.
3-代替我们的Mobilie App民意调查或监听我们的内部微服务获取状态，它会监听Firestore以从相应文档中获取状态.为了进行监听，它将使用步骤1中从帖子返回的CustomToken.我们公司仅希望利用Google Firestore的Real Time Database功能来进行此项目(反应性方法).
3 - Instead of our Mobilie App poll or listen our internal microservice to get the status it will listen to Firestore for getting the status from respective document. In order to listen, it will use the CustomToken returned from post in step 1. Our company wants just take advantage of Real Time Database feature from Google Firestore for this project (reactive approach).
将我的陈述与"Google在大多数情况下都希望您使用服务帐户授权"相提并论时，您是否考虑到任何考虑因素?
Do you see any consideration when compared what I am doing with your statement: "Google prefers in most cases that you authorize using a service account"?
CustomToken是使用此NodeJs服务器在内部创建的，并且取决于从固定用户
The CustomToken is created internally with this NodeJs server and depending on uid extrated from antenticated user authentication/users from Google Firebase:
const admin = require('firebase-admin');
exports.serviceAccount = {
"type": "service_account",
"project_id": "firetestjimis",
"private_key_id": "ecfc6 ... fd05923",
"private_key": "-----BEGIN PRIVATE KEY-----\nMIIE .... 5EKvQ==\n-----END PRIVATE KEY-----\n",
"client_email": "firebase-adminsdk-fg6p9@firetestjimis.iam.gserviceaccount.com",
"client_id": "102422819688924138150",
"auth_uri": "https://accounts.google.com/o/oauth2/auth",
"token_uri": "https://oauth2.googleapis.com/token",
"auth_provider_x509_cert_url": "https://www.googleapis.com/oauth2/v1/certs",
"client_x509_cert_url": "https://www.googleapis.com/robot/v1/metadata/x509/firebase-adminsdk-fg6p9%40firetestjimis.iam.gserviceaccount.com"
}
admin.initializeApp({
credential: admin.credential.cert(exports.serviceAccount)
});
var uid = "NS .... Ro2"; //copied from https://console.firebase.google.com/project/firetestjimis/authentication/users
var claim = {
control: true
};
admin.auth().createCustomToken(uid)
.then(function (customToken) {
console.log(customToken)
})
.catch(function (error) {
console.log("Error creating custom token:", error);
});
我们的移动设备(例如Angular中的示例，但IOS和Android的想法相同)具有我这样下载的SERVICE_ACCOUNT_JSON_FILE:
Our mobile (example in Angular but same idea for IOS and Android) has the SERVICE_ACCOUNT_JSON_FILE I downloaded like this:
environment.ts:
environment.ts:
export const environment = {
production: false,
firebaseConfig: {
apiKey: "AIzaSy ... 3DCGihK3xs",
authDomain: "firetestjimis.firebaseapp.com",
databaseURL: "https://firetestjimis.firebaseio.com",
projectId: "firetestjimis",
storageBucket: "firetestjimis.appspot.com",
messagingSenderId: "795318872350",
appId: "1:7953 ... 32b26fb53dc810f"
}
};
app.component.ts
app.component.ts
public transfers: Observable<any[]>;
transferCollectionRef: AngularFirestoreCollection<any>;
constructor(public auth: AngularFireAuth, public db: AngularFirestore) {
this.listenSingleTransferWithToken();
}
async listenSingleTransferWithToken() {
await this.auth.signInWithCustomToken("eyJh ### CUSTOMTOKEN GENERATED FROM INTERNAL NODEJS SERVER ABOVE ### CVg");
this.transferCollectionRef = this.db.collection<any>('transfer', ref => ref.where("id", "==", "1"));
this.transfers = this.transferCollectionRef.snapshotChanges().map(actions => {
return actions.map(action => {
const data = action.payload.doc.data();
const id = action.payload.doc.id;
return { id, ...data };
});
});
}
}
我了解到，CustomToken的创建及其在我们的移动设备中的使用完全依赖于服务帐户.我对吗?我是否错过了一些概念，并且在后台使用了USER CREDENTIAL，并且在DEV环境中正常工作的某些东西在生产时会突然弹出?显然，此问题全部来自我的免费帐户，但在生产中将支付给帐户，但此处的代码和步骤将完全相同.
I understand that both CustomToken creation and its use from our Mobile is relying entirely on Service Account. Am I right? Did I miss some concept and I am using USER CREDENTIAL behind the scene and something that works properly in DEV environment will pop up some surprise when in production? Obviously for this question all comes from my free accoutn but in production it will be paid account but the code and steps will be exactly the same here.
推荐答案
CLI使用两种类型的凭据:
There are two types of credentials used by the CLI:
- 用户凭证
- 服务帐户
在大多数情况下，Google都希望您使用服务帐户进行授权.但是，某些服务需要用户凭据(通常是非Google Cloud Platform服务).请查阅所使用的每种服务的文档.
Google prefers in most cases that you authorize using a service account. However, some services require user credentials (usually non-Google Cloud Platform services). Consult the documentation for each service that you use.
执行以下命令.这将显示您正在使用的凭据:
Execute the following command. This will show the credentials you are using:
gcloud auth list
要将CLI配置为使用服务帐户，请执行以下命令:
To configure the CLI to use a service account, execute this command:
gcloud auth activate-service-account <SERVICE_ACCOUNT_EMAIL_ADDRESS> --key-file=<SERVICE_ACCOUNT_JSON_FILE>
我写了一篇文章，对它进行了更详细的解释(以及有关服务帐户，授权等的其他几篇文章):
I wrote an article that explains in more detail (and several additional articles on services accounts, authorization, etc.):
Google Cloud –设置Gcloud带有服务帐户凭据
这篇关于CLOUD_SDK_CREDENTIALS_WARNING我们建议大多数服务器应用程序改用服务帐户的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
