GCP Service Account Usage Guide and Best Practices
Introduction
Basics
Service account are programmatic users in GCP which provides an identity for applications to impersonate as service account while consuming google services.
Service account keys
Google identity authenticates service account using a service account key. There are two types of service account keys.
- Google managed service account key. Where we users or application don’t have an access to the key and it’s lifecycle is managed by google.
- User managed service account key. These are created by users and used to authenticate as service account against google identity provider and lifecycle has to be managed by users.
When any Application is being onboarded in GCP or outside which has to consume any google services, App developers have to decide how to authenticate to google services and how to avoid any key or password.
Use case
Applications want to authenticate against google cloud services like google cloud storage, BigQuery etc.
Google Cloud requires the application to authenticate with a programmatic user to prove its identity and only then it will go ahead and provide the required access.
Google Cloud provides various different ways to authenticate and this link provides all details.
Ways to Authenticate against google cloud services, Decision Tree:-
Source :- https://cloud.google.com/iam/docs/best-practices-service-accounts#choose-when-to-use
The above diagram is a simplified version and attempts to provide the options to authenticate from an application based on where it is running.
Components
- Application
Applications that we are referring to here are the ones which want to utilize google cloud services and APIs
- Application Type
Application can be in house or application can be a third party application.
- Infrastructure location.
Applications can run on GCP cloud or non-gcp environments. Non-GCP can include AWS, Azure or On-prem data centers.
Options
Below is the summary of the options available to authenticate.Detailed information is provided about them in the Developer’s guide section.
Developers Guide
If you are a developer and looking to integrate an application with google services and API’s, then the below guide will help you. We will start with some concepts and then ways to authenticate to google services.
Google APIs and Services Authentication
Google APIs implement and extend the OAuth 2.0 framework. The OAuth 2.0 framework outlines various authentication “flows” or authentication approaches. Generally, the application presents credentials, which represent a principal (either a user or a service account), to an intermediate module called an Authorization Server. The Authorization Server responds with a token, which the application can use to authenticate with the service and access resources
Google APIs and Services Authorization
Google Cloud services use Identity and Access Management (IAM) for authentication. IAM offers granular control, by principal and by resource. When you authenticate to Google Cloud services, you generally use a scope that includes all Google Cloud services (https://www.googleapis.com/auth/cloud-platform).
Users authenticate using password and some kind of multi factor authentication option.
Application Default Credentials
ADC is a strategy used by Cloud Client Libraries and Google API Client Libraries to automatically find credentials based on the application environment, and use those credentials to authenticate to Google Cloud APIs. When you set up ADC and use a client library, your code can run in either a development or production environment without changing how your application authenticates to Google Cloud services and APIs.
If you are writing code that needs to use Google Cloud services, you should use ADC whenever possible. Using ADC can simplify your development process, because it lets you use the same authentication code in a variety of environments including google cloud compute engine, cloud run , cloud function, app engine etc.
Usage
Cloud Client Libraries and Google API Client Libraries.
Workload Identity is the recommended way for your workloads running on Google Kubernetes Engine (GKE) to access Google Cloud services in a secure and manageable way.
Applications running on GKE might need access to Google Cloud APIs such as Compute Engine API, BigQuery Storage API, or Machine Learning APIs.
Workload Identity allows a Kubernetes service account in your GKE cluster to act as an IAM service account. Pods that use the configured Kubernetes service account automatically authenticate as the IAM service account when accessing Google Cloud APIs. Using Workload Identity allows you to assign distinct, fine-grained identities and authorization for each application in your cluster.
Usage
Please refer to the quick start mentioned here.
Workload Identity Federation
If your application runs on-premises or on another cloud provider, then you cannot attach a service account to the underlying compute resources. However, the application might have access to environment-specific credentials such as:
- AWS temporary credentials.
- Azure AD access tokens.
- OpenID access tokens or ID tokens issued by an on-premises identity provider like AD FS or KeyCloak
If your application has access to one of these credentials and needs access to Google Cloud APIs or resources, use workload identity federation.
Workload identity federation lets you create a one-way trust relationship between a Google Cloud project and an external identity provider. Once you’ve established that trust, applications can use credentials issued by the trusted identity provider to impersonate a service account by following a three-step process:
- Obtain a credential from the trusted identity provider, for example an OpenID Connect ID token.
- Use the STS API to exchange the credential against a short-lived Google STS token.
- Use the STS token to authenticate to the IAM Credentials API and obtain short-lived Google access tokens for a service account.
By using workload identity federation, you can let applications use the native authentication mechanisms that the external environment provides, and you avoid having to store and manage service account keys.
Pre-requisites
Oauth (ID Tokens) should be available to authenticate for Application. Application developers should be able to make the necessary changes to retrieve the credentials from the IDP and then present it to google sts to get the token to authenticate and authorize against google cloud services.
Flow
This section will cover the detailed flow for all different use cases of Workload identity.
AWS/Azure (STS)
Here is the flow for STS based service :-
The high level flow is like
- Acquire ambient AWS|OIDC|Azure credentials.
- Exchange that ambient token with Google for an intermediate federated token
- Depending on the service:
If the service you are accessing on GCP accepts the federated token, use it directly. (this is federated)
If the service you are accessing does not accept federated tokens, exchange the federated token for a GCP Service Account token. Use the Service Account token to access GCP (this is impersonated)
Disclaimer:- References have been taken from this link.
For AWS, consider getting ambient credentials directly using env-vars or ambient credentials
Usage/Sample
Reference
- Exchange AWS Credentials for GCP Credentials using GCP STS Service.
- OIDC/SAML (With ADFS/ON-PREM AD, or OTKA) :-
Active Directory users can use OIDC access tokens from Active Directory Federation Services (AD FS) to impersonate a service account on Google Cloud.
Usage :- Steps are documented here.
Service Account Key (Last choice)
If you cannot use user credentials for local development, you can use a service account key.
If your organization policy has a constraint that prevents creating a service account key, then this method is unavailable to you. So would you need to ask for security exemption and then request for org policy for service account key creation to be relaxed.
Note: Creating a service account key is a security risk that should be avoided if possible. If you must create a service account key, make sure you keep it secure. Anyone with access to the key can gain all of the access that’s granted to the associated service account. For more information, see Best practices for managing service account keys.
Implementation
To create a service account key and make it available to ADC:
Create a service account with the roles your application needs, and a key for that service account, by following the instructions in Creating a service account key.
Set the GOOGLE_APPLICATION_CREDENTIALS environment variable to the location of the key.
Note: When you set the GOOGLE_APPLICATION_CREDENTIALS environment variable, ADC checks this location first, then checks other locations only if necessary.
Security Measure
- Service accounts should only have limited access. Service accounts will not be provided with predefined or basic roles like owner/editor/viewer.
- It will be provided with least privilege access depending on the resources it needs.
- Service account user access should be provided on need basis only.
- Every service account should have a application owner responsible for it.
- Service account should follow naming convention and should have proper description.
- Any changes to service account should be audited and alerted and reviewed periodically.
- Rotate service account key.
A. Manually
- It’s very important to understand that the key will need to be rotated every 90 days. Inform to Application owner regarding the key rotation. Generate a new service account key if the key reaches 90 days.
- Share the new key to Application owner Disable the key and ensure the application continues to run.
- Then post 7 days delete the old key after getting confirmation from the application owners that jobs are fine with the new service account key.
B. Automatically :- You can use third party tools like hashicorp vault to create short lived service account key and then rotate it.
Store securely
Also the key should be stored in Secret manager and accessed via it (Code changes will be required).
It is the application owner’s responsibility to store the keys securely.
Auditing
Auditing of service account key and its last login is possible.
Asset inventory can be used to check how many service account have user managed service account key.
Hope this post helps provide insight into using service account to authenticate and authorise when using google services.
For more information, please get in touch with us and we will help you further.
