https://pulumi.com logo
Powered by
Title
b

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"): 
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?
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? 
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,
        })
    )
  );
}
e

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.
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.
b

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. 
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.
#google-cloudJoin Slack
Powered by