Service accounts, IAM roles, and API scopes
Summary
TLDRThis 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
🔐 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.
Mindmap
Keywords
💡Service accounts
💡IAM roles
💡API scopes
💡Compute Engine
💡Principle of least privilege
💡Default service account
💡User-managed service accounts
💡Access scopes
💡Cloud Logging and Cloud Monitoring
💡Project Editor role
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.
تصفح المزيد من مقاطع الفيديو ذات الصلة
Chapter #8 - Cloud IAM Basics | identity & access management on google cloud platform (gcp)
Members
AWS IAM Core Concepts You NEED to Know
Invoke application deployed in Cloud Run from Apigee Proxy
El usuario administrador en Windows / Linux (ISO - 3.1)
Master Google Sheets with Node.js: Read & Write Data Effortlessly!
5.0 / 5 (0 votes)