Configure GCP Pub/Sub Topic IAM Bindings

The gcp:pubsub/topicIAMBinding:TopicIAMBinding resource, part of the Pulumi GCP provider, grants IAM roles to members for Pub/Sub topics. It manages all members for a specific role authoritatively while preserving other roles on the topic. This guide focuses on two capabilities: bulk member assignment and incremental member grants.

IAM bindings reference existing Pub/Sub topics and require appropriate IAM permissions in the GCP project. The examples are intentionally small. Combine them with your own topic resources and identity management.

Grant a role to multiple members at once

When multiple users or service accounts need the same level of access, TopicIAMBinding assigns a role to all members in a single resource.

import * as pulumi from "@pulumi/pulumi";
import * as gcp from "@pulumi/gcp";

const binding = new gcp.pubsub.TopicIAMBinding("binding", {
    project: example.project,
    topic: example.name,
    role: "roles/viewer",
    members: ["user:jane@example.com"],
});
import pulumi
import pulumi_gcp as gcp

binding = gcp.pubsub.TopicIAMBinding("binding",
    project=example["project"],
    topic=example["name"],
    role="roles/viewer",
    members=["user:jane@example.com"])
package main

import (
	"github.com/pulumi/pulumi-gcp/sdk/v9/go/gcp/pubsub"
	"github.com/pulumi/pulumi/sdk/v3/go/pulumi"
)

func main() {
	pulumi.Run(func(ctx *pulumi.Context) error {
		_, err := pubsub.NewTopicIAMBinding(ctx, "binding", &pubsub.TopicIAMBindingArgs{
			Project: pulumi.Any(example.Project),
			Topic:   pulumi.Any(example.Name),
			Role:    pulumi.String("roles/viewer"),
			Members: pulumi.StringArray{
				pulumi.String("user:jane@example.com"),
			},
		})
		if err != nil {
			return err
		}
		return nil
	})
}
using System.Collections.Generic;
using System.Linq;
using Pulumi;
using Gcp = Pulumi.Gcp;

return await Deployment.RunAsync(() => 
{
    var binding = new Gcp.PubSub.TopicIAMBinding("binding", new()
    {
        Project = example.Project,
        Topic = example.Name,
        Role = "roles/viewer",
        Members = new[]
        {
            "user:jane@example.com",
        },
    });

});
package generated_program;

import com.pulumi.Context;
import com.pulumi.Pulumi;
import com.pulumi.core.Output;
import com.pulumi.gcp.pubsub.TopicIAMBinding;
import com.pulumi.gcp.pubsub.TopicIAMBindingArgs;
import java.util.List;
import java.util.ArrayList;
import java.util.Map;
import java.io.File;
import java.nio.file.Files;
import java.nio.file.Paths;

public class App {
    public static void main(String[] args) {
        Pulumi.run(App::stack);
    }

    public static void stack(Context ctx) {
        var binding = new TopicIAMBinding("binding", TopicIAMBindingArgs.builder()
            .project(example.project())
            .topic(example.name())
            .role("roles/viewer")
            .members("user:jane@example.com")
            .build());

    }
}
resources:
  binding:
    type: gcp:pubsub:TopicIAMBinding
    properties:
      project: ${example.project}
      topic: ${example.name}
      role: roles/viewer
      members:
        - user:jane@example.com

The role property specifies which IAM role to grant (e.g., “roles/viewer”). The members array lists all identities that receive this role; TopicIAMBinding authoritatively manages this list, meaning any members not in the array will lose the role. The topic and project properties identify which Pub/Sub topic to configure.

Add a single member to a role incrementally

As teams grow, you often need to grant access one person at a time without managing the full member list.

import * as pulumi from "@pulumi/pulumi";
import * as gcp from "@pulumi/gcp";

const member = new gcp.pubsub.TopicIAMMember("member", {
    project: example.project,
    topic: example.name,
    role: "roles/viewer",
    member: "user:jane@example.com",
});
import pulumi
import pulumi_gcp as gcp

member = gcp.pubsub.TopicIAMMember("member",
    project=example["project"],
    topic=example["name"],
    role="roles/viewer",
    member="user:jane@example.com")
package main

import (
	"github.com/pulumi/pulumi-gcp/sdk/v9/go/gcp/pubsub"
	"github.com/pulumi/pulumi/sdk/v3/go/pulumi"
)

