Service accounts, IAM roles, and API scopes

Summary

This video script discusses service accounts in Google Cloud, focusing on their use for API requests by VM instances. It highlights the importance of assigning minimal necessary permissions using IAM roles and access scopes. The default service account, with Project Editor role, is automatically created but can be limited using access scopes. The script advises against granting full API access, recommending instead the selection of specific API scopes needed by applications, adhering to the principle of least privilege.

Takeaways

• 🔑 **Service Accounts**: A service account is an identity that resources like VM instances can use to authenticate API requests on behalf of the user.
• 💻 **VM Association**: When launching a VM in Compute Engine, a service account can be directly associated with it to authenticate API calls.
• 🚫 **No Service Account Association**: Specifying no service account means that API requests on the VM will not have a default identity and must be manually configured.
• 🛡️ **Principle of Least Privilege**: It's crucial to assign roles and permissions to service accounts with minimal necessary access to safeguard resource management.
• 🆓 **Default Service Account**: Every project has a default service account created when Compute Engine is enabled, initially assigned the Project Editor role.
• 👤 **User-Managed Service Accounts**: Users can create and manage service accounts with specific permissions through IAM roles, providing granular access control.
• 🚫 **No Role, No Access**: Service accounts without assigned roles have no access to services, emphasizing the need for explicit permission granting.
• 🔗 **IAM Roles vs. Access Scopes**: While IAM roles control permissions for user-managed service accounts, access scopes are used for the default service account to limit API access.
• 📋 **Access Scopes**: Access scopes apply on a per-instance basis and must be configured when launching an instance under the default service account.
• ❌ **Avoid Full Access**: Granting full access to all Cloud APIs violates the Principle of Least Privilege and is not recommended.
• ✅ **Selective API Access**: Best practice is to grant access to only the APIs required by the application running on the VM, enhancing security and adherence to best practices.

Q & A

What is a service account in the context of Google Cloud?

A service account is an identity that a resource, such as a VM instance, can use to run API requests on your behalf.

How is a service account associated with a VM instance in Google Compute Engine?

A service account can be associated directly with a VM instance when launching it in Compute Engine.

What happens if no service account is specified for a VM instance?

If no service account is specified, API requests running on the VM will not assume a service account identity by default and would need to be manually configured.

Why is it important to assign roles and permissions to service accounts using the principle of least privilege?

Service accounts control how resources are managed and used, so assigning them roles and permissions with the principle of least privilege ensures that they only have the necessary access to perform their intended functions, minimizing security risks.

What is the role assigned to the default service account in a Google Cloud project?

The default service account is assigned the role of Project Editor when Compute Engine is first enabled for the project.

How can you create and manage your own service accounts in Google Cloud?

You can create and manage your own service accounts using Identity and Access Management (IAM), where you can assign necessary permissions by granting roles.

What is the difference between user-managed service accounts and the default service account in terms of access control?

User-managed service accounts do not use the 'access scope' concept and instead have permissions controlled through IAM roles assigned to the account, whereas the default service account uses access scopes to control permissions.

What are access scopes and why are they still important even with IAM roles?

Access scopes are a mechanism for granting permissions to service accounts, and they are still important because they apply on a per-instance basis and must be configured when initiating an instance to run under the default service account.

What does 'Allow default access' provide in terms of permissions for a VM instance?

The 'Allow default access' scope provides read-only access to Cloud Storage, as well as access to Cloud Logging and Cloud Monitoring, but restricts access to other APIs.

What are the drawbacks of choosing 'allow full access' for a VM instance's service account?

Choosing 'allow full access' grants full access to all Cloud APIs, which violates the Principle of Least Privilege and is not a best practice due to the potential security risks.

What is the recommended practice when setting access scopes for a VM instance that requires access to specific APIs?

The recommended practice is to set each API access required individually, granting access only to the APIs necessary for the programs running on the VM, which adheres to the Principle of Least Privilege.

Outlines

00:00

🔐 Service Accounts and IAM Roles

