One of the challenges engineers face is the management, protection, distribution and renewal of Service Account keys.
The best way to reduce the security risks associated with this is not to use them.
While researching how to use Workload Identity Federation with GitLab CI, I came across this article from GitLab that explains how to configure OpenID Connect with GCP’s Workload Identity Federation. After the configuration, I realized that there are several ways to exploit the credential json file provided by Workload Identity Federation. In order to better understand this, we will perform two tests which are shown below.
Case 1: Use gsutil
For the test, we will follow the steps defined in this article 👇.
Configure OpenID Connect with GCP Workload Identity Federation | GitLab
This tutorial demonstrates authenticating to Google Cloud from a GitLab CI/CD job using a JSON Web Token (JWT) token…
Regarding the Service Account linked to Workload Identity Federation, we will assign the following roles to it 👇.
Here is the result of March 08, 2022 👇👇👇
As you can see, we have a 401 error message indicating that we do not have
storage.objects.list access to the Google Cloud Storage bucket. However, our Service Account has the Storage Object Admin role. Now let’s move on to the second test.
Here are the results for March 31, 2022 👇👇👇
Case 2: Python client library
Here we will use python code to exploit the json file provided by Workload Identity Federation.
Here is the result 👇👇👇
As you can see, everything works fine with the same configurations we used in the first test.
What you need to understand here is that
terraform supports Workload Identity Federation as well as the python and Go client libraries. It work with Terraform which supports the environment variable
For the record, I got the idea to write this article after a discussion with guillaume blaquiere who told me to avoid using Services Account for security reasons. He advised me to use Workload Identity Federation.