func main() {
	pulumi.Run(func(ctx *pulumi.Context) error {
		_, err := pubsub.NewTopicIAMMember(ctx, "member", &pubsub.TopicIAMMemberArgs{
			Project: pulumi.Any(example.Project),
			Topic:   pulumi.Any(example.Name),
			Role:    pulumi.String("roles/viewer"),
			Member:  pulumi.String("user:jane@example.com"),
		})
		if err != nil {
			return err
		}
		return nil
	})
}
using System.Collections.Generic;
using System.Linq;
using Pulumi;
using Gcp = Pulumi.Gcp;

return await Deployment.RunAsync(() => 
{
    var member = new Gcp.PubSub.TopicIAMMember("member", new()
    {
        Project = example.Project,
        Topic = example.Name,
        Role = "roles/viewer",
        Member = "user:jane@example.com",
    });

});
package generated_program;

import com.pulumi.Context;
import com.pulumi.Pulumi;
import com.pulumi.core.Output;
import com.pulumi.gcp.pubsub.TopicIAMMember;
import com.pulumi.gcp.pubsub.TopicIAMMemberArgs;
import java.util.List;
import java.util.ArrayList;
import java.util.Map;
import java.io.File;
import java.nio.file.Files;
import java.nio.file.Paths;

public class App {
    public static void main(String[] args) {
        Pulumi.run(App::stack);
    }

    public static void stack(Context ctx) {
        var member = new TopicIAMMember("member", TopicIAMMemberArgs.builder()
            .project(example.project())
            .topic(example.name())
            .role("roles/viewer")
            .member("user:jane@example.com")
            .build());

    }
}
resources:
  member:
    type: gcp:pubsub:TopicIAMMember
    properties:
      project: ${example.project}
      topic: ${example.name}
      role: roles/viewer
      member: user:jane@example.com

TopicIAMMember adds a single member to a role non-authoritatively, preserving existing members. The member property (singular) specifies one identity, while role and topic work the same as in TopicIAMBinding. You can create multiple TopicIAMMember resources for the same role without conflicts, as long as each grants to a different member.

Beyond these examples

These snippets focus on specific IAM binding features: role-based access control and bulk member assignment vs incremental grants. They’re intentionally minimal rather than full access control configurations.

The examples reference pre-existing infrastructure such as Pub/Sub topics and a GCP project with IAM permissions. They focus on configuring IAM bindings rather than provisioning topics or managing project-level permissions.

To keep things focused, common IAM patterns are omitted, including:

  • Conditional IAM bindings (condition property)
  • Custom role definitions and formatting
  • Policy-level management (TopicIAMPolicy)
  • Federated identity and workload identity pool configuration

These omissions are intentional: the goal is to illustrate how each IAM binding approach is wired, not provide drop-in access control modules. See the Pub/Sub TopicIAMBinding resource reference for all available configuration options.

Let's configure GCP Pub/Sub Topic IAM Bindings

Get started with Pulumi Cloud, then follow our quick setup guide to deploy this infrastructure.

Try Pulumi Cloud for FREE

Frequently Asked Questions

Resource Selection & Conflicts
What's the difference between TopicIAMPolicy, TopicIAMBinding, and TopicIAMMember?
TopicIAMPolicy is authoritative and replaces the entire IAM policy. TopicIAMBinding is authoritative for a single role, managing all members for that role while preserving other roles. TopicIAMMember is non-authoritative, adding individual members without affecting existing members for the role.
Can I use TopicIAMPolicy with TopicIAMBinding or TopicIAMMember?
No, TopicIAMPolicy cannot be used with TopicIAMBinding or TopicIAMMember because they’ll conflict over the policy state.
Can I use TopicIAMBinding and TopicIAMMember together?
Yes, but only if they manage different roles. Using both for the same role causes conflicts.
Configuration & Permissions
What member identity formats are supported?

You can use:

  • Special identifiers: allUsers, allAuthenticatedUsers
  • Accounts: user:{email}, serviceAccount:{email}, group:{email}
  • Domains: domain:{domain}
  • Project roles: projectOwner:{projectid}, projectEditor:{projectid}, projectViewer:{projectid}
  • Federated identities: principal://iam.googleapis.com/locations/global/workforcePools/...
What's the format for custom IAM roles?
Custom roles must use the format [projects|organizations]/{parent-name}/roles/{role-name}.
What properties can't be changed after creation?
The role, topic, project, and condition properties are immutable and require resource replacement if changed.

Using a different cloud?

Explore security guides for other cloud providers: