How To Create And Manage Service Account In GCP
Hello Everyone
Welcome to CloudAffaire and this is Debjeet.
In the last blog post, we have discussed cloud IAM roles in GCP.
https://cloudaffaire.com/how-to-create-a-custom-iam-role-in-gcp/
In this blog post, we are going to discuss the service account in GCP.
What are service accounts?
A service account is a special kind of account used by an application or a virtual machine (VM) instance, not a person. Applications use service accounts to make authorized API calls.
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.
Note: A service account is identified by its email address, which is unique to the account.
Service account features:
- Service accounts do not have passwords, and cannot log in via browsers or cookies.
- Service accounts are associated with private/public RSA key-pairs that are used for authentication to Google.
- Cloud IAM permissions can be granted to allow other users (or other service accounts) to impersonate a service account.
- Service accounts are not members of your G Suite domain, unlike user accounts. For example, if you share assets with all members in your G Suite domain, they will not be shared with service accounts. Similarly, any assets created by a service account cannot be owned or managed by G Suite admins.
Service account keys:
Each service account is associated with two sets of public/private RSA key pairs that are used to authenticate to Google: Google-managed keys, and user-managed keys.
- Google-managed keys: Google-managed key pairs imply that Google stores both the public and private portion of the key, rotates them regularly (each key can be used for signing a maximum of two weeks), and the private key is always held in escrow and is never directly accessible. Cloud IAM provides APIs to use these keys to sign on behalf of the service account.
- User-managed keys: User-managed key pairs imply that you own both the public and private portions of a key pair. You can create one or more user-managed key pairs (also known as “external” keys) that can be used from outside of Google Cloud. Google only stores the public portion of a user-managed key. The private portion of a user-managed key pair is most commonly used with Application Default Credentials. The private key is then used to authenticate server-to-server applications.
Types of service accounts:
- User-managed service accounts: When you create a new Google Cloud project using the Cloud Console, if the 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
- 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 Cloud 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. An example of a Google-managed service account is a Google API service account identifiable using the email:
PROJECT_NUMBER@cloudservices.gserviceaccount.com
Service account permissions:
In addition to being an identity, a service account is a resource that has IAM policies attached to it. These policies determine who can use the service account.
For instance, Alice can have the editor role on a service account and Bob can have the viewer role on a service account. This is just like granting roles for any other Google Cloud resource.
The default Compute Engine and App Engine service accounts are granted editor roles on the project when they are created so that the code executing in your App or VM instance has the necessary permissions. In this case the service accounts are identities that are granted the editor role for a resource (project).
If you want to allow your application to access a Cloud Storage bucket, you grant the service account (that your application uses) the permissions to read the Cloud Storage bucket. In this case the service account is the identity that you are granting permissions for another resource (the Cloud Storage bucket).
The Service Account User role:
You can grant the Service Account User role (roles/iam.serviceAccountUser) at the project level for all service accounts in the project, or at the service account level.
Granting the Service Account User role to a user for a project gives the user access to all service accounts in the project, including service accounts that may be created in the future.
Granting the Service Account User role to a user for a specific service account gives a user access to only that service account.
Users granted the Service Account User role on a service account can use it to indirectly access all the resources to which the service account has access. For example, if a service account has been granted the Compute Admin role (roles/compute.admin), a user that has been granted the Service Account Users role (roles/iam.serviceAccountUser) on that service account can act as the service account to start a Compute Engine instance. In this flow, the user impersonates the service account to perform any tasks using its granted roles and permissions.
Short-Lived Service Account Credentials:
You can create short-lived credentials that allow you to assume the identity of a Google Cloud service account. These credentials can be used to authenticate calls to Google Cloud APIs or other non-Google APIs.
The most common use case for these credentials is to temporarily delegate access to Google Cloud resources across different projects, organizations, or accounts. For example, instead of providing an external caller with the permanent credentials of a highly-privileged service account, temporary emergency access can be granted instead. Alternatively, a designated service account with restricted permissions can be impersonated by an external caller without requiring a more highly-privileged service account’s credentials.
How To Create And Manage Service Account In GCP:
Step 1: Create and manage a service account in GCP.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 |
######################################## ## Google Cloud IAM - Service Account ## ######################################## ## Prerequisite: gcloud installed and configured ## https://cloudaffaire.com/gcloud-installation-and-configuration/ ##---------------------------------- ## Create and manage service account ##---------------------------------- ## Create a service account gcloud iam service-accounts create myserviceaccount \ --description "demo service account" \ --display-name "myserviceaccount" ## List all available service account gcloud iam service-accounts list ## NAME EMAIL DISABLED ## myserviceaccount myserviceaccount@cloudaffaire.iam.gserviceaccount.com False ## Get details for your service account gcloud iam service-accounts describe \ myserviceaccount@cloudaffaire.iam.gserviceaccount.com ## Note down the uniqueID for your service account ## uniqueId: '109752292927015108535' ## Rename a service account gcloud iam service-accounts update \ myserviceaccount@cloudaffaire.iam.gserviceaccount.com \ --description "updated demo service account" \ --display-name "myserviceaccountupdated" ## Disable a service account gcloud iam service-accounts disable myserviceaccount@cloudaffaire.iam.gserviceaccount.com ## Enable a service account gcloud iam service-accounts enable myserviceaccount@cloudaffaire.iam.gserviceaccount.com ## Delete a service account gcloud iam service-accounts delete myserviceaccount@cloudaffaire.iam.gserviceaccount.com ## Undeleting a service account ## Prerequisites: ## The service account was deleted less than 30 days ago. ## There is no existing service account with the same name as the deleted service account. gcloud beta iam service-accounts undelete |
Step 2: Create and manage service account keys.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 |
##------------------------------------------- ## Creating and managing service account keys ##------------------------------------------- ## Create a key for your service account ## Note: Keep the key in secure location gcloud iam service-accounts keys create mykey.json \ --iam-account myserviceaccount@cloudaffaire.iam.gserviceaccount.com ## View the content of the key cat mykey.json ## Note down the private_key_id ## "private_key_id": "d003hsfdfsdfdysgygyugu3d360ffae719d" ## List all available key's in a service account gcloud iam service-accounts keys list \ --iam-account myserviceaccount@cloudaffaire.iam.gserviceaccount.com ## Delete your service account key gcloud iam service-accounts keys delete d003be88f61c75c381515fd68a04d360ffae719d \ --iam-account myserviceaccount@cloudaffaire.iam.gserviceaccount.com && rm -f mykey.json |
Step 3: Create and manage service account permissions.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 |
##-------------------------------------------------- ## Creating and managing service account permissions ##-------------------------------------------------- ## Grant a premitive role to a service account (service account is treated as identity) gcloud projects add-iam-policy-binding cloudaffaire \ --member serviceAccount:myserviceaccount@cloudaffaire.iam.gserviceaccount.com \ --role roles/editor ## Grant an user editor role to a service account (service account is treated as resource) gcloud iam service-accounts add-iam-policy-binding \ myserviceaccount@cloudaffaire.iam.gserviceaccount.com \ --member='user:debjeet@gmail.com' --role='roles/editor' ## Check current policy assosiated with the service account gcloud iam service-accounts get-iam-policy \ myserviceaccount@cloudaffaire.iam.gserviceaccount.com \ --format json ## Remove the policy from the service account gcloud iam service-accounts remove-iam-policy-binding \ myserviceaccount@cloudaffaire.iam.gserviceaccount.com \ --member='user:debjeet@gmail.com' --role='roles/editor' ## Remove the role from the service account gcloud projects remove-iam-policy-binding cloudaffaire \ --member serviceAccount:myserviceaccount@cloudaffaire.iam.gserviceaccount.com \ --role roles/editor ## Delete the service account gcloud iam service-accounts delete \ myserviceaccount@cloudaffaire.iam.gserviceaccount.com |
Hope you have enjoyed this article. In the next blog post, we will discuss policy in Cloud IAM.
All the public cloud providers are changing the console user interface rapidly and due to this some of the screenshots used in our previous AWS blogs are no longer relevant. Hence, we have decided that from now onwards most of the demo will be done programmatically. Let us know your feedback on this in the comment section.
To get more details on cloud IAM service account, please refer below GCP documentation.
https://cloud.google.com/iam/docs/
https://cloud.google.com/iam/docs/service-accounts
https://cloud.google.com/iam/docs/creating-managing-service-accounts
https://cloud.google.com/iam/docs/creating-managing-service-account-keys
https://cloud.google.com/iam/docs/granting-roles-to-service-accounts