数据集成数据工程数据分析【免费下载链接】cloudqueryData pipelines for cloud config and security data. Build cloud asset inventory, CSPM, FinOps, and vulnerability management solutions. Extract from AWS, Azure, GCP, and 70 cloud and SaaS sources.项目地址https://gitcode.com/gh_mirrors/cl/cloudquery点击查看免费下载本指南以 CloudQuery 仓库中 BigQuery 目标插件plugins/destination/bigquery的认证文档为主线系统讲解插件如何基于 Google Cloud 的 Application Default CredentialsADC机制完成身份认证覆盖本地开发、Cloud Shell、GKE、云内附加服务账号以及本地/多云环境五类典型部署场景并深入源码剖析service_account_key_json、client_project_id等配置项的实际作用。读完本文你将能针对自己的运行环境选择正确的认证方式、写出可直接运行的 BigQuery 目标配置并理解插件在启动时如何校验凭据与数据集。认证核心Application Default CredentialsADCCloudQuery 的 BigQuery 目标插件不使用自定义的认证体系而是完全复用 Google Cloud 官方的 Application Default CredentialsADC查找机制。ADC 是一套标准化的凭据发现流程当代码调用 Google Cloud 客户端库时SDK 会按照既定顺序在环境中查找可用的凭据找到后即可自动完成 OAuth 认证与 Token 刷新。从源码可以看到插件在创建 BigQuery 客户端时并没有显式传入任何密钥而是把任务交给官方 SDKclient.go 中的bqClient函数构造option.ClientOption列表调用bigquery.NewClient(ctx, s.ClientProjectID, opts...)只有当用户显式配置了service_account_key_json时才会追加option.WithAuthCredentialsJSON(option.ServiceAccount, []byte(s.ServiceAccountKeyJSON))这一选项其余情况下客户端库走 ADC 默认查找路径环境变量GOOGLE_APPLICATION_CREDENTIALS、gcloud 配置的默认凭据、元数据服务器等。因此理解「在什么环境、用什么方式让 ADC 能发现凭据」是配置 BigQuery 目标插件的关键前提。原认证文档将场景划分为四类下面逐一展开。本地开发环境gcloud auth application-default login当你在自己的笔记本或开发机上运行cloudquery sync时推荐使用 gcloud 命令行工具生成 ADC 凭据gcloud auth application-default login执行该命令后gcloud 会引导你完成浏览器授权并把生成的「应用默认凭据」写入本地配置文件中。此后CloudQuery BigQuery 插件运行时Google 客户端库会自动定位到这份凭据无需在配置里写任何密钥。该方式之所以被推荐是因为它把「身份」与「代码」分离开发机上不会出现长期有效的服务账号密钥文件凭据以用户身份或委托的账号存在且可通过gcloud auth application-default revoke随时回收。Google Cloud 云内开发环境Cloud Shell 与 Cloud Code如果你的开发工作直接在 Google Cloud 生态内完成——例如在Cloud Shell中执行命令或在 IDE 里通过Cloud Code插件运行 CloudQuery——则不需要做任何额外的认证配置。原因在于Cloud Shell 和 Cloud Code 会话启动时Google Cloud 平台已经为你注入了当前登录用户的凭据ADC 机制能够直接发现并使用它们。也就是说你在这些环境中拿到cloudquery二进制后只要配置好project_id与dataset_id插件启动时即可完成认证。GKE 容器化环境Workload Identity当 CloudQuery 以容器形式运行在Google Kubernetes EngineGKE集群中时推荐使用Workload Identity工作负载身份联盟进行认证。Workload Identity 的核心思路是让 Kubernetes 的 ServiceAccount 与 Google Cloud 的 IAM 服务账号建立绑定关系Pod 内运行的进程可以通过 GKE 的元数据服务器自动获得临时凭据整个过程无需在 Pod 中存放任何密钥文件。对 CloudQuery 而言只要集群与节点池启用了 Workload Identity并且 CloudQuery 容器使用的 Kubernetes ServiceAccount 绑定了具备 BigQuery 数据集读写权限的 IAM 服务账号插件即可透明完成认证。相比在容器镜像或 ConfigMap 中注入密钥Workload Identity 天然具备两个优势凭据是短期的、自动轮换的且权限范围可收敛到单一服务账号。Google Cloud 内可附加服务账号的服务Compute Engine、App Engine、Functions对于Compute Engine 虚拟机、App Engine 应用、Cloud Functions 函数这类「支持附加用户管理服务账号」的 Google Cloud 托管服务CloudQuery 同样可以直接利用平台注入的服务账号凭据。具体来说这类服务在创建或部署时允许你指定一个服务账号附加到实例/应用/函数上。运行时Google Cloud 的元数据服务器会为进程提供该服务账号的短期凭据ADC 机制会自动发现并采用。因此只要预先为该服务账号授予目标 BigQuery 数据集所需的写权限及必要的 BigQuery 作业权限在这些服务上运行 CloudQuery 时无需任何显式认证配置。这一场景与 GKE 的 Workload Identity 本质相同都是「平台负责提供凭据应用零配置消费」区别仅在于底层托管服务不同。本地或其他云平台Workload Identity Federation 优先密钥兜底如果 CloudQuery 运行在**本地自建机房、或其他云厂商如 AWS、Azure**的环境中原认证文档给出了两种方案并明确标注了优先级首选Workload Identity Federation工作负载身份联盟。它允许你用外部身份例如本地 Active Directory、其他云厂商的角色等换取 Google Cloud 的临时凭据无需维护长期有效的服务账号密钥符合安全最佳实践。兜底服务账号密钥文件 环境变量。如果当前环境无法使用 Workload Identity Federation可以下载一个服务账号的 JSON 密钥并通过GOOGLE_APPLICATION_CREDENTIALS环境变量指向该文件export GOOGLE_APPLICATION_CREDENTIALS/path/to/service-account-key.json但文档特别强调这种方式不推荐使用因为长期有效的密钥本身就是一种安全风险——一旦泄露攻击者可长期冒充该服务账号访问你的 BigQuery 资源。如果必须使用应严格限制密钥的权限范围、定期轮换并避免把密钥提交进代码仓库。值得说明的是对于「本地或其他云」这类无法依赖云内元数据服务器的环境GOOGLE_APPLICATION_CREDENTIALS是 ADC 查找链中唯一可直接读取密钥文件的环节因此它天然成为兜底方案。配置层视角service_account_key_json与 ADC 的关系在 CloudQuery 的配置层面上述认证机制与 spec.go 中定义的service_account_key_json字段直接对应spec: project_id: ${PROJECT_ID} dataset_id: ${DATASET_ID} # 可选直接内联 GCP 服务账号密钥内容 # service_account_key_json: ${file:./path-to-your-file.json}该字段的行为可以从源码得到精确印证在 client.go 中当len(s.ServiceAccountKeyJSON) ! 0时插件会调用option.WithAuthCredentialsJSON把密钥内容直接交给官方 BigQuery 客户端——此时显式密钥优先于 ADC 的自动发现在 spec.go 的Validate中插件会对该字段做 JSON 合法性校验非法的 JSON 会直接报错若不配置该字段客户端走 ADC 默认链路即前面五类场景描述的自动发现过程。配置层面还有两个实用技巧文件变量替换语法文档建议通过${file:./path-to-your-file.json}引用密钥文件内容让 CloudQuery 在加载配置时完成变量替换避免把密钥明文写进配置也可以使用${ENV_VAR}从环境变量注入见 cli/testdata/source-with-env.yml 展示的环境变量替换用法。源与目标分离service_account_key_json的典型用途是「让 BigQuery 目标插件使用与源插件不同的服务账号」从而在 GCP 源插件与 BigQuery 目标之间做权限隔离。client_project_id凭据与查询项目解耦在认证上下文之外还有一个与「项目身份」强相关的配置项值得一并说明——client_project_id见 spec.gospec: client_project_id: *detect-project-id*它的作用与默认值可以从 spec.go 的SetDefaults中看到未设置时默认等于project_id即客户端在目标表所在项目中执行查询设置为*detect-project-id*时插件将自动从环境变量或 ADC 凭据中探测项目 ID当你需要「在项目 A 存储表、在项目 B 执行查询」时可将client_project_id显式指向项目 B。由于该值直接传给bigquery.NewClient的第一个参数client.go它会成为 BigQuery 客户端 API 调用的项目上下文因此也和认证凭据的授权范围紧密相关凭据主体必须对client_project_id指向的项目具备相应权限。启动校验与常见问题排查插件并不只是在写入数据时才检查认证。从 client.go 可以看到New在初始化客户端后会立即调用validateCreds而 TestConnection 也会复用同样的逻辑做连接自检。validateCredsclient.go的实际行为是调用DatasetInProject(projectID, datasetID).Metadata()读取数据集元数据。根据 errors.go 中的错误判定当 API 返回 404 时会给出明确提示数据集必须在 sync 或 migrate 之前预先创建——插件只会自动建表不会自动建数据集。结合认证文档与源码常见问题的排查思路如下现象可能原因处理建议提示找不到凭据类似could not find default credentials环境未提供任何 ADC 凭据本地执行gcloud auth application-default login服务器环境配置 Workload Identity 或GOOGLE_APPLICATION_CREDENTIALS提示 invalid dataset / dataset must be created目标数据集尚未创建在 BigQuery 控制台或bq mk创建数据集后再 sync权限不足403凭据主体的 IAM 权限不足为服务账号/用户授予数据集的 BigQuery 写入与作业权限service_account_key_json校验失败内联内容不是合法 JSON改用${file:...}引用密钥文件并确认文件内容为完整 JSON提示 dataset not found新数据集场景数据集所在 region 不明确设置dataset_location作为作业默认位置见 overview.md 的说明另外注意BigQuery 目标插件当前仅支持append写模式overview.md配置时应避免使用其它写模式。小结按环境选择认证方式的决策参考运行环境推荐认证方式是否需要显式配置密钥本地开发机gcloud auth application-default login否Cloud Shell / Cloud Code平台自动注入凭据否GKE 容器Workload Identity否Compute Engine / App Engine / Functions附加服务账号否本地机房 / 其他云Workload Identity Federation否则GOOGLE_APPLICATION_CREDENTIALS不推荐可选兜底任意环境需要独立身份service_account_key_json 文件变量替换是显式核心原则可以总结为三句话能利用平台自动注入的短期凭据就优先利用无法利用时优先选择 Workload Identity Federation 这类联盟方案最后才考虑长期密钥且务必控制权限、及时轮换。在 CloudQuery 中无论选择哪种方式最终都汇聚到官方 BigQuery 客户端库的 ADC 机制上你只需要保证「运行环境里存在可被 ADC 发现的凭据」即可。更多配置参数dataset_location、time_partitioning、batch_size等可参考 配置文档 与 overview.md完整的 Spec 字段定义见 spec.go。赞分享数据集成数据工程数据分析【免费下载链接】cloudqueryData pipelines for cloud config and security data. Build cloud asset inventory, CSPM, FinOps, and vulnerability management solutions. Extract from AWS, Azure, GCP, and 70 cloud and SaaS sources.项目地址https://gitcode.com/gh_mirrors/cl/cloudquery点击查看免费下载相关推荐在 LangChain RAG 链路中接入本地临床文本脱敏OpenMed LangChain Redaction Wrapper 实战在 LangChain RAG 链路中接入本地临床文本脱敏OpenMed LangChain Redaction Wrapper 实战 OpenMed 提供与数据集成数据工程数据分析SQLiteStudio aarch64 构建指南在树莓派等 ARM64 Linux 上少走弯路SQLiteStudio aarch64 构建指南在树莓派等 ARM64 Linux 上少走弯路 想在树莓派、Orange Pi、Radxa 这类 aarch数据集成数据工程数据分析Telegraf GoogleCloud 凭据 Secret Store 插件基于 GCP 认证令牌的密钥引用实战指南Telegraf GoogleCloud 凭据 Secret Store 插件基于 GCP 认证令牌的密钥引用实战指南 本指南系统讲解 Telegraf 内置可观测性指标监控运维上一篇无水印B站视频提取全攻略从工具选型到合规使用的系统方法论下一篇awesome-typescript-loader 高级配置指南20个实用选项详解创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
数据集成数据工程数据分析【免费下载链接】cloudqueryData pipelines for cloud config and security data. Build cloud asset inventory, CSPM, FinOps, and vulnerability management solutions. Extract from AWS, Azure, GCP, and 70 cloud and SaaS sources.项目地址https://gitcode.com/gh_mirrors/cl/cloudquery点击查看免费下载本指南以 CloudQuery 仓库中 BigQuery 目标插件plugins/destination/bigquery的认证文档为主线系统讲解插件如何基于 Google Cloud 的 Application Default CredentialsADC机制完成身份认证覆盖本地开发、Cloud Shell、GKE、云内附加服务账号以及本地/多云环境五类典型部署场景并深入源码剖析service_account_key_json、client_project_id等配置项的实际作用。读完本文你将能针对自己的运行环境选择正确的认证方式、写出可直接运行的 BigQuery 目标配置并理解插件在启动时如何校验凭据与数据集。认证核心Application Default CredentialsADCCloudQuery 的 BigQuery 目标插件不使用自定义的认证体系而是完全复用 Google Cloud 官方的 Application Default CredentialsADC查找机制。ADC 是一套标准化的凭据发现流程当代码调用 Google Cloud 客户端库时SDK 会按照既定顺序在环境中查找可用的凭据找到后即可自动完成 OAuth 认证与 Token 刷新。从源码可以看到插件在创建 BigQuery 客户端时并没有显式传入任何密钥而是把任务交给官方 SDKclient.go 中的bqClient函数构造option.ClientOption列表调用bigquery.NewClient(ctx, s.ClientProjectID, opts...)只有当用户显式配置了service_account_key_json时才会追加option.WithAuthCredentialsJSON(option.ServiceAccount, []byte(s.ServiceAccountKeyJSON))这一选项其余情况下客户端库走 ADC 默认查找路径环境变量GOOGLE_APPLICATION_CREDENTIALS、gcloud 配置的默认凭据、元数据服务器等。因此理解「在什么环境、用什么方式让 ADC 能发现凭据」是配置 BigQuery 目标插件的关键前提。原认证文档将场景划分为四类下面逐一展开。本地开发环境gcloud auth application-default login当你在自己的笔记本或开发机上运行cloudquery sync时推荐使用 gcloud 命令行工具生成 ADC 凭据gcloud auth application-default login执行该命令后gcloud 会引导你完成浏览器授权并把生成的「应用默认凭据」写入本地配置文件中。此后CloudQuery BigQuery 插件运行时Google 客户端库会自动定位到这份凭据无需在配置里写任何密钥。该方式之所以被推荐是因为它把「身份」与「代码」分离开发机上不会出现长期有效的服务账号密钥文件凭据以用户身份或委托的账号存在且可通过gcloud auth application-default revoke随时回收。Google Cloud 云内开发环境Cloud Shell 与 Cloud Code如果你的开发工作直接在 Google Cloud 生态内完成——例如在Cloud Shell中执行命令或在 IDE 里通过Cloud Code插件运行 CloudQuery——则不需要做任何额外的认证配置。原因在于Cloud Shell 和 Cloud Code 会话启动时Google Cloud 平台已经为你注入了当前登录用户的凭据ADC 机制能够直接发现并使用它们。也就是说你在这些环境中拿到cloudquery二进制后只要配置好project_id与dataset_id插件启动时即可完成认证。GKE 容器化环境Workload Identity当 CloudQuery 以容器形式运行在Google Kubernetes EngineGKE集群中时推荐使用Workload Identity工作负载身份联盟进行认证。Workload Identity 的核心思路是让 Kubernetes 的 ServiceAccount 与 Google Cloud 的 IAM 服务账号建立绑定关系Pod 内运行的进程可以通过 GKE 的元数据服务器自动获得临时凭据整个过程无需在 Pod 中存放任何密钥文件。对 CloudQuery 而言只要集群与节点池启用了 Workload Identity并且 CloudQuery 容器使用的 Kubernetes ServiceAccount 绑定了具备 BigQuery 数据集读写权限的 IAM 服务账号插件即可透明完成认证。相比在容器镜像或 ConfigMap 中注入密钥Workload Identity 天然具备两个优势凭据是短期的、自动轮换的且权限范围可收敛到单一服务账号。Google Cloud 内可附加服务账号的服务Compute Engine、App Engine、Functions对于Compute Engine 虚拟机、App Engine 应用、Cloud Functions 函数这类「支持附加用户管理服务账号」的 Google Cloud 托管服务CloudQuery 同样可以直接利用平台注入的服务账号凭据。具体来说这类服务在创建或部署时允许你指定一个服务账号附加到实例/应用/函数上。运行时Google Cloud 的元数据服务器会为进程提供该服务账号的短期凭据ADC 机制会自动发现并采用。因此只要预先为该服务账号授予目标 BigQuery 数据集所需的写权限及必要的 BigQuery 作业权限在这些服务上运行 CloudQuery 时无需任何显式认证配置。这一场景与 GKE 的 Workload Identity 本质相同都是「平台负责提供凭据应用零配置消费」区别仅在于底层托管服务不同。本地或其他云平台Workload Identity Federation 优先密钥兜底如果 CloudQuery 运行在**本地自建机房、或其他云厂商如 AWS、Azure**的环境中原认证文档给出了两种方案并明确标注了优先级首选Workload Identity Federation工作负载身份联盟。它允许你用外部身份例如本地 Active Directory、其他云厂商的角色等换取 Google Cloud 的临时凭据无需维护长期有效的服务账号密钥符合安全最佳实践。兜底服务账号密钥文件 环境变量。如果当前环境无法使用 Workload Identity Federation可以下载一个服务账号的 JSON 密钥并通过GOOGLE_APPLICATION_CREDENTIALS环境变量指向该文件export GOOGLE_APPLICATION_CREDENTIALS/path/to/service-account-key.json但文档特别强调这种方式不推荐使用因为长期有效的密钥本身就是一种安全风险——一旦泄露攻击者可长期冒充该服务账号访问你的 BigQuery 资源。如果必须使用应严格限制密钥的权限范围、定期轮换并避免把密钥提交进代码仓库。值得说明的是对于「本地或其他云」这类无法依赖云内元数据服务器的环境GOOGLE_APPLICATION_CREDENTIALS是 ADC 查找链中唯一可直接读取密钥文件的环节因此它天然成为兜底方案。配置层视角service_account_key_json与 ADC 的关系在 CloudQuery 的配置层面上述认证机制与 spec.go 中定义的service_account_key_json字段直接对应spec: project_id: ${PROJECT_ID} dataset_id: ${DATASET_ID} # 可选直接内联 GCP 服务账号密钥内容 # service_account_key_json: ${file:./path-to-your-file.json}该字段的行为可以从源码得到精确印证在 client.go 中当len(s.ServiceAccountKeyJSON) ! 0时插件会调用option.WithAuthCredentialsJSON把密钥内容直接交给官方 BigQuery 客户端——此时显式密钥优先于 ADC 的自动发现在 spec.go 的Validate中插件会对该字段做 JSON 合法性校验非法的 JSON 会直接报错若不配置该字段客户端走 ADC 默认链路即前面五类场景描述的自动发现过程。配置层面还有两个实用技巧文件变量替换语法文档建议通过${file:./path-to-your-file.json}引用密钥文件内容让 CloudQuery 在加载配置时完成变量替换避免把密钥明文写进配置也可以使用${ENV_VAR}从环境变量注入见 cli/testdata/source-with-env.yml 展示的环境变量替换用法。源与目标分离service_account_key_json的典型用途是「让 BigQuery 目标插件使用与源插件不同的服务账号」从而在 GCP 源插件与 BigQuery 目标之间做权限隔离。client_project_id凭据与查询项目解耦在认证上下文之外还有一个与「项目身份」强相关的配置项值得一并说明——client_project_id见 spec.gospec: client_project_id: *detect-project-id*它的作用与默认值可以从 spec.go 的SetDefaults中看到未设置时默认等于project_id即客户端在目标表所在项目中执行查询设置为*detect-project-id*时插件将自动从环境变量或 ADC 凭据中探测项目 ID当你需要「在项目 A 存储表、在项目 B 执行查询」时可将client_project_id显式指向项目 B。由于该值直接传给bigquery.NewClient的第一个参数client.go它会成为 BigQuery 客户端 API 调用的项目上下文因此也和认证凭据的授权范围紧密相关凭据主体必须对client_project_id指向的项目具备相应权限。启动校验与常见问题排查插件并不只是在写入数据时才检查认证。从 client.go 可以看到New在初始化客户端后会立即调用validateCreds而 TestConnection 也会复用同样的逻辑做连接自检。validateCredsclient.go的实际行为是调用DatasetInProject(projectID, datasetID).Metadata()读取数据集元数据。根据 errors.go 中的错误判定当 API 返回 404 时会给出明确提示数据集必须在 sync 或 migrate 之前预先创建——插件只会自动建表不会自动建数据集。结合认证文档与源码常见问题的排查思路如下现象可能原因处理建议提示找不到凭据类似could not find default credentials环境未提供任何 ADC 凭据本地执行gcloud auth application-default login服务器环境配置 Workload Identity 或GOOGLE_APPLICATION_CREDENTIALS提示 invalid dataset / dataset must be created目标数据集尚未创建在 BigQuery 控制台或bq mk创建数据集后再 sync权限不足403凭据主体的 IAM 权限不足为服务账号/用户授予数据集的 BigQuery 写入与作业权限service_account_key_json校验失败内联内容不是合法 JSON改用${file:...}引用密钥文件并确认文件内容为完整 JSON提示 dataset not found新数据集场景数据集所在 region 不明确设置dataset_location作为作业默认位置见 overview.md 的说明另外注意BigQuery 目标插件当前仅支持append写模式overview.md配置时应避免使用其它写模式。小结按环境选择认证方式的决策参考运行环境推荐认证方式是否需要显式配置密钥本地开发机gcloud auth application-default login否Cloud Shell / Cloud Code平台自动注入凭据否GKE 容器Workload Identity否Compute Engine / App Engine / Functions附加服务账号否本地机房 / 其他云Workload Identity Federation否则GOOGLE_APPLICATION_CREDENTIALS不推荐可选兜底任意环境需要独立身份service_account_key_json 文件变量替换是显式核心原则可以总结为三句话能利用平台自动注入的短期凭据就优先利用无法利用时优先选择 Workload Identity Federation 这类联盟方案最后才考虑长期密钥且务必控制权限、及时轮换。在 CloudQuery 中无论选择哪种方式最终都汇聚到官方 BigQuery 客户端库的 ADC 机制上你只需要保证「运行环境里存在可被 ADC 发现的凭据」即可。更多配置参数dataset_location、time_partitioning、batch_size等可参考 配置文档 与 overview.md完整的 Spec 字段定义见 spec.go。赞分享数据集成数据工程数据分析【免费下载链接】cloudqueryData pipelines for cloud config and security data. Build cloud asset inventory, CSPM, FinOps, and vulnerability management solutions. Extract from AWS, Azure, GCP, and 70 cloud and SaaS sources.项目地址https://gitcode.com/gh_mirrors/cl/cloudquery点击查看免费下载相关推荐在 LangChain RAG 链路中接入本地临床文本脱敏OpenMed LangChain Redaction Wrapper 实战在 LangChain RAG 链路中接入本地临床文本脱敏OpenMed LangChain Redaction Wrapper 实战 OpenMed 提供与数据集成数据工程数据分析SQLiteStudio aarch64 构建指南在树莓派等 ARM64 Linux 上少走弯路SQLiteStudio aarch64 构建指南在树莓派等 ARM64 Linux 上少走弯路 想在树莓派、Orange Pi、Radxa 这类 aarch数据集成数据工程数据分析Telegraf GoogleCloud 凭据 Secret Store 插件基于 GCP 认证令牌的密钥引用实战指南Telegraf GoogleCloud 凭据 Secret Store 插件基于 GCP 认证令牌的密钥引用实战指南 本指南系统讲解 Telegraf 内置可观测性指标监控运维上一篇无水印B站视频提取全攻略从工具选型到合规使用的系统方法论下一篇awesome-typescript-loader 高级配置指南20个实用选项详解创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
