首页
学习
活动
专区
工具
TVP
发布
精选内容/技术社群/优惠产品,尽在小程序
立即前往

给予GCP Cloud Function ( CF )使其只能从另一个CF调用的正确权限是什么?

在 Google Cloud Platform (GCP) 中,如果你希望一个 Cloud Function (CF) 只能被另一个 Cloud Function 调用,你需要配置适当的身份和访问管理 (IAM) 权限。以下是实现这一目标的步骤:

1. 创建服务账号

首先,为调用 Cloud Function 的 Cloud Function 创建一个服务账号。

代码语言:javascript
复制
gcloud iam service-accounts create caller-function-sa \
    --display-name "Service account for caller Cloud Function"

2. 授予调用权限

接下来,为这个服务账号授予调用目标 Cloud Function 的权限。你需要将 roles/cloudfunctions.invoker 角色绑定到目标 Cloud Function。

代码语言:javascript
复制
gcloud functions add-iam-policy-binding TARGET_FUNCTION_NAME \
    --member="serviceAccount:caller-function-sa@YOUR_PROJECT_ID.iam.gserviceaccount.com" \
    --role="roles/cloudfunctions.invoker"

TARGET_FUNCTION_NAME 替换为目标 Cloud Function 的名称,将 YOUR_PROJECT_ID 替换为你的 GCP 项目 ID。

3. 配置调用 Cloud Function 使用服务账号

在调用 Cloud Function 的部署过程中,指定使用刚刚创建的服务账号。

代码语言:javascript
复制
gcloud functions deploy CALLER_FUNCTION_NAME \
    --runtime RUNTIME \
    --trigger-http \
    --service-account caller-function-sa@YOUR_PROJECT_ID.iam.gserviceaccount.com

CALLER_FUNCTION_NAME 替换为调用 Cloud Function 的名称,将 RUNTIME 替换为你的 Cloud Function 的运行时(例如 nodejs14),将 YOUR_PROJECT_ID 替换为你的 GCP 项目 ID。

4. 确保目标 Cloud Function 的触发器配置正确

确保目标 Cloud Function 的触发器配置为 HTTP 触发器,并且没有公开访问权限。

代码语言:javascript
复制
gcloud functions deploy TARGET_FUNCTION_NAME \
    --runtime RUNTIME \
    --trigger-http \
    --no-allow-unauthenticated

TARGET_FUNCTION_NAME 替换为目标 Cloud Function 的名称,将 RUNTIME 替换为你的 Cloud Function 的运行时。

5. 调用 Cloud Function

在调用 Cloud Function 的代码中,使用 HTTP 请求调用目标 Cloud Function。确保在请求中包含适当的身份验证令牌。

以下是一个使用 Node.js 的示例,展示如何从一个 Cloud Function 调用另一个 Cloud Function:

代码语言:javascript
复制
const { google } = require('googleapis');
const fetch = require('node-fetch');

exports.callerFunction = async (req, res) => {
  const targetFunctionUrl = 'https://REGION-PROJECT_ID.cloudfunctions.net/TARGET_FUNCTION_NAME';

  // 获取身份验证令牌
  const auth = new google.auth.GoogleAuth({
    scopes: ['https://www.googleapis.com/auth/cloud-platform']
  });

  const client = await auth.getClient();
  const token = await client.getAccessToken();

  // 调用目标 Cloud Function
  const response = await fetch(targetFunctionUrl, {
    method: 'POST',
    headers: {
      'Authorization': `Bearer ${token.token}`,
      'Content-Type': 'application/json'
    },
    body: JSON.stringify({ message: 'Hello from caller function!' })
  });

  const data = await response.json();
  res.status(200).send(data);
};

REGION 替换为目标 Cloud Function 部署的区域,将 PROJECT_ID 替换为你的 GCP 项目 ID,将 TARGET_FUNCTION_NAME 替换为目标 Cloud Function 的名称。

页面内容是否对你有帮助?
有帮助
没帮助

相关·内容

  • 《Scikit-Learn、Keras与TensorFlow机器学习实用指南(第二版)》第19章 规模化训练和部署TensorFlow模型

    有了能做出惊人预测的模型之后,要做什么呢?当然是部署生产了。这只要用模型运行一批数据就成,可能需要写一个脚本让模型每夜都跑着。但是,现实通常会更复杂。系统基础组件都可能需要这个模型用于实时数据,这种情况需要将模型包装成网络服务:这样的话,任何组件都可以通过REST API询问模型。随着时间的推移,你需要用新数据重新训练模型,更新生产版本。必须处理好模型版本,平稳地过渡到新版本,碰到问题的话需要回滚,也许要并行运行多个版本做AB测试。如果产品很成功,你的服务可能每秒会有大量查询,系统必须提升负载能力。提升负载能力的方法之一,是使用TF Serving,通过自己的硬件或通过云服务,比如Google Cloud API平台。TF Serving能高效服务化模型,优雅处理模型过渡,等等。如果使用云平台,还能获得其它功能,比如强大的监督工具。

    02

    通过Kyverno使用KMS、Cosign和工作负载身份验证容器镜像

    随着软件供应链攻击的增加,保护我们的软件供应链变得更加重要。此外,在过去几年中,容器的采用也有所增加。有鉴于此,对容器镜像进行签名以帮助防止供应链攻击的需求日益增长。此外,我们今天使用的大多数容器,即使我们在生产环境中使用它们,也容易受到供应链攻击。在传统的 CI/CD 工作流中,我们构建镜像并将其推入注册中心。供应链安全的一个重要部分是我们构建的镜像的完整性,这意味着我们必须确保我们构建的镜像没有被篡改,这意味着保证我们从注册中心中提取的镜像与我们将要部署到生产系统中的镜像相同。证明镜像没有被篡改的最简单和最好的方法之一(多亏了 Sigstore)是在构建之后立即签名,并在允许它们部署到生产系统之前验证它。这就是 Cosign 和 Kyverno 发挥作用的地方。

    02
    领券