Managing access
Access on the CBWS platform is granted by adding a member to a role on a resource, such as a project. The resource's IAM policy holds these bindings, and a binding on a project reaches every resource in it.
Members and roles
A member is one of:
| Member | Example |
|---|---|
user |
user colleague@example.com |
group |
group team@example.com |
serviceAccount |
serviceAccount deployer@my-project.iam-sa.cbws.xyz |
allUsers |
every principal, including people outside your organization |
A role is a set of permissions. A service's own roles are named services/{service}/roles/{role}, and each service's
description lists the roles it offers. The platform-wide roles/owner gives full access.
Projects
Warning
Always pass --role. Without it, cbws projects add-member grants roles/owner.
Service accounts
A service account has a policy of its own, which decides who may act as it. Without --role,
these commands grant and revoke the role that lets a member mint tokens for the account.
VPCs and private networks
VPCs and private networks also have their own policies, for access to one of them rather than to the whole project.
cbws vpc vpcs get-iam-policy my-vpc
cbws vpc vpcs add-member my-vpc user colleague@example.com --role <role>
cbws vpc private-networks get-iam-policy my-network
get-iam-policy shows only the bindings on that resource itself, not the ones on the project above it.
To find out why a command was denied, check which permissions you hold on a resource:
Granting to everyone
Granting to allUsers gives every principal the role, so the CLI asks for confirmation first. Pass --yes to skip the
question in a script.
How changes are made
A policy is replaced as a whole when it is written. add-member and remove-member read the policy, change the one
binding and write it back, so bindings made by others are kept. Use them rather than editing a policy by hand.