Service accounts are identities used by resources like VM instances to make API requests on behalf of users. When launching a VM in Compute Engine, a service account can be associated with it, allowing the VM to authenticate API calls using that service account's identity. It's crucial to assign roles and permissions to service accounts following the principle of least privilege. Projects have a default service account with the Project Editor role, but user-managed service accounts can be created with specific permissions through IAM. These accounts do not use the 'access scope' concept but instead have permissions controlled by IAM roles. Applications on instances can use the service account's identity to make authenticated API requests.

Keywords

💡Service accounts

Service accounts are a type of identity used by resources, such as virtual machine (VM) instances, to authenticate and make API requests. In the context of the video, service accounts are integral to managing how VMs interact with Google Cloud APIs. The script mentions that when launching a VM in Compute Engine, a service account can be directly associated with it, allowing the VM to use the service account's identity for API calls.

💡IAM roles

IAM stands for Identity and Access Management, and IAM roles define the permissions that a service account or user has within a Google Cloud project. The video emphasizes the importance of assigning roles using the principle of least privilege to control how resources are managed and used. IAM roles are crucial for ensuring that service accounts have only the necessary permissions to perform their intended functions, as illustrated by the default service account being assigned the Project Editor role.

💡API scopes

API scopes determine the level of access that a service account has to Google Cloud APIs. The video explains that access scopes can limit what permissions are allowed when using the default service account, which is particularly important when considering security and the principle of least privilege. The script outlines different access scope options, such as 'Allow default access', 'Full access', and customizing access to specific APIs.

💡Compute Engine

Compute Engine is a Google Cloud service that allows users to create and run virtual machines. In the video, Compute Engine is mentioned as the platform where service accounts are associated with VMs. The service account's identity is used by the VM for authentication when making API requests, highlighting the interplay between Compute Engine and service accounts in managing cloud resources.

💡Principle of least privilege

The principle of least privilege is a security concept where users are granted the minimum level of access necessary to perform their job functions. The video script emphasizes this principle when discussing the assignment of IAM roles to service accounts, advocating for 'necessary' permissions to limit potential security risks. This principle is exemplified by the recommendation to avoid granting full API access and instead customize access scopes.

💡Default service account

Every Google Cloud project has a default service account that is automatically created when Compute Engine is first enabled. The video script explains that this account is assigned the Project Editor role by default, which can be dangerous if used without restriction. It also mentions that access scopes are configured for the default service account, which is a critical step in managing permissions on a per-instance basis.

💡User-managed service accounts

User-managed service accounts are created and managed by users through Identity and Access Management. The video script differentiates these from the default service account by noting that they do not use the 'access scope' concept. Instead, permissions for user-managed service accounts are controlled through IAM roles assigned to the account, providing users with full control over the permissions of these accounts.

💡Access scopes

Access scopes are a mechanism for granting permissions to service accounts, particularly the default service account. The video script discusses how access scopes can be configured when initiating an instance, with options ranging from 'Allow default access', which provides read-only access to Cloud Storage and access to Cloud Logging and Monitoring, to 'Full access', which is discouraged due to security concerns. Customizing access scopes allows for a more granular control over API access.

💡Cloud Logging and Cloud Monitoring

Cloud Logging and Cloud Monitoring are Google Cloud services mentioned in the context of default access scopes. These services are part of the limited set of APIs accessible under the 'Allow default access' scope. The video script uses these services as examples to illustrate the restricted but necessary permissions that can be granted to service accounts for basic operational monitoring and logging.

💡Project Editor role

The Project Editor role is an IAM role that contains permissions to create and delete resources for most Google Cloud services. The video script warns that using this role without restrictions can be dangerous, as it grants broad permissions. It is recommended to use this role with caution and to limit its use in accordance with the principle of least privilege.

Highlights

Service accounts are identities for resources like VM instances to run API requests.

Service accounts can be associated directly with VMs in Compute Engine.

VMs use the service account's identity for authentication when making API calls.

It's possible to specify no service account association for a VM.

Without a service account, VMs need manual configuration for API requests.

