New documentation and tool support for authenticating to Google Cloud from an Active Directory environment
When an on-premises application needs to access Google Cloud, it’s tempting to just let it use a service account key. But if the application runs in an Active Directory environment and has domain credentials, there’s a better alternative: we can let it use its NTLM or Kerberos credentials and “exchange” them against Google credentials.
To exchange Active Directory credentials against short-lived Google Cloud credentials, the application needs to chain two token exchanges:
- First, the application uses integrated Windows authentication (IWA) and its existing Active Directory credentials to authenticate to AD FS and obtain an OIDC token or SAML assertion.
- Then, the application uses workload identity federation to exchange the AD FS-issued OIDC token or SAML assertion against a Google token and, optionally, to impersonate a Google Cloud service account.
Up until recently, this approach required custom code. That was tedious and more importantly, it meant that the approach did not work for any third-party applications that we can’t modify.
Fortunately, things have evolved and most Google Cloud client libraries now support executable-sourced credentials: This feature lets us configure the client libraries to invoke a custom binary every time they need to authenticate. The binary can then obtain an external token in whatever way it sees fit and return it to the client library. The library then exchanges that external token against short-lived Google credentials by using workload identity federation.
Using executable-sourced credentials not only works for our own applications, but also for third-party applications that use the Google client libraries – it’s like a plugin mechanism that lets us “plug” our own authentication mechanism to existing apps.
This new mechanism allowed me to implement and publish a new tool, the Workload Authenticator for Windows.
Workload Authenticator for Windows
The Workload Authenticator for Windows (WWAuth) is a Windows executable that we can use as plugin for
terraform, and other applications to let them authenticate to Google Cloud using Active Directory credentials.
It works like this:
- We configure an application to use WWAuth by pointing the environment variable
GOOGLE_APPLICATION_CREDENTIALSto an WWAuth-enabled credential configuration file (more on that later).
- The credential configuration file instructs the application’s client library (which is built into the application) to invoke WWAuth every time it needs to authenticate to Google Cloud. This is the executable-sourced credentials mechanism described earlier.
- When invoked by the client library, WWAuth uses the current Windows user’s Kerberos (or NTLM) credentials to authenticate to AD FS, and returns an OIDC token or SAML assertion back to the client library.
- The client library exchanges the token or assertion against short-lived Google credentials by using workload identity federation.
- The application uses the short-lived Google Credentials to access resources on Google Cloud.
WWAuth includes a user interface that lets us create and edit a WWAuth-enabled credential configuration file:
The user interface also includes the option to test the configuration and check for common misconfigurations:
For more details on how to set up AD FS and workload identity federation with WWAuth, see my new article Configure workload identity federation with Active Directory in the Google Cloud IAM docs.