Google Cloud: Workload Identity Federation

Keyless authentication in the Google Cloud. How Workload Identity Federation replaces the use of service account keys in API authentication.

Starting Point

In an increasingly digitalized working world, cloud-based infrastructures and the automation of workflows are indispensable. Concepts such as Infrastructure as Code (IaC) or version management such as Git are vital for this evolution. For example, IaC allows cloud infrastructures and resources to be defined and managed using code. Paired with a version management platform such as GitHub, this creates an established basic framework for managing a cloud infrastructure.

Authentication to the cloud provider is necessary when managing infrastructure on an external cloud platform such as GitHub. Only after successful authentication can the caller make changes. One of the ways to map and automate this authentication is to use access keys.

In Google Cloud Platform (GCP), these are called service account keys and enable access to resources through a service account. In Amazon Web Services (AWS), these access keys are directly called access keys and provide access to an IAM user.

Service account keys or access keys are long-lived access credentials. The keys are passed along with the API call, authenticating the call. Keys must be securely stored, managed, and periodically changed (rotated). If this key management effort is neglected, this could lead to a security risk.

The GCP and AWS Consoles explicitly point out the associated risks when creating such access keys, as shown in Figures 1 and 2.

To avoid the corresponding risks, another method of authentication can be chosen. In addition to the use of service account keys, an identity federation can be used to which the text in Figure 1 already refers. Inside the Google Cloud, this method is called “Workload Identity Federation”.

What is Workload Identity Federation?

Google Cloud Workload Identity Federation (WIF) provides simple, secure, and keyless authentication for workloads outside of Google Cloud that needs to access Google Cloud resources. With WIF, the existing Identity Provider (IdP) is used to authenticate users and workloads without the need to create and manage Google Cloud specific credentials, such as service account keys.

An Identity Provider is a system that manages digital identities of users. Users can authenticate to the IdP using a username and password, for example, and then access the managed resources. If the IdP is registered as a trust center in the Google Cloud, a so-called identity federation is created between the GCP and the IdP. Registered users in the IdP can then be provided with a corresponding authorization and thus access resources in the Google Cloud. The security risk posed by unregulated management of service account keys and the effort involved in secure storage and rotation are eliminated, since identity federation uses short-lived credentials assigned by the IdP rather than long-lived service account keys.

Using Workload Identity Federation offers the following advantages over service account keys:

• fine-grained scoping
• short-lived credentials
• minimal Management Overhead

Fine-grained scoping

When using service account keys, authentication can only distinguish between allowed access and denied access. With WIF, on the other hand, access can be granted based on attributes like the calling application or the executing user. In this way, a distinction can be made between different applications, even within a registered provider, and access can be precisely regulated.

Short-lived credentials

Unlike service account keys, Workload Identity Federation credentials are short-lived. By default, credentials are valid for one hour, but this period can be extended. The short lifetime significantly reduces the window of opportunity for a potential attacker compared to long-lived service account keys which are valid until the next key-rotation takes place.

Minimal management overhead

Service account keys should be subject to regulated management to keep them secure, rotate them, and use them. This administration effort for the keys is eliminated with WIF since the short-lived credentials do not require rotation or administration. However, the effort of managing fine-grained access control through a proper rights concept stays.

How it works

Authentication at WIF is based on OpenID Connect (OIDC). OICD is an identity protocol that builds on OAuth 2.0 and enables secure and standardized authentication. The applications that use OIDC do not have to manage any credentials themselves, as the process of authentication and identity management is handled by an external identity provider (IdP).

With WIF, this IdP is entered in an identity pool in the Google Cloud as a Google Cloud Workload Identity Provider. This establishes a trust relationship between the Google Cloud and the IdP. Identity pools are the entities in which these trust relationships are managed.

In addition to the Identity Pool, a service account is created, which is used to access the Google Cloud resources. The corresponding permissions are assigned to this service account, which enables access to the resources. To enable the identity pools to access the service account, the pool must be granted the privilege to impersonate the service account.

The preparatory steps for using WIF can be summarized as follows:

1. Activate the “IAM Credentials API”.
2. Create a workload identity pool in the Google Cloud.
   
3. Create a provider in the workload identity pool and establish a trust relationship between the identity pool and an external identity provider.
   
4. Create a service account and assign privileges.
   
5. Assign permissions to the identity pool to impersonate the service account.
   

Authentication process

If Workload Identity Federation has been successfully set up, authentication can now proceed without a key. The following figure illustrates how the call from an external workload is authenticated.

1. Prerequisites

Preparation and setup of the workload identity provider and service account.

2. Authentication Identity Provider

The workload authenticates with the Identity Provider and receives an OIDC token from it.

3. Authentication Google Cloud

The workload uses the OIDC token received from the identity provider when authenticating to Google Cloud. The Security Token Service (STS) matches this with the information stored in the identity pool. If the identity provider is entered accordingly and the attributes of the workload allow access, the STS returns short-lived credentials.

4. Access to Google Cloud resources

The short-lived credentials issued by the Security Token Service (STS) can be used to impersonate a service account. Google Cloud resources can then be accessed via this service account if the necessary permission has been granted.

Sample scenario

The following scenario shows the functionality and in particular the authentication process based on an example. The scenario shows the setup of workload identity federation in conjunction with GitHub and authentication in a workload.

The access to Google Cloud resources is done from a GitHub Action. GitHub Actions is a Continuous Integration/Continuous Delivery (CI/CD) solution that automates software workflows in GitHub. For the authentication process, the GitHub Action google-github-actions/auth is used. The usage of this action is built into your own GitHub Actions workflow as follows:

The name of the identity pool is entered as the workload_identity_provider attribute and the name of the service account to be used for access is entered as the service_account attribute.

To prepare on the Google Cloud side, the following steps were conducted to set up Workload Identity Federation in the Google Cloud:

1. Activate the “IAM Credentials API” in the Google Cloud.
2. Create a service account and assign the required permission to that account.
3. Create a workload identity pool.
4. Establishing a trust relationship between the identity pool and the GitHub OIDC provider (IdP). Add relevant attributes such as the name of the repository or the username of the executor into the relationship entry.
5. Assigning permissions to the identity pool, here is the privilege to impersonate a service account.

1. Authentication Google Cloud

The GitHub Action uses the OIDC token obtained from the GitHub OIDC provider to authenticate to the Google Cloud – in detail the Security Token Service (STS).

2. Compare the information with the identity pool

The Security Token Service (STS) matches the received attributes as well as the OIDC token with the information stored in the identity pool. If the identity provider is entered appropriately and the attributes of the workload allow access, the STS returns short-lived credentials. The attributes in the example are information like the repository name, the username, or the event type. Through this information, the fine-grained access control is reflected, as only workloads with the stored attributes are granted access.

3. Access Google Cloud resources

The short-lived credentials issued by the Security Token Service (STS) can be used to access a service account (Impersonate Service Account). Google Cloud resources can then be accessed via this service account if the necessary permission has been granted.

Conclusion

Workload Identity Federation provides a way to authenticate cloud-external workloads, in addition to the traditional use of service account keys, to enable access to cloud-internal resources. This simplifies the authentication process and improves security by cutting the need for long-lived and administratively complex service account keys. Integration with existing workloads is simplified with pre-built workloads. The transition to workload identity federation can also be done incrementally on a per-workload basis. ORDIX AG will be happy to support you in this endeavor. Simply get in touch with us.