Service accounts should be assigned roles and permissions following the principle of least privilege.

Every project has a default service account created when Compute Engine is enabled.

The default service account is assigned the Project Editor role by default.

User-managed service accounts can be created and managed via Identity and Access Management.

User-managed service accounts are granted necessary permissions by assigning IAM roles.

If no roles are granted, the service account has no access to services.

New service accounts can be assigned to instances like the default service account.

User-managed service accounts do not use the access scope concept.

IAM roles control permissions for user-managed service accounts.

Applications on instances can make authenticated requests using the service account identity.

The IAM Project Editor role contains permissions for creating and deleting resources.

Access scopes limit permissions for the default service account with the Project Editor role.

Access scopes were the only mechanism for granting permissions before IAM roles.

Access scopes must be configured when initiating an instance under the default service account.

Access scopes apply only on a per-instance basis and persist for the life of the instance.

Access scopes can be set to 'Allow default access' for read-only access to Cloud Storage and access to logging and monitoring.

VMs may require access to APIs not included in the default access scope, leading to security errors.

The 'allow full access' option grants full access to all Cloud APIs, violating the Principle of Least Privilege.

It's best practice to set each API access required individually for the default service account.

Transcripts

OK, let’s get started with Service accounts, IAM roles and API scopes.

Service accounts are an identity that a resource such as a VM instance can use to run API requests

on your behalf.

When launching a virtual machine in Compute Engine, a service account can be associated

directly to that VM.

When a service account is specified, the VM authenticates using the identity of that service

account when making calls to the Google APIs.

It also possible to specify no service account association.

In that case, API requests running on the VM will not assume the service account identity

by default and would therefore need to be manually configured.

Since service accounts control how resources are managed and used, it’s very important

that you provide them roles and permissions using the principle of least privilege.

Every project has a default service account that is automatically created when Compute

Engine is first enabled for the project.

In this instance the service account is assigned the role of Project Editor and is used by

default when launching VMs.

You can also create and manage your own service accounts using Identity and Access Management.

These user-managed service accounts are granted “necessary” permissions just like any

member in IAM - by assigning roles.

This gives you full control over exactly which permissions the service account will have.

If you do not grant any roles, the service account will not have any access to services.

When you create a new service account, it can be assigned to instances in exactly the

same way as the default service account.

The only difference is user-managed service accounts do not use the “access scope”

concept, which we’ll cover in the next slide.

Instead, permissions are controlled through the IAM roles assigned to the account.

Applications running on instances associated with the service account can make authenticated

requests to other Google APIs using the service account identity.

The IAM Project Editor role contains permissions to create and delete resources for most Google

Cloud services and can be dangerous to use as-is.

Access scopes provide the ability to limit what permissions are allowed when using the

default service account containing this role.

Before the existence of IAM roles, access scopes were the only mechanism for granting

permissions to service accounts.

Although they are not the primary way of granting permissions now, you must still configure

access scopes when initiating an instance to run under the default service account.

It is important to remember that access scopes only apply on a per-instance basis.

You set access scopes when creating an instance and the access scopes persists only for the

life of the instance.

There are several options when setting access scopes.

The first is called “Allow default access”.

The default access scope is actually very narrow and allows read-only access to Cloud

Storage, as well as access to Cloud Logging and Cloud Monitoring.

Other API access using the default service account will obviously be restricted.

Consider the situation where your VMs need access to other APIs, such as BigQuery, Datastore,

Cloud SQL, Pub/Sub, or Cloud Bigtable.

The default access scope does not include these APIs and would cause a security error

when accessing these, or other APIs not included in scope.

The next access scope option is to “allow full access”.

This grants full access to all Cloud APIs.

Choosing this option would violate the Principle of Least Privilege, and therefore is definitely

NOT a best practice!

There is another option, and that is to set the each API access required individually.

This will allow you to grant access to only the APIs required by the programs running

on the VM.

You can choose only the scopes required by your application.

If you are using the default service account, then this is a much better practice than granting

full API access.