Im tying to add an IAM policy to a service account as per <h Pulumi Community #google-cloud

Im tying to add an IAM policy to a service account...

best-summer-38252

02/28/2023, 7:18 PM

Im tying to add an IAM policy to a service account as per https://www.pulumi.com/registry/packages/gcp/api-docs/serviceaccount/iammember/ The policy has a list of bindings and every role I have tried provided results in an Error 400 (other than "roles/iam.serviceAccountUser"):

Copy code

Error 400: Role roles/workflow.invoker is not supported for this resource., badRequest

Surely a service account can have a role as per the Pulumi example. The exmaple shows the format of the role being just the role name, roles/iam.serviceAccountUser, which seems consistent with the type info: _The role that should be applied Only one

gcp.organizations.IAMBinding

can be used per role. Note that custom roles must be of the format

organizations/{{org_id}}/roles/{{role_id}}

._ Given I am not using custom roles, is

roles/workflow.invoker

the correct format?

best-summer-38252

03/01/2023, 4:40 AM

so if

"roles/iam.serviceAccountUser"

is works just fine but

"roles/workflows.invoker"

is not allowed, what is needed so the service account can invoke a workflow?

Copy code

if (!IAM_DEV_FLAG) {
  const getIAMPolicy = ({ roles, member }: { roles: string[]; member: string }) =>
    gcp.organizations.getIAMPolicy({
      bindings: roles.map((role) => ({
        members: [member],
        role,
      })),
    });

  const appIAM = appSA.member.apply((member) =>
    getIAMPolicy({
      member,
      roles: [
        //"roles/run.invoker", // workflow to invoke dispatch  in cloud run via HTTP
        //"roles/workflows.invoker", // cloud scheduler to invoke the workflow
        "roles/iam.serviceAccountUser", // a role that actually works from the pulumi docs
      ],
    }).then(
      (policy) =>
        new gcp.serviceaccount.IAMPolicy(kebabcase(APP_NAME + "-authz"), {
          serviceAccountId: appSA.name,
          policyData: policy.policyData,
        })
    )
  );
}

eager-keyboard-30823

03/01/2023, 8:21 AM

This is something I was confused about as well - basically when you use that module you’re granting roles that have access to the service account, not roles that the service account has access to. If you want to grant invoker access across the project, you need to use one thing, and if you want to grant workflows invoker access for a specific workflow, you need to use another.

eager-keyboard-30823

03/01/2023, 8:24 AM

For global, you want to use

gcp.projects.IAMMember

(or `IAMPolicy`/`IAMBinding`). For the role on workflows, I’m actually not seeing anything in the

gcp.workflows

module, so not sure. That’s typically how it works though, e.g. if you want to grant roles directly on a storage bucket, you’ll be looking for IAM objects in

gcp.storage

, etc.

best-summer-38252

03/01/2023, 4:59 PM

Thanks for the explaintion on the IAM Policy, I was definitely backwards. To invoke cloud run from the workflow I can set the IAM member.

Copy code

const invoker = new gcp.cloudrun.IamMember("invoke-by-workflow-authz", {
  location: REGION,
  project: GCP_PROJECT.name,
  service: appService.name,
  role: "roles/run.invoker",
  member: "allUsers",
});

But that does not exist on the Workflow - apparently its a bug (half baked product, this is just the latest shortcoming). • https://issuetracker.google.com/issues/221402255?pli=1 • https://github.com/hashicorp/terraform-provider-google/issues/12914 I think Ill just let cloud scheduler have the default service account for the project to invoke the workflow until WF has better IAM support.

Open in Slack

Previous Next