The Firebase SDK makes it really easy to implement Federated Identity Management.
Cloud IAM lets you manage access control by defining who (members) has what access (role) for which resource. You can grant more granular access to GCP Resources using the least privilege principle. Only grant access to resources that is necessary.
Cloud Platform Resources are organized hierarchically where the organization node is the root node in the hierarchy. The projects are the children of the organization and the other resources are the children of the projects. Each resource has exactly one parent.
IAM Members
You can specify who has access to your resources with IAM Members.
Types:
- Google account. It represents a developer, administrator or a person who interacts with GCP
- Service account. It belongs to an application instead of to an individual user
- Google group. Is a named collection of google accounts and service accounts. Every group has a unique email address that is associated with the group. They’re a convenient way to apply an access policy to a collection of users. They don’t have log-in credentials, so you cannot use them to establish identity to make a request to access a resource.
- G Suite domain. Is a virtual group of all the members in an organization. Suite customers can associate their email account with an Internet domain name. When you do this, each email account takes the form of username@yourdomain.com You can specify an identity by using any Internet domain name that is associated with a G Suite account. Like groups, domains cannot be used to stablish identity, but they enable convenient permissions management.
- Cloud Identity Domain. It represents a virtual group of all members in an organization but doesn’t provide access to G Suite apps and features.
Specify what resources the members have access to
You can grant access to users for our Cloud Platform resource. Resources include
- GCP Projects
- Compute Engine instances
- Cloud Storage buckets
- Pub/Sub topics
Specify what operations are allowed on resources
Permissions determine what operations are allowed on a resource.
They’re represented in the form of service.resource.verb
Example: storage.objects.list
They usually (but not always) correspond one to one to REST methods. This means, each Cloud Platform service has an associated set of permissions for each REST method that it exposes. The caller of that method, needs those permissions.
Assign permissions using roles
A role is the collection of permissions. You cannot assign a permission to the user directly, instead you grant them a role.
When you grant a role to a user, you grant them all the permissions that the role contains.
You can grant permissions by granting roles to a user, a group, or a service account.
There’re 3 kinds of roles
- Primitive. Apply primitive roles at a project level |Role name|Role title|Permissions| |:—:|:—:|:—:| |roles/viewer|Viewer|Read-only actions that preserve state| |roles/editor|Editor|Viewer permissions plus actions that modify state| |roles/owner|Owner|Editor permissions plus manage access control for a project and all its resources, and set up billing to a project|
Granting the owner role at a resource level such as pubsub.topic does not grant the owner role on the parent project. The owner role does not contain any permission for the organization resource. Granting the owner role at the organization level does not allow you to udpdate the organization’s metadata, but it allows you to modify projects under that organization.
- Predefined. They give granular access to specific GCP resources and prevent unwanted access to other resources.
|Role Name|Role Title|Description|Resource type| |:—:|:—:|:—:|:—:| |roles/bigtable.admin|Cloud Bigtable Admin|Administers all instances within a project, including data stored in tables[…]|Organization;Project;Instance| |roles/bigtable.user|Cloud Bigtable User|Provides read-write access to the data stored in tables[…]|Organization; Project; Instance| |roles/bigtable.reader|Cloud Bigtable Reader|Provides read-only access to the data stored in tables[…]|Organization; Project; Instance|
You can grant multiple roles to the same user. For example, you can grant admin and log viewer roles on a project and also have a publisher role for a pubsub.topic within that project.
- Custom. They permite even finer grained permission assignation.
They are great for the least-privilege principle.
If you decide to use them, you’ll need to manually manage the permissions that make them up. They also may only be used at the project or organization levels. They cannot be used at the folder level.
Define who has what type of access using policies
A policy is attached to a resource and is used to enforce access control whenever that resource is accessed.
Cloud IAM Policy
It is represented by the policy object. It consist of a list of bindings. A binding binds a list of members to a role.
API Methods
setIAMPolicy() allows you to set policies on your resources.
getIAMPolicy()
testIAMPermissions() allows you to test whether the caller has the specified permissions for a resource
Cloud IAM Best Practices
- Follow the principle of least privilege
- Rotate service account keys
- Manage user-managed service account keys
- Don’t check in service account keys to source code
- Use Cloud Audit Logging and export logs to Cloud Storage
- Set organization-level IAM policies to grant access to all projects in your organization
- Grant roles to a Google group instead of individual users when possible
Use service accounts to authenticate your apps when invoking Google APIs
Service accounts
- belong to your app or VM
- are used by your app to call the Google API or service so users aren’t directly involved
- are identified by their unique email address
- are associated with a key pair
- can have up to 10 keys associated with them to facilitate key rotation
- enable authentication and authorization. You can assign specific IAM roles to a service account.
Use external keys for external GCP use
They require that you be responsible for security of the private key and other management operations
They are managed through the IAM API; gcloud command; service account page
You can define many service accounts in a project
This would be useful for a microservice app, where each microservice would be represented by their own service account.
Granularity is employed by specifying which service accounts are allowed to call which other services.
Steps to use a service account in your application
- Create the service account via the console
- Generate and download your credentials file
- Set an environment var to provide credentials to your app
- Authenticate in your code with the default credentials
Use ADC (App Default Credentials) to authenticate between apps
If you don’t explicitly specify credentials when constructing a client, the client library will look credentials in the environment.
ADC checks for credentials in the following order
- Checks for GOOGLE_APPLICATION_CREDENTIALS environment var
- Checks for default service accounts
- If 1 and 2 aren’t found, it throws an error