============ ============= ====================
In Azure, the equivalents to a GCP service account are Managed Identities and Service Principals. The specific choice depends on the use case, as Azure provides two distinct options where GCP generally uses a single concept.
Azure Equivalents to GCP Service Accounts
Managed Identities: These are recommended for services running within Azure (e.g., on an Azure Virtual Machine, Azure App Service, or Azure Function) that need to authenticate to other Azure resources. Managed Identities simplify authentication by automatically managing credentials through Azure's metadata service, eliminating the need for developers to manage secrets, passwords, or keys.
System-assigned: The identity has a one-to-one relationship with the specific Azure resource and is deleted when the resource is deleted.
User-assigned: The identity is created as a standalone, independent Azure resource and can be assigned to multiple Azure resources.
Service Principals: A service principal is the non-human identity used by applications, services, and automation tools to access Azure resources, typically when running outside of Azure or when a managed identity is not an option (e.g., on-premises applications, CI/CD pipelines). They require the management of credentials, such as client secrets or certificates. Creating an App Registration in Microsoft Entra ID (formerly Azure AD) will create an associated service principal.
============ ============== ===================
Service accounts are a special type of Google account that grant permissions to virtual machines instead of end users. Service accounts are primarily used to ensure safe, managed connections to APIs and Google Cloud services. Granting access to trusted connections and rejecting malicious ones is a must-have security feature for any Google Cloud project.
- Create and manage service accounts.
- Create a virtual machine and associate it with a service account.
- Use client libraries to access BigQuery from a service account.
- Run a query on a BigQuery public dataset from a Compute Engine instance.
What are service accounts?
A service account is a special Google account that belongs to your application or a virtual machine (VM) instead of an individual end user. Your application uses the service account to call the Google API of a service, so that the users aren't directly involved.
For example, a Compute Engine VM may run as a service account, and that account can be given permissions to access the resources it needs. This way the service account is the identity of the service, and the service account's permissions control which resources the service can access.
A service account is identified by its email address, which is unique to the account.
Types of service accounts
- User-managed service accounts
- Google-managed service accounts
- Google APIs service account
User-managed service accounts
When you create a new Cloud project using Google Cloud console and if Compute Engine API is enabled for your project, a Compute Engine Service account is created for you by default. It is identifiable using the email:
PROJECT_NUMBER-compute@developer.gserviceaccount.com
If your project contains an App Engine application, the default App Engine service account is created in your project by default. It is identifiable using the email:
PROJECT_ID@appspot.gserviceaccount.com
Google-managed service accounts
In addition to the user-managed service accounts, you might see some additional service accounts in your project’s IAM policy or in the console. These service accounts are created and owned by Google. These accounts represent different Google services and each account is automatically granted IAM roles to access your Google Cloud project.
Google APIs service account
An example of a Google-managed service account is a Google API service account identifiable using the email:
PROJECT_NUMBER@cloudservices.gserviceaccount.com
This service account is designed specifically to run internal Google processes on your behalf and is not listed in the Service Accounts section of the console. By default, the account is automatically granted the project editor role on the project and is listed in the IAM section of the console. This service account is deleted only when the project is deleted.
Note: Google services rely on the account having access to your project, so you should not remove or change the service account’s role on your project.
Understanding IAM roles
When an identity calls a Google Cloud API, Google Cloud Identity and Access Management requires that the identity has the appropriate permissions to use the resource. You can grant permissions by granting roles to a user, a group, or a service account.
Types of roles
There are three types of roles in Cloud IAM:
Primitive roles, which include the Owner, Editor, and Viewer roles that existed prior to the introduction of Cloud IAM.
Predefined roles, which provide granular access for a specific service and are managed by Google Cloud.
Custom roles, which provide granular access according to a user-specified list of permissions.
student_04_ac2c687f8546@cloudshell:~ (qwiklabs-gcp-02-41dc3caed530)$ gcloud iam service-accounts create ketan-sa-123 --display-name "ketan service account"
Created service account [ketan-sa-123].
student_04_ac2c687f8546@cloudshell:~ (qwiklabs-gcp-02-41dc3caed530)$ gcloud iam service-accounts list | grep ketan
DISPLAY NAME: ketan service account
EMAIL: ketan-sa-123@qwiklabs-gcp-02-41dc3caed530.iam.gserviceaccount.com
student_04_ac2c687f8546@cloudshell:~ (qwiklabs-gcp-02-41dc3caed530)$
Task 1. Create and manage service accounts
When you create a new Cloud project, Google Cloud automatically creates one Compute Engine service account and one App Engine service account under that project. You can create up to 98 additional service accounts to your project to control access to your resources.
Creating a service account
Creating a service account is similar to adding a member to your project, but the service account belongs to your applications rather than an individual end user.
To create a service account, run the following command in Cloud Shell:
gcloud iam service-accounts create my-sa-123 --display-name "my service account"
Granting roles to a service account for specific resources
You grant roles to a service account so that the service account has permission to complete specific actions on the resources in your Cloud Platform project. For example, you might grant the storage.admin role to a service account so that it has control over objects and buckets in Cloud Storage.
Run the following in Cloud Shell to grant roles to the service account you just made:
gcloud projects add-iam-policy-binding $DEVSHELL_PROJECT_ID \
--member serviceAccount:my-sa-123@$DEVSHELL_PROJECT_ID.iam.gserviceaccount.com --role roles/editor
Copied!
The output displays a list of roles the service account now has:
Create a VM instance
Go to Navigation menu > Compute Engine > VM Instances, and click Create Instance.
In the Machine configuration:
Set the following values:
Configuration Value
Name bigquery-instance
Region us-west4
Zone us-west4-b
Series E2
Machine Type e2-medium
Click OS and storage.
If the boot disk is not already set, click Change and select
Boot Disk: Debian GNU/Linux 12 (bookworm)
Click Select.
Click Security.
Set the following values:
Configuration Value
Service account bigquery-qwiklab
Access scopes Set access for each API
BigQuery Enabled
Note: If the bigquery-qwiklab service account doesn't appear in the drop-down list, try typing the name into the "Filter" section.
Click Create.
Put the example code on a Compute Engine instance
Now, you will be able to see the bigquery-instance under VM Instances.
SSH into bigquery-instance by clicking on the SSH button.
Note: While connecting to SSH, you can click on Connect without Identity-Aware Proxy.
Install Python and create a virtual environment by running the following commands:
sudo apt install python3 python3-pip python3.11-venv -y
python3 -m venv myvenv
source myvenv/bin/activate
In the SSH window, install the necessary dependencies by running the following commands:
sudo apt-get update
sudo apt-get install -y git python3-pip
pip3 install --upgrade pip
pip3 install google-cloud-bigquery
pip3 install pyarrow
!pip3 install pandas
pip3 install db-dtypes
Now create the example Python file:
echo "
from google.auth import compute_engine
from google.cloud import bigquery
credentials = compute_engine.Credentials(
service_account_email='YOUR_SERVICE_ACCOUNT')
query = '''
SELECT
year,
COUNT(1) as num_babies
FROM
publicdata.samples.natality
WHERE
year > 2000
GROUP BY
year
'''
client = bigquery.Client(
project='qwiklabs-gcp-02-41dc3caed530',
credentials=credentials)
print(client.query(query).to_dataframe())
" > query.py
Add the Project ID to query.py with:
sed -i -e "s/qwiklabs-gcp-02-41dc3caed530/$(gcloud config get-value project)/g" query.py
Run the following to make sure that the sed command has successfully changed the Project ID in the file:
cat query.py
Example output (yours may differ):
from google.auth import compute_engine
from google.cloud import bigquery
credentials = compute_engine.Credentials(
service_account_email='YOUR_SERVICE_ACCOUNT')
query = '''
SELECT
year,
COUNT(1) as num_babies
FROM
publicdata.samples.natality
WHERE
year > 2000
GROUP BY
year
'''
client = bigquery.Client(
project=qwiklabs-gcp-02-41dc3caed530,
credentials=credentials)
print(client.query(query).to_dataframe())
Add the service account email to query.py with:
sed -i -e "s/YOUR_SERVICE_ACCOUNT/bigquery-qwiklab@$(gcloud config get-value project).iam.gserviceaccount.com/g" query.py
Run the following to make sure that the sed command has successfully changed the service account email in the file:
cat query.py
Example output (yours may differ):
from google.auth import compute_engine
from google.cloud import bigquery
credentials = compute_engine.Credentials(
service_account_email='bigquery-qwiklab@qwiklabs-gcp-02-41dc3caed530.iam.gserviceaccount.com')
query = '''
SELECT
year,
COUNT(1) as num_babies
FROM
publicdata.samples.natality
WHERE
year > 2000
GROUP BY
year
'''
client = bigquery.Client(
project=qwiklabs-gcp-02-41dc3caed530,
credentials=credentials)
print(client.query(query).to_dataframe())
The application now uses the permissions that are associated with this service account. Run the query with the following Python command:
python3 query.py
The query should return the following output (your numbers may vary):
Row year num_babies
0 2008 4255156
1 2006 4273225
2 2003 4096092
3 2004 4118907
4 2002 4027376
5 2005 4145619
6 2001 4031531
7 2007 4324008
Note: Your row values might not map to the years in the above output. However, make sure that the babies per year are the same.
Awesome work! You made a request to a BigQuery public dataset with a bigquery-qwiklab service account.
Use `gcloud config set project [PROJECT_ID]` to change to a different project.
student_04_ac2c687f8546@cloudshell:~ (qwiklabs-gcp-02-41dc3caed530)$ history
1 gcloud auth list
2 gcloud config list
3 gcloud config list project
4 gcloud config list compute
5 gcloud config list compute/region
6 gcloud config set compute/region
7 gcloud config set compute/region --help
8 gcloud config set compute/region us-westd
9 gcloud config set compute/region us-west4
10 gcloud config list compute/region
11 gcloud config list
12 gcloud iam service-accounts create my-sa-123 --display-name "my service account"
13 gcloud iam service-account list
14 gcloud iam
15 gcloud iam roles list
16 gcloud iam service account list
17 gcloud iam service-accounts list
18 gcloud projects add-iam-policy-binding $DEVSHELL_PROJECT_ID --member serviceAccount:my-sa-123@$DEVSHELL_PROJECT_ID.iam.gserviceaccount.com --role roles/editor
19 gcloud iam service-accounts create ketan-sa-123 --display-name "ketan service account"
20 gcloud iam service-account list | grep ketan
21 gcloud iam service-accounts list | grep ketan
22 history
student_04_ac2c687f8546@cloudshell:~ (qwiklabs-gcp-02-41dc3caed530)$
.png)
