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

Identity management for Google Cloud

To use Cloud de Confiance by S3NS, users and workloads need an identity that Cloud de Confiance 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 Cloud de Confiance through Workforce Identity Federation. This method lets you use your external identity provider (IdP) to sign in your users to Cloud de Confiance and let them access Cloud de Confiance 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

Cloud de Confiance provides the following types of identity services for workloads:

Workload Identity Federation lets your workloads access most Cloud de Confiance services by using an identity that is provided by an IdP. Workloads that use Workload Identity Federation can run on Cloud de Confiance, Google Kubernetes Engine (GKE), or other platforms, such as AWS, Azure, and GitHub.
Cloud de Confiance 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 Cloud de Confiance APIs.

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

If you're running workloads on Cloud de Confiance, 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 Cloud de Confiance 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 Cloud de Confiance services.
Short-lived service account credentials: Generate and use short-lived service account credentials whenever your resources need to access to Cloud de Confiance 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 Cloud de Confiance, 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 Cloud de Confiance 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.