Some or all of the information on this page might not apply to Trusted Cloud by S3NS. See Differences from Google Cloud for more details.

Identity management for Google Cloud

To use Trusted Cloud by S3NS, users and workloads need an identity that Trusted Cloud can recognize.

This page outlines the methods that you can use to configure identities for users and workloads.

User identities

You can configure user identities for Trusted Cloud through Workforce Identity Federation. This method lets you use your external identity provider (IdP) to sign in your users to Trusted Cloud and let them access Trusted Cloud resources and products. With Workforce Identity Federation, users need only one account: their external account. This type of user identity is sometimes referred to as a federated identity.

Workload identities

Trusted Cloud provides the following types of identity services for workloads:

Workload Identity Federation lets your workloads access most Trusted Cloud services by using an identity that is provided by an IdP. Workloads that use Workload Identity Federation can run on Trusted Cloud, Google Kubernetes Engine (GKE), or other platforms, such as AWS, Azure, and GitHub.
Trusted Cloud service accounts can act as identities for workloads. Instead of granting access to a workload directly, you grant access to a service account, then let the workload use the service account as its identity.
Managed workload identities (Preview) let you bind strongly attested identities to your Compute Engine workloads. You can use managed workload identities to authenticate your workloads to other workloads using mutual TLS (mTLS), but they cannot be used for authenticating to Trusted Cloud APIs.

The methods that you can use depend on where your workloads are running.

If you're running workloads on Trusted Cloud, you can use the following methods to configure workload identities:

Workload Identity Federation for GKE: Grant IAM access to GKE clusters and Kubernetes service accounts. Doing so lets the clusters' workloads access most Trusted Cloud services directly, without using IAM service account impersonation.
Attached service accounts: Attach a service account to a resource so that the service account acts as the resource's default identity. Any workloads running on the resource use the service account's identity when accessing Trusted Cloud services.
Short-lived service account credentials: Generate and use short-lived service account credentials whenever your resources need to access to Trusted Cloud services. The most common types of credentials are OAuth 2.0 access tokens and OpenID Connect (OIDC) ID tokens.

If you're running workloads outside of Trusted Cloud, you can use the following methods to configure workload identities:

Workload Identity Federation: Use credentials from external identity providers to generate short-lived credentials, which workloads can use to temporarily impersonate service accounts. Workloads can then access Trusted Cloud resources, using the service account as their identity.
Service account keys: Use the private portion of a service account's public/private RSA key pair to authenticate as the service account.

Important: Service account keys are a security risk if not managed correctly. You should choose a more secure alternative to service account keys whenever possible. If you must authenticate with a service account key, you are responsible for the security of the private key and for other operations described by Best practices for managing service account keys. If you are prevented from creating a service account key, service account key creation might be disabled for your organization. For more information, see Managing secure-by-default organization resources.
If you acquired the service account key from an external source, you must validate it before use. For more information, see Security requirements for externally sourced credentials.

To learn more about these methods for setting up workload identities, see Workload identities overview.