At Google Cloud, we’re focused on giving customers new ways to strengthen their security posture. Many organizations use service account keys to authenticate for Google Cloud Platform API access, but managing keys can be challenging, especially in multi-cloud scenarios. To help, last year we launched Workload Identity Federation, which allows workloads running on-premises or in other clouds to federate with an external identity provider (IdP) and call Google Cloud resources without using a service account key.

Initially, we supported federating workloads via the Open ID Connect (OIDC) authentication protocol. We are excited to announce today that support for SAML federation is also generally available. Now, customers who use a SAML-based identity provider are able to take advantage of Workload Identity Federation to reduce their use of long-lived service account keys.

Partner with aster.cloud
for your next big idea.
Let us know here.

From our partners:

CITI.IO :: Business. Institutions. Society. Global Political Economy.

CYBERPOGO.COM :: For the Arts, Sciences, and Technology.

DADAHACKS.COM :: Parenting For The Rest Of Us.

ZEDISTA.COM :: Entertainment. Sports. Culture. Escape.

TAKUMAKU.COM :: For The Hearth And Home.

ASTER.CLOUD :: From The Cloud And Beyond.

LIWAIWAI.COM :: Intelligence, Inside and Outside.

GLOBALCLOUDPLATFORMS.COM :: For The World's Computing Needs.

FIREGULAMAN.COM :: For The Fire In The Belly Of The Coder.

ASTERCASTER.COM :: Supra Astra. Beyond The Stars.

BARTDAY.COM :: Prosperity For Everyone.

How to set up Workload Identity Federation with SAML

You can configure Workload Identity Federation with SAML in much the same way as you configure federation with OIDC today. The only difference is that you use the following command to create your SAML provider:

gcloud iam workload-identity-pools providers create-saml PROVIDER_ID \
    --location="global" \
    --workload-identity-pool="POOL_ID" \
    --idp-metadata-path="IDP_METADATA_PATH" \
    --attribute-mapping="MAPPINGS" \
    --attribute-condition="CONDITIONS"

Where the –idp-metadata-path is the local file path to your SAML IDP’s metadata document.

For a complete step by step guide for setting up Workload Identity Federation with SAML and specific guidance for identity providers like ADFS please see our documentation for Configuring Workload Identity Federation.

We are also launching encryption support for SAML federation in Preview. Encrypting SAML assertions can protect confidential user information and adds an extra layer of security to Workload Identity Federation. To request access to the SAML encryption preview, please complete this form.

How to access Google Cloud using SAML federation

As with other federation protocols supported by Workload Identity Federation, you will first need to authenticate your workload to your identity provider and obtain a credential. Your workload can then exchange the credential for a Google Cloud access token using the Security Token Service.

In order to use Workload Identity Federation with the Google Cloud client libraries, your workloads need to make a local file containing the credential issued by your identity provider available. Refreshing the credential in this file could be burdensome, and the file itself needs to be protected. To simplify and improve the security of using Workload Identity Federation with the Google Cloud client libraries, we will soon introduce the ability for the multiple client libraries to call an external process to retrieve the credential.

How to retrieve credentials by calling an external processes

Calling an external process to retrieve credentials from your identity provider using a client library can be straightforward. Once this is available for each client library, you will be able to specify the external process to call when generating a credential configuration file.

gcloud iam workload-identity-pools create-cred-config projects/$PROJECT_NUMBER/locations/$LOCATION/workloadIdentityPools/$WORKLOAD_POOL_ID/providers/$PROVIDER_ID \
    --service-account=$EMAIL --subject-token-type=urn:ietf:params:oauth:token-type:saml2 \
    --executable-command "/path/to/get/credentials.sh --arg1=value1 --arg2=value2" \ 
    --executable-timeout-millis 5000

Where the executable-command is the path and arguments to call to retrieve the credential and executable-timeout-millis is how long (in milliseconds) the client library will wait for the executable before erroring out.

Once you generate the credential’s configuration file, you can set the GOOGLE_APPLICATION_CREDENTIALS environment variable to point to the file so that the client libraries are automatically authenticated.

When a Google Cloud client library calls a Google Cloud service with Workload Identity Federation, it will execute the process at the configured path with the configured parameters. This process that you create should retrieve the credential from your identity provider to allow your workload to authenticate to Google Cloud. You can learn more about retrieving credentials with external processes in our documentation once it becomes available in each of our client libraries.

For a complete guide on configuring the Google Cloud client libraries for SAML Workload Identity Federation please see Authenticating by using client libraries, the gcloud CLI, or Terraform. For a complete guide on using SAML Workload Identity Federation with the REST API please see Authenticating by using the REST API.

Next steps

Moving from service account keys to the keyless application authentication mechanism enabled by Workload Identity Federation can help you reduce the risks associated with managing long-lived keys for application authentication across your environment. To learn more about Workload Identity Federation, take a look at our documentation. To learn about the other Cloud Security announcements today, check out the Google Cloud Security Summit, which is available live and afterwards on-demand.

By: Shaun Liu (Product Manager)
Source: Google Cloud